I quote from the WDK:
“When Force IRQL Checking is enabled, Driver Verifier will provide extreme
memory pressure on the selected driver. Whenever a driver being verified
requests a spin lock, calls KeSynchronizeExecution, or raises the IRQL to
DISPATCH_LEVEL or higher, all of the driver’s pageable code and data (as
well as system pageable pool, code, and data) are trimmed from the working
set.”
Lets say I have a driver that uses METHOD_NEITHER and receives a usermode
address in its disptach routine and goes on to acquire a spinlock, thereby
raising the IRQL to DISPATCH_LEVEL. If I have Force IRQL Checking turned
on, will verifier page out the usermode memory? Based on a strict
interpretation of the information above, not to mention personal experience,
I would say no. Is my assumption correct? Is there a technical reason why
Verifier doesn’t do this?
You cannot access the UMbuffer at raised IRQL, regardless of the
verifier setting. DV doesn’t do this today b/c it doesn’t know anything
about the UM address you are referencing, DV only knows about the
code/data in your driver. If you need to touch the buffer at raised
IRQL, make a copy of it first into a system buffer.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Takin
Nili-Esfahani
Sent: Tuesday, April 10, 2007 7:34 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Verifier Force IRQL Checking
I quote from the WDK:
"When Force IRQL Checking is enabled, Driver Verifier will provide
extreme
memory pressure on the selected driver. Whenever a driver being
verified
requests a spin lock, calls KeSynchronizeExecution, or raises the IRQL
to
DISPATCH_LEVEL or higher, all of the driver’s pageable code and data (as
well as system pageable pool, code, and data) are trimmed from the
working
set."
Lets say I have a driver that uses METHOD_NEITHER and receives a
usermode
address in its disptach routine and goes on to acquire a spinlock,
thereby
raising the IRQL to DISPATCH_LEVEL. If I have Force IRQL Checking
turned
on, will verifier page out the usermode memory? Based on a strict
interpretation of the information above, not to mention personal
experience,
I would say no. Is my assumption correct? Is there a technical reason
why
Verifier doesn’t do this?
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> raising the IRQL to DISPATCH_LEVEL. If I have Force IRQL Checking turned
on, will verifier page out the usermode memory?
I think only the kernel paged pool is paged out.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it there is no problem whatsoever. Certainly, in practical terms, after having run the code that does the above few times you are more than likely to bluescreen anyway, so that you don’t even need DriverVerifier in order to detect this bug…
Anton Bassov
I should have been more clear, you cannot *safely and deterministically*
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Hold it. That sounds like you can’t use a probed and locked buffer for
DMA? I know that’s not true.
Hmm. You say the PDE can be paged out, does that mean that the system VA
I get back after probing and locking the buffer and calling
MmGetSystemAddressForMdlSafe() isn’t always valid? Or are you saying that
probing and locking isn’t sufficient, and the process VA isn’t necessarily
valid, so you need to get a system VA from MmGetSystemAddressForMdlSafe()?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 11, 2007 9:12 AM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Verifier Force IRQL Checking
I should have been more clear, you cannot safely and deterministically
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Hold it. That sounds like you can’t use a probed and locked buffer for
DMA? I know that’s not true.
No, this sounds like you cannot dereference Irp->UserBuffer from >=
DISPATCH_LEVEL even if you (or the IO manager) have called MmProbeAndLockPages.
Hmm. You say the PDE can be paged out, does that mean that the system VA
I get back after probing and locking the buffer and calling
MmGetSystemAddressForMdlSafe() isn’t always valid?
System VA is always valid.
User VA is not always valid, even if MmProbeAndLockPages was called. The pages
cannot go out after MmProbeAndLockPages, but the user PTEs can.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
By calling MmGetSystemAddressForMdlSafe you have system VA. I am
referring to the user VA address
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Wednesday, April 11, 2007 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Verifier Force IRQL Checking
Hold it. That sounds like you can’t use a probed and locked buffer for
DMA? I know that’s not true.
Hmm. You say the PDE can be paged out, does that mean that the system
VA I get back after probing and locking the buffer and calling
MmGetSystemAddressForMdlSafe() isn’t always valid? Or are you saying
that probing and locking isn’t sufficient, and the process VA isn’t
necessarily valid, so you need to get a system VA from
MmGetSystemAddressForMdlSafe()?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 11, 2007 9:12 AM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Verifier Force IRQL Checking
I should have been more clear, you cannot safely and deterministically
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer — Questions? First
check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
MmProbeAndLockPages locks the pages in memory. Not the user VA addresses. So the pages are resident, but the process itself can call a free() on the user VA, thus causing the user VA to become invalid (and just that becomes invalid).
Have a nice day
GV
----- Original Message -----
From: xxxxx@seagate.com
To: Windows System Software Devs Interest List
Sent: Wednesday, April 11, 2007 11:03 AM
Subject: RE: [ntdev] Verifier Force IRQL Checking
Hold it. That sounds like you can’t use a probed and locked buffer for DMA? I know that’s not true.
Hmm. You say the PDE can be paged out, does that mean that the system VA I get back after probing and locking the buffer and calling MmGetSystemAddressForMdlSafe() isn’t always valid? Or are you saying that probing and locking isn’t sufficient, and the process VA isn’t necessarily valid, so you need to get a system VA from MmGetSystemAddressForMdlSafe()?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 11, 2007 9:12 AM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Verifier Force IRQL Checking
I should have been more clear, you cannot safely and deterministically
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Our current approach is something like this:
IoAllocateMdl
MmProbeAndLockPages
MmGetSystemAddressForMdlSafe
Would this lock the PDE in place?
You mentioned in your other post that we should make a copy of the usermode
data in a system buffer. Did you mean that we should make a copy during
each operation? How would we synchronize this since we can’t touch the
usermode buffer after acquiring a spinlock?
“Doron Holan” wrote in message
news:xxxxx@ntdev…
I should have been more clear, you cannot safely and deterministically
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
OK, that restores order to my sense of the world. Yes, I knew that you
have to probe and lock and then get a system VA to safely access a UM
buffer inside the kernel. It appeared that you were saying even that
wasn’t sufficient.
So the statement should probably be that “You can’t safely access the UM
buffer through the UM *address* at raised IRQL.”
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 11, 2007 12:20 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Verifier Force IRQL Checking
By calling MmGetSystemAddressForMdlSafe you have system VA. I am
referring to the user VA address
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Wednesday, April 11, 2007 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Verifier Force IRQL Checking
Hold it. That sounds like you can’t use a probed and locked buffer for
DMA? I know that’s not true.
Hmm. You say the PDE can be paged out, does that mean that the system VA
I get back after probing and locking the buffer and calling
MmGetSystemAddressForMdlSafe() isn’t always valid? Or are you saying that
probing and locking isn’t sufficient, and the process VA isn’t necessarily
valid, so you need to get a system VA from MmGetSystemAddressForMdlSafe()?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 11, 2007 9:12 AM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Verifier Force IRQL Checking
I should have been more clear, you cannot safely and deterministically
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer — Questions? First
check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Yup
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Wednesday, April 11, 2007 11:43 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Verifier Force IRQL Checking
OK, that restores order to my sense of the world. Yes, I knew that you
have to probe and lock and then get a system VA to safely access a UM
buffer inside the kernel. It appeared that you were saying even that
wasn’t sufficient.
So the statement should probably be that “You can’t safely access the UM
buffer through the UM *address* at raised IRQL.”
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 11, 2007 12:20 PM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Verifier Force IRQL Checking
By calling MmGetSystemAddressForMdlSafe you have system VA. I am
referring to the user VA address
d
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Wednesday, April 11, 2007 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Verifier Force IRQL Checking
Hold it. That sounds like you can’t use a probed and locked buffer for
DMA? I know that’s not true.
Hmm. You say the PDE can be paged out, does that mean that the system
VA I get back after probing and locking the buffer and calling
MmGetSystemAddressForMdlSafe() isn’t always valid? Or are you saying
that probing and locking isn’t sufficient, and the process VA isn’t
necessarily valid, so you need to get a system VA from
MmGetSystemAddressForMdlSafe()?
Phil
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
________________________________
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, April 11, 2007 9:12 AM
To: “Windows System Software Devs Interest List”
Subject: RE: [ntdev] Verifier Force IRQL Checking
I should have been more clear, you cannot safely and deterministically
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer — Questions? First
check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer — Questions? First
check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
The copy comes into play if you are not calling
MmGetSystemAddressForMdlSafe. For instance, you can probe/lock the
buffer, copy it to a local buffer and then use the local buffer. If you
are mapping it into system va, a copy might not be necessary. The
reason it might still be necessary is if you are reading from the buffer
and making decisions based on the buffer state, the UM can change the
buffer after sending the IOCTL and alter your driver’s internal state
decisions, potentially causing your driver to do weird, wacky and
dangerous things. If all you are doing is writing to the buffer or
reading from it once and capturing the work from the first read, a copy
is not necessary.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Takin
Nili-Esfahani
Sent: Wednesday, April 11, 2007 11:36 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Verifier Force IRQL Checking
Our current approach is something like this:
IoAllocateMdl
MmProbeAndLockPages
MmGetSystemAddressForMdlSafe
Would this lock the PDE in place?
You mentioned in your other post that we should make a copy of the
usermode
data in a system buffer. Did you mean that we should make a copy during
each operation? How would we synchronize this since we can’t touch the
usermode buffer after acquiring a spinlock?
“Doron Holan” wrote in message
news:xxxxx@ntdev…
I should have been more clear, you cannot safely and deterministically
the UM buffer at rasied IRQL. If you probe and lock it, the PDE in the
process could be paged out at any time.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, April 11, 2007 2:49 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Verifier Force IRQL Checking
> You cannot access the UMbuffer at raised IRQL
Well, as long as buffer is present in RAM at the time you access it
there is no problem whatsoever. Certainly, in practical terms, after
having run the code that does the above few times you are more than
likely to bluescreen anyway, so that you don’t even need DriverVerifier
in order to detect this bug…
Anton Bassov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Takin Nili-Esfahani wrote:
You mentioned in your other post that we should make a copy of the usermode
data in a system buffer. Did you mean that we should make a copy during
each operation? How would we synchronize this since we can’t touch the
usermode buffer after acquiring a spinlock?
Why do you need to synchronize the copy?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.