Re: win32/memory locking (Re: Reply to EFS note on Bugtraq)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bits _never_ get written to the disk? Guaranteed never to use swap space? The GnuPG FAQ (http://www.gnupg.org/faq.html#q6.1) suggests that it is not possible to make a Windows program insist on physical RAM the way a program can in Open Systems. Does EFS really use only physical RAM? If so, is there some win32 API that can be used by other application designers who want to guarantee that certain blocks of allocated memory are *never* swapped out to disk? The most likely candidate I've come across is VirtualLock() which, unfortunately, "does not mean that the page will not be paged to disk" (http://msdn.microsoft.com/library/techart/msdn_virtmm.htm). Thanks, -Peter As described on the MSDN site: "The AllocateUserPhysicalPages function is used to allocate physical memory. Memory allocated by this function must be physically present in the system. Once allocated, it is locked down and unavailable to the rest of the virtual memory management system of Windows 2000." _http://msdn.microsoft.com/library/psdk/winbase/memman_0u5v.htm_ The UserPhysicalPages class of functions appear to be directly related to kernel calls, so I'd take a guess and say it's probably what you're looking for. - James Perry -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE6bp0ds6J9OMPOxE8RAki4AKCiTWweQkkvcRWBqUyXJDQEFu8yngCfYNP8 f/adsAYRzRYstL63pJZSZbo= =g2j5 -END PGP SIGNATURE-
Re: win32/memory locking (Re: Reply to EFS note on Bugtraq)
From: Peter W [mailto:[EMAIL PROTECTED]] Bits _never_ get written to the disk? Guaranteed never to use swap space? The GnuPG FAQ (http://www.gnupg.org/faq.html#q6.1) suggests that it is not possible to make a Windows program insist on physical RAM the way a program can in Open Systems. Does EFS really use only physical RAM? If so, is there some win32 API that can be used by other application designers who want to guarantee that certain blocks of allocated memory are *never* swapped out to disk? The most likely candidate I've come across is VirtualLock() which, unfortunately, "does not mean that the page will not be paged to disk" (http://msdn.microsoft.com/library/techart/msdn_virtmm.htm). This is certainly possible as EFS is a kernel mode device driver and not a Win32 application. Non pageable memory can be easily allocated from the non-paged pool by a device driver (and is one of the fundamental concepts in writing a Win2000 driver). The EFS driver communicates with the local security authority (lsass) to allow the use of CryptoAPI for encryption of the data, but as lsass is a Native applciation (not Win32) then it may have access to other (undocumented) functions, or simply pass a pointer to the non-paged memory it has allocated for the encryption buffers. Note that the PGP implementation uses a device driver (PGPmemlock.sys) to lock pages into memory and prevent them from being swapped out. I am unsure as to the motives of the GPG team if they have not implemented a similar feature, but smells like FUD to me. John Wiltshire
Re: win32/memory locking (Re: Reply to EFS note on Bugtraq)
Quoting James Perry [EMAIL PROTECTED]: As described on the MSDN site: "The AllocateUserPhysicalPages function is used to allocate physical memory. Memory allocated by this function must be physically present in the system. Once allocated, it is locked down and unavailable to the rest of the virtual memory management system of Windows 2000." _http://msdn.microsoft.com/library/psdk/winbase/memman_0u5v.htm_ The UserPhysicalPages class of functions appear to be directly related to kernel calls, so I'd take a guess and say it's probably what you're looking for. - James Perry AllocateUserPhysicalPages() is only available on Windows 2000. VirtualAlloc() with the PAGE_NOCACHE flag is available for Windows NT 3.1+ and Windows 95+. From the MSDN Library: PAGE_NOCACHE - Allows no caching of the committed regions of pages. The hardware attributes for the physical memory should be specified as "no cache." This is not recommended for general usage. It is useful for device drivers; for example, mapping a video frame buffer with no caching. This value is a page protection modifier, and it is only valid when used with one of the page protections other than PAGE_NOACCESS. Keith Ray [EMAIL PROTECTED] http://www.nullify.org PGP - 0xAE1B3529 - 8227 60E5 BAA5 9461 CAB3 A6F2 4DFE F573 AE1B 3529
win32/memory locking (Re: Reply to EFS note on Bugtraq)
On Mon, Jan 22, 2001 at 05:28:50PM -0800, Ryan Russell wrote: Due to some mail trouble, I'm manually forwarding this note. From: Microsoft Security Response Center Subject:Re: BugTraq: EFS Win 2000 flaw "... it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc." Bits _never_ get written to the disk? Guaranteed never to use swap space? The GnuPG FAQ (http://www.gnupg.org/faq.html#q6.1) suggests that it is not possible to make a Windows program insist on physical RAM the way a program can in Open Systems. Does EFS really use only physical RAM? If so, is there some win32 API that can be used by other application designers who want to guarantee that certain blocks of allocated memory are *never* swapped out to disk? The most likely candidate I've come across is VirtualLock() which, unfortunately, "does not mean that the page will not be paged to disk" (http://msdn.microsoft.com/library/techart/msdn_virtmm.htm). Thanks, -Peter
