[ros-dev] [ros-diffs] [jgardou] 48465: [WIN32K] - Rewrite NtGdiStretchDIBitsInternal : clearer, faster, stronger (+1 wine test)

[Jérôme Gardou]

Le vendredi 06 août 2010 19:03:57, Timo Kreuzer a écrit :
> Hi,
> 
> Please take care about proper protection of the user mode buffer. The
> current solution: probe and forget is not safe.
> 
> Possibilities are:
> 1) SEH protected copying of the buffer, pass the copy of the buffer to
> lower level functions -> Easy to do, large overhead for large bitmaps.
> 2) SEH protected call to a lower level function, passing the user mode
> buffer. -> Not possible if the lower level function is either allocating
> any resources (unless also protected by SEH + finally) or can pass
> execution to 3rd party provided code, like drivers.
> 3) Be sure to have SEH at the lowest level (DIB) -> Not possible as the
> function might end up in a driver.
> 4) Use Mm to protect the buffer. Either with MmSecureVirtualMemory or
> double mapping using MmProbeAndLockPages + MmGetSystemAddressForMdlSafe.
> 
> I think 4 is the way to go. While the overhead of remapping should be
> relatively small compared to a full copy, we are still wasting large
> ammounts of system address space.
> MmSecureVirtualMemory might at first sound like a good solution, but
> beware, it has some pitfalls. While it protects a memory range from
> being freed, it doesn't protect it from being paged out. That wouldn't
> be a problem, unless the memory is not backed by the page file, but let
> say a network resource, which becomes unavailable after a page was paged
> out. In this case we would get an in page error when trying to access
> the page, leading to a kernel crash. So unless we can be sure that the
> memory is backed by the page file, we need to additionally lock the
> pages into memory to be safe. Final thing to note is that
> MmSecureVirtualMemory is not implemented yet, but I hope with current
> work on the VAD code, we'll soon get a present (hint).
> 
> Regards,
> Timo
> 
I'm OK for 4. Looking for MmSecureVirtualMemory to be implemented.
Please note that for now, SURFACE::hSecure is hacked to be (HANDLE)1 so we can 
detect if the bitmap is a DIB. As now all **DIB** functions create a DIB, it 
will be securised in the process. Others bits can be PSEH-accessed during the 
DIB creation, as it the only place it's used.

Regards.
Jérôme.