I’m pretty sure that this falls into the category of ‘sharing memory
from kernel space’ and if so I’ll just read the archives as I’ve seen it
discussed quite a bit over time.
Someone has just asked the question about sharing a page of memory with
another VM under Xen. So either userspace says to my driver “here’s a
page of memory, lock it into memory and give me a reference to it” (A
reference is an index into a table of page mapping structures containing
the pfn, access modes, etc), or it says “allocate me a page of
non-paged, give me the VA and a reference”. I’m pretty sure that you
can’t do the latter, but what are the security implications of the
former?
And this is a more general question - what happens if I allocate a
memory buffer from userspace and give it to the kernel to do some async
I/O with, and then free the buffer before the kernel returns, which
could take a long time (eg because the I/O is reading 4K of data from
the network or serial port or something). How does the kernel know that
the buffer has been free’d and could have been re-allocated by another
process? What stops that memory being trashed?
Thanks
James
James,
Take a look at http://www.osronline.com/article.cfm?id=39. You can
ask the kernel to allocate and share a page with user space. As to your
question of a buffer from user space, if you have locked the pages down you
have a kernel address, and the freeing just eliminates the user address.
–
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“James Harper” wrote in message
news:xxxxx@ntdev…
I’m pretty sure that this falls into the category of ‘sharing memory
from kernel space’ and if so I’ll just read the archives as I’ve seen it
discussed quite a bit over time.
Someone has just asked the question about sharing a page of memory with
another VM under Xen. So either userspace says to my driver “here’s a
page of memory, lock it into memory and give me a reference to it” (A
reference is an index into a table of page mapping structures containing
the pfn, access modes, etc), or it says “allocate me a page of
non-paged, give me the VA and a reference”. I’m pretty sure that you
can’t do the latter, but what are the security implications of the
former?
And this is a more general question - what happens if I allocate a
memory buffer from userspace and give it to the kernel to do some async
I/O with, and then free the buffer before the kernel returns, which
could take a long time (eg because the I/O is reading 4K of data from
the network or serial port or something). How does the kernel know that
the buffer has been free’d and could have been re-allocated by another
process? What stops that memory being trashed?
Thanks
James
Information from ESET NOD32 Antivirus, version of virus signature
database 4471 (20090930)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Information from ESET NOD32 Antivirus, version of virus signature database 4471 (20090930)
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
James Harper wrote:
And this is a more general question - what happens if I allocate a
memory buffer from userspace and give it to the kernel to do some async
I/O with, and then free the buffer before the kernel returns, which
could take a long time (eg because the I/O is reading 4K of data from
the network or serial port or something). How does the kernel know that
the buffer has been free’d and could have been re-allocated by another
process? What stops that memory being trashed?
With buffered I/O, the kernel driver is working with a copy of the data
that exists only in kernel space. There is no danger there.
With direct I/O, the I/O manager creates an MDL for the user buffer,
which raises the reference count on those physical pages. The pages
will not be re-used until the last reference is released. Even if the
user frees the memory, allocates it again, and happens to get the same
virtual address, they will be different physical pages. The driver can
complete the I/O at its leisure. When it returns and the MDL is freed,
only then will the pages will be released.
With neither I/O, you’re responsible for following the rules and
creating the MDL. If you don’t follow the rules, then bad things can
happen, as you say.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If you lock the VAs down, the user will get an error back should they attempt to release those virtual addresses or alter their page protection in a fashion that is incompatible with the protection supplies when locking the mapping down.
-----Original Message-----
From: James Harper
Sent: Wednesday, September 30, 2009 16:51
To: Windows System Software Devs Interest List
Subject: [ntdev] sharing memory with another xen virtual machine from userland
I’m pretty sure that this falls into the category of ‘sharing memory
from kernel space’ and if so I’ll just read the archives as I’ve seen it
discussed quite a bit over time.
Someone has just asked the question about sharing a page of memory with
another VM under Xen. So either userspace says to my driver “here’s a
page of memory, lock it into memory and give me a reference to it” (A
reference is an index into a table of page mapping structures containing
the pfn, access modes, etc), or it says “allocate me a page of
non-paged, give me the VA and a reference”. I’m pretty sure that you
can’t do the latter, but what are the security implications of the
former?
And this is a more general question - what happens if I allocate a
memory buffer from userspace and give it to the kernel to do some async
I/O with, and then free the buffer before the kernel returns, which
could take a long time (eg because the I/O is reading 4K of data from
the network or serial port or something). How does the kernel know that
the buffer has been free’d and could have been re-allocated by another
process? What stops that memory being trashed?
Thanks
James
—
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
> If you lock the VAs down, the user will get an error back should they attempt to release
those virtual addresses or alter their page protection in a fashion that is incompatible with the
protection supplies when locking the mapping down.
IIRC, drivers are not supposed to lock VAs in the user space- IIRC, ZwLockVirtualMemory() is not exported by ntoskrnl.exe. The only thing they are supposed to lock is MDL. By doing so you simply tell the system not to reuse physical pages that MDL describes (which means they cannot get swapped out to the disk) until you unlock it. It has nothing to do with virtual addresses, and, hence, with page protection - an app is certainly to free a buffer while driver uses MDL that describes the target buffer.
The only thing that step implies is that by unmapping a range an app loses its access to the pages that MDL describes
Your statement applies in the situation when you are mapping MDL to the user address space from a driver (and in this case you cannot specify page protection - it will be RW anyway). In this case an app, indeed, has no control over VADs corresponding to the buffer - it cannot free this buffer and it cannot change its page protection to more restrictive one. This is why your call to
MmMapLockedPagesSpecifyCache() will fail if you attempt to map MDL to the address that had been earlier reserved by an app that had called VirtualAlloc() with MEM_RESERVE flag - after all, an app is supposed to be free to do anything it wants with a buffer it has allocated…
Anton Bassov
On Thu, 01 Oct 2009 12:21:38 +0200, wrote:
> IIRC, drivers are not supposed to lock VAs in the user space- IIRC,
> ZwLockVirtualMemory() is not exported by ntoskrnl.exe.
Drivers can use MmSecureVirtualMemory() for this purpose:
http://msdn.microsoft.com/en-us/library/ms802934.aspx
- Cay
> Drivers can use MmSecureVirtualMemory() for this purpose: >http://msdn.microsoft.com/en-us/library/ms802934.aspx
This function does not ensure that all pages in a buffer are resident in RAM, which, if I got it right, is one of the OP’s requirements . Therefore, he still needs to lock MDL, which eliminates any need to be bothered about things that happen in the userland. In fact, this function does not seem to be particularly useful in itself - no wonder driver writers are advised NOT to use it…
Anton Bassov
Have I implied anything to the contrary? By the same reasoning, the
posting I was referring to, yours, would be equally redundant, given that
MmMapLockedPagesSpecifyCache() automatically locks/secures the user-space
VAD.
On Thu, 01 Oct 2009 21:17:45 +0200, wrote:
>> Drivers can use MmSecureVirtualMemory() for this purpose:
>> >http://msdn.microsoft.com/en-us/library/ms802934.aspx
>
> This function does not ensure that all pages in a buffer are resident in
> RAM, which, if I got it right, is one of the OP’s requirements .
> Therefore, he still needs to lock MDL, which eliminates any need to be
> bothered about things that happen in the userland. In fact, this
> function does not seem to be particularly useful in itself - no wonder
> driver writers are advised NOT to use it…
>
>
> Anton Bassov
> By the same reasoning, the posting I was referring to, yours, would be equally redundant, given that >MmMapLockedPagesSpecifyCache() automatically locks/secures the user-space VAD.
Please note that MmMapLockedPagesSpecifyCache() affects user-space VAD only if you map MDL to the userland. However, judging from the original post, there is nothing that suggests that it applies to the OP’s situation. Instead, he will do exactly the opposite, i.e. lock MDL that describes user buffer and map it to the kernel address space, so that user-space VAD is not going to be affected and user may free the buffer. This is the reason why James asks his question, in the first place- he asks whether this may pose a problem to a driver…
Anton Bassov
On Fri, 02 Oct 2009 00:10:30 +0200, wrote:
> Please note that MmMapLockedPagesSpecifyCache() affects user-space VAD
> only if you map MDL to the userland.
Yes, of course. I’ve had the other way in mind which James has also
mentioned. In this case, however, I don’t understand why you have
mentioned ZwLockVirtualMemory() in the first place, the point I was
originally referring to.
- Cay
James - You could let Xenstore manage it for you… At Virtual Iron I wrote some code that would mirror the Xenstore (at least the portions available to each VM) under a key in the windows registry. You can use all of the Zw registry functions and CmRegisterCallback to achieve this.
Once you have that, you can use Regedit to view or modify xenstore and userland applications can just use the standard registry access APIs.
> Could it be that when userspace requests direct I/O on a buffer, the system takes care of this
for you anyway?
If you use direct IO the target buffer is described by MDL field in IRP, and this MDL is already locked
by the time your drivers receives IRP…
Anton Bassov
> I don’t understand why you have mentioned ZwLockVirtualMemory() in the first place,
OK, fair point - indeed, locking VADs does not necessarily imply locking target pages in RAM, although doing the former does not seem to be particularly useful without doing the latter…
Anton Bassov
>the network or serial port or something). How does the kernel know that
the buffer has been free’d and could have been re-allocated by another
process? What stops that memory being trashed?
The virtual address range (PTEs) is really purged, but the pages themselves are not, since they are locked in the MDL.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com