Greetings,
I’m looking for advice on the technical feasibility of this - at the moment, I’m experimenting reading from the harddisk using _inpw from kernel mode, bypassing the file system to get at the raw disk contents without relying on apis/syscalls/etc. It is working fine on an XP VM and single core physical machine but in moving to Vista/dual core machines, it becomes unreliable in operation.
Is this a fundamental problem which I will be unable to solve? I suppose the issue is that the OS is performing other disk operations alongside my PIO instructions which are interfering with my command structuring. I’d prefer to keep everything passive but is there a possibility of synchronizing my accesses with the other drive operations temporarily?
Alternatively, I’ve considered performing all of my reads within my DriverEntry on bootup - does anyone know if this would be fundamentally more reliable?
Thank you for the input!
Is this a disk that is to be used in normal operation? If so forget this.
If not why do you feel you want to create the work for yourself versus
accessing the disk as a raw device?
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
wrote in message news:xxxxx@ntdev…
> Greetings,
> I’m looking for advice on the technical feasibility of this - at the
> moment, I’m experimenting reading from the harddisk using _inpw from
> kernel mode, bypassing the file system to get at the raw disk contents
> without relying on apis/syscalls/etc. It is working fine on an XP VM and
> single core physical machine but in moving to Vista/dual core machines, it
> becomes unreliable in operation.
>
> Is this a fundamental problem which I will be unable to solve? I suppose
> the issue is that the OS is performing other disk operations alongside my
> PIO instructions which are interfering with my command structuring. I’d
> prefer to keep everything passive but is there a possibility of
> synchronizing my accesses with the other drive operations temporarily?
>
> Alternatively, I’ve considered performing all of my reads within my
> DriverEntry on bootup - does anyone know if this would be fundamentally
> more reliable?
>
> Thank you for the input!
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4634 (20091124)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4634 (20091124)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Hello Don,
Thank you for the response and feedback. Yes, this disk is intended for normal use. Ideally I’d be able to read the data raw to perform a cross-sectional analysis between what is visible in usermode within the operating system and what I receive back from raw mode.
Other more “conventional” approaches are all marred by the multiple points of interception within the driver stack where malware can embed itself into to modify read data, while accessing data in this manner appears to be a much clearer and more direct approach.
I’m aware of the inevitability of the cat-and-mouse game but unfortunately the mice have been upping their game recently and the security industry can’t force the average “Mom and Pop” user to scan offline via a boot CD (which would obviously be the best approach).
From the time of boot if you go out there independantly to access the
hardware then you are MALWARE. Sorry but trying to go too far makes the
cure worse than the disease.
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Hello Don,
> Thank you for the response and feedback. Yes, this disk is intended for
> normal use. Ideally I’d be able to read the data raw to perform a
> cross-sectional analysis between what is visible in usermode within the
> operating system and what I receive back from raw mode.
>
> Other more “conventional” approaches are all marred by the multiple points
> of interception within the driver stack where malware can embed itself
> into to modify read data, while accessing data in this manner appears to
> be a much clearer and more direct approach.
>
> I’m aware of the inevitability of the cat-and-mouse game but unfortunately
> the mice have been upping their game recently and the security industry
> can’t force the average “Mom and Pop” user to scan offline via a boot CD
> (which would obviously be the best approach).
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4634 (20091124)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4634 (20091124)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
What’s stopping malware from hoisting your code into ring 1 and trapping
port access? (I’ve seen drivers that do this…)
–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group
This post implies no warranties and confers no rights.
wrote in message news:xxxxx@ntdev…
> Hello Don,
> Thank you for the response and feedback. Yes, this disk is intended for
> normal use. Ideally I’d be able to read the data raw to perform a
> cross-sectional analysis between what is visible in usermode within the
> operating system and what I receive back from raw mode.
>
> Other more “conventional” approaches are all marred by the multiple points
> of interception within the driver stack where malware can embed itself
> into to modify read data, while accessing data in this manner appears to
> be a much clearer and more direct approach.
>
> I’m aware of the inevitability of the cat-and-mouse game but unfortunately
> the mice have been upping their game recently and the security industry
> can’t force the average “Mom and Pop” user to scan offline via a boot CD
> (which would obviously be the best approach).
>
> t is there a possibility of synchronizing my accesses with the other drive operations temporarily?
Well, technically it is feasible - it can be achieved by a technique known as “CPU corralling”. You can start a thread of every CPU( other than the one that performs target operations, of course) that disables interrupts and spins in an infinite loop that polls the state of a global variable. After having accomplished your ops you change the state of this variable (it is done by the CPU that handles operations), thus telling other CPUs that they can break out of their infinite loops and re-enable interrupts…
This technique can be used only in a situation when your target resource is GUARANTEED to be accesses at elevated IRQL, i.e. access to it guarded by a spinlock or interrupt spinlock. “Corralling” threads run at PASSIVE_LEVEL, which means that all outstanding operations the target resource will be accomplished by the “official” components by the time all CPU get “corralled”. Therefore, you are not going to catch the “official” components in the midst of their operations on the target resource, which
may leave it in inconsistent state.
If the target resource is guarded by dispatcher-level construct that allows preemption this technique is not reliable, for understandable reasons…
However, before you proceed to corralling, please read carefully Don’s statement about a “cure that is worse than a disease itself”…
Anton Bassov
Anton is correct but his statement “target resource is GUARANTEED to be
accesses at elevated IRQL” is not somehting you can be sure of unless you
own the sources, and if so why are you mucking with this approach there are
better ones.
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
wrote in message news:xxxxx@ntdev…
>
>> t is there a possibility of synchronizing my accesses with the other
>> drive operations temporarily?
>
> Well, technically it is feasible - it can be achieved by a technique known
> as “CPU corralling”. You can start a thread of every CPU( other than the
> one that performs target operations, of course) that disables interrupts
> and spins in an infinite loop that polls the state of a global variable.
> After having accomplished your ops you change the state of this variable
> (it is done by the CPU that handles operations), thus telling other CPUs
> that they can break out of their infinite loops and re-enable
> interrupts…
>
>
> This technique can be used only in a situation when your target resource
> is GUARANTEED to be accesses at elevated IRQL, i.e. access to it guarded
> by a spinlock or interrupt spinlock. “Corralling” threads run at
> PASSIVE_LEVEL, which means that all outstanding operations the target
> resource will be accomplished by the “official” components by the time all
> CPU get “corralled”. Therefore, you are not going to catch the “official”
> components in the midst of their operations on the target resource, which
> may leave it in inconsistent state.
>
>
> If the target resource is guarded by dispatcher-level construct that
> allows preemption this technique is not reliable, for understandable
> reasons…
>
>
>
> However, before you proceed to corralling, please read carefully Don’s
> statement about a “cure that is worse than a disease itself”…
>
>
>
>
> Anton Bassov
>
>
> Information from ESET NOD32 Antivirus, version of virus
> signature database 4635 (20091125)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
Information from ESET NOD32 Antivirus, version of virus signature database 4635 (20091125)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
I’m missing the part where this is supposed to work on a system that
has disks that are not accessed through some IO ‘port’ . The OP seems
to be referring to IDE architecture disk stacks.
Mark Roddy
On Wed, Nov 25, 2009 at 8:14 AM, Don Burn wrote:
> Anton is correct but his statement “target resource is GUARANTEED to be
> accesses at elevated IRQL” is not somehting you can be sure of unless you
> own the sources, and if so why are you mucking with this approach there are
> better ones.
>
>
> –
> Don Burn (MVP, Windows DKD)
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
> wrote in message news:xxxxx@ntdev…
>>
>>> t is there a possibility of synchronizing my accesses with the other
>>> drive operations temporarily?
>>
>> Well, technically it is feasible - it can be achieved by a technique known
>> as “CPU corralling”. You can start a thread of every CPU( other than the
>> one that performs target operations, of course) that disables interrupts
>> and spins in an infinite loop that polls the state of a global variable.
>> After having accomplished your ops you change the state of this variable
>> (it is done by the CPU that handles operations), thus telling other CPUs
>> that they can break out of their infinite loops and re-enable
>> interrupts…
>>
>>
>> This technique can be used only in a situation when your target resource
>> is GUARANTEED to be accesses at elevated IRQL, i.e. access to it guarded
>> by a spinlock or interrupt spinlock. “Corralling” threads ?run at
>> PASSIVE_LEVEL, which means that ?all outstanding operations the target
>> resource will be accomplished by the “official” components by the time all
>> CPU get “corralled”. Therefore, you are not going to catch the “official”
>> components in the midst of their operations on the target resource, which
>> may leave it in inconsistent state.
>>
>>
>> If the target resource is guarded by dispatcher-level construct that
>> allows preemption this technique is not reliable, for understandable
>> reasons…
>>
>>
>>
>> However, before you proceed to corralling, please read carefully Don’s
>> statement about a “cure that is worse than a disease itself”…
>>
>>
>>
>>
>> Anton Bassov
>>
>>
>> Information from ESET NOD32 Antivirus, version of virus
>> signature database 4635 (20091125)
>>
>> The message was checked by ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>
>
>
> Information from ESET NOD32 Antivirus, version of virus signature database 4635 (20091125)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
Don,
statement “target resource is GUARANTEED to be accesses at elevated IRQL” is not somehting
you can be sure of unless you own the sources
Actually, this is the reason why I stated “guaranteed” in capitals - as long as you don’t own the target resource the only thing you can do is guessing. Furthermore, even if you do it safely, the whole thing is incredibly inefficient, so that one must have a really compelling reason to attempt something like that…
Anton Bassov
> I’m looking for advice on the technical feasibility of this - at the moment, I’m experimenting reading
from the harddisk using _inpw from kernel mode, bypassing the file system to get at the raw disk
contents without relying on apis/syscalls/etc.
What is the need in this?
performing other disk operations alongside my PIO instructions which are interfering with my
command structuring.
Exactly.
I’d prefer to keep everything passive but is there a possibility of synchronizing my accesses with the
other drive operations temporarily?
No ways.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>> t is there a possibility of synchronizing my accesses with the other drive operations temporarily?
Well, technically it is feasible - it can be achieved by a technique known as “CPU corralling”.
The state of disk controller is not known at this moment, so, this is not a solution.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>from the harddisk using _inpw from kernel mode
I would also add that AHCI is popular these days, and sorry, it’s IO ports are different. More so, AHCI does not use the IO ports at all 
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> The state of disk controller is not known at this moment,
Is not it being accessed in atomic context only??? Look - if there is a possibility that it may get accessed
in ISR/DPC any component that does not run in atomic context must acquire a spinlock before accessing it.
If this is the case “corralling” will work just fine…
Anton Bassov
>> The state of disk controller is not known at this moment,
Is not it being accessed in atomic context only???
It is.
But it can be in busy state, and its driver knows of it. Other software will not have this knowledge and will submit commands to the already busy controller.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>
>> The state of disk controller is not known at this moment,
>
> Is not it being accessed in atomic context only???
It is.
But it can be in busy state, and its driver knows of it. Other
software will
not have this knowledge and will submit commands to the already busy
controller.
You could relieve that somewhat by putting a filter in the stack to
count requests. If there are no outstanding requests you could have some
confidence that the device is quiet.
There are several problems with this though…
Spinning all CPU’s at HIGH_LEVEL while you do your dirty work isn’t an
atomic operation though, so a request could sneak through while you are
setting it up.
Performance would suck - you really do need to make sure nothing else
happens in the system while you are doing you dirty work.
If the whole point is to avoid malware, you have no confidence that
malware isn’t feeding requests to the driver in a way that isn’t visible
to you. Also, if you can do port based disk access then so can malware.
Part of my day job is assisting with the fixing of computers that are
playing up. Antivirus software (firewall software in particular) is the
cause of way more problems than viruses themselves - please don’t add to
this.
James
Nice antivirus software is not much of a problem. Is it the solution to all
malware? No! Firewalls are a little better with Vista and Win7 because of
the WFP capability, however Microsoft seems to have failed to understand the
problem completely. WFP can do stateful packet inspection but at its level
knowledge of the source and target of the requests has been dropped so most
firewalls require multiple filtering drivers (or locations) within the NDIS
stack.
I think having a hardware firewall is the best solution since it keeps the
load on another system. Just using NAT is a good idea to eliminate many
attack vectors. I use Norton Internet Security on my notebooks, but since I
get Symantec’s AV from my employer for free I use it on most of my desktops
since I have a firewall at home. The latest version of Symantec’s product,
Symantec Endpoint Protection, seems to be much less overhead than many
others. The only problem for home users is that obtaining software updates
is a real pain since it is targeted at IT departments who get notice of
updates and are allowed to push those to their users after they have been
tested. Signatures are updated automatically but not as frequently as the
latest Norton products which update every few minutes.
While it has changed a lot with Windows, I remember ‘AtGuard’ very fondly.
During that time I was always connected via dialup with no hardware
firewall. It would stop probes and attacks all the time during the 9x, NT,
& early 2000 days. Symantec bought AtGuard so it became the base for their
firewall products.
“James Harper” wrote in message
news:xxxxx@ntdev…
>
> >> The state of disk controller is not known at this moment,
> >
> > Is not it being accessed in atomic context only???
>
> It is.
>
> But it can be in busy state, and its driver knows of it. Other
software will
> not have this knowledge and will submit commands to the already busy
> controller.
>
You could relieve that somewhat by putting a filter in the stack to
count requests. If there are no outstanding requests you could have some
confidence that the device is quiet.
There are several problems with this though…
Spinning all CPU’s at HIGH_LEVEL while you do your dirty work isn’t an
atomic operation though, so a request could sneak through while you are
setting it up.
Performance would suck - you really do need to make sure nothing else
happens in the system while you are doing you dirty work.
If the whole point is to avoid malware, you have no confidence that
malware isn’t feeding requests to the driver in a way that isn’t visible
to you. Also, if you can do port based disk access then so can malware.
Part of my day job is assisting with the fixing of computers that are
playing up. Antivirus software (firewall software in particular) is the
cause of way more problems than viruses themselves - please don’t add to
this.
James
> Spinning all CPU’s at HIGH_LEVEL while you do your dirty work isn’t an atomic operation though,
so a request could sneak through while you are setting it up.
This is not a problem - once you are not going to start your actual “dirty work” until all CPUs have been “corralled”, processing of requests while you are setting up the whole thing does not pose any problem.
Problems may arise if
-
Requests starts getting processed while your “dirty work” is in progress. This cannot happen, for understandable reasons
-
Your “dirty work” gets in the middle of the operation by a legitimate owner. This is why the whole thing
may work if and only if requests are GUARANTEED to be processed atomically by a legitimate owner - otherwise the whole thing is unsafe by definition…
Performance would suck - you really do need to make sure nothing else happens in the
system while you are doing you dirty work.
This is where Don’s statement about “cure worse than disease itself” holds particularly true…
Anton Bassov
>
> Spinning all CPU’s at HIGH_LEVEL while you do your dirty work isn’t
an
atomic operation though,
> so a request could sneak through while you are setting it up.
This is not a problem - once you are not going to start your actual
“dirty
work” until all CPUs have been “corralled”, processing of requests
while you
are setting up the whole thing does not pose any problem.
It’s during the setup of the corralling I was referring to. The way I
take control of all the cpu’s (when doing live migration under Xen) is:
- Throw the switch to stop new requests being processed in the scsi and
ndis drivers
- Wait until outstanding requests are complete
- Schedule a DPC onto each CPU
- In the DPC for CPU != 0, go to HIGH_LEVEL, InterlockedIncrement a
counter and when spin in a while() loop
- In the DPC for CPU 0, go to HIGH_LEVEL and wait until all other CPU’s
are spinning
etc
That’s fine for me because I own the drivers for the devices I care
about. It is between steps 3 and 4 above that a new request could come
through - another DPC (or just code elevated to DISPATCH_LEVEL) might
beat you to it. Of course you could solve it by just unwinding and
starting again if you detect that this has happened, but that’s more
things to go wrong.
Also, under a non-virtualised environment, aren’t there timeout concerns
on an SMP system if you go above IPI_LEVEL for too long (Bug Check
0x101)? Given that you’d have to wait for the request to complete while
you are at HIGH_LEVEL, this could be up to a second (or more?) for a
spun down disk - it won’t be a common occurrence but it is one you have
to account for.
James
> I use Norton Internet Security on my notebooks, but since I
get Symantec’s AV from my employer for free I use it on most of my
desktops
since I have a firewall at home.
My favourite Symantec product is the “Norton Removal Tool”
The last computer I fixed was behaving very much like it had a virus -
AVG wasn’t updating and other strange things were happening. Internet
access seemed to work from IE6 but from nothing else (including IE7 and
IE8).
Eventually I found that all the Symantec drivers were still installed
and had their tentacles wound tightly around the network stack. All the
services and stuff were uninstalled so the user didn’t get prompted for
“This program wants to access the internet - Cancel or Allow” etc, but
for some reason the Symantec drivers didn’t get uninstalled by the
uninstaller and so their list of allowed programs could never be
changed.
It’s not just Symantec either - so many times I’ve seen the trial
antivirus software that gets loaded onto computers by brand name
manufacturers fail to uninstall properly.
James
> It’s during the setup of the corralling I was referring to. The way I take control of all the cpu’s (when doing live migration under Xen) is:
- Throw the switch to stop new requests being processed in the scsi and ndis drivers
- Wait until outstanding requests are complete
- Schedule a DPC onto each CPU
- In the DPC for CPU != 0, go to HIGH_LEVEL, InterlockedIncrement a counter and when spin
in a while() loop
- In the DPC for CPU 0, go to HIGH_LEVEL and wait until all other CPU’s are spinning
Actually, as far as consistency is concerned, steps 1 and 2 are not really needed …
It is between steps 3 and 4 above that a new request could come through
So what??? Depending on its position in DPC queue relative to your DPC its processing will be either completed or not yet started by the time you start your operation on the resource. Neither case poses a problem - problems would arise if your processing and the one by “legitimate owner” could somehow overlap. The one by the resource owner cannot interfere with yours because you disable interrupts, and your processing can interfere with the one by the resource owner only if “legitimate” resource owner accesses it in non-atomic fashion, which is. a situation when you cannot even think about any “corralling” scheme…
Anton Bassov