https://devblogs.microsoft.com/oldnewthing/20221216-00/?p=107598 Skip to main content [RE1Mu3b] Microsoft The Old New Thing The Old New Thing The Old New Thing * Home * DevBlogs * Developer + Visual Studio + Visual Studio Code + Visual Studio for Mac + DevOps + Developer support + CSE Developer + Engineering@Microsoft + Azure SDK + IoT + Command Line + Perf and Diagnostics + Dr. International + Notification Hubs + Math in Office + React Native * Technology + DirectX + PIX + SurfaceDuo + Startups + Sustainable Engineering + Windows AI Platform * Languages + C++ + C# + F# + Visual Basic + TypeScript + PowerShell Community + PowerShell Team + Python + Q# + JavaScript + Java + Java Blog in Chinese * .NET + .NET + .NET MAUI + Blazor + ASP.NET + NuGet + Xamarin + .NET Blog in Chinese * Platform Development + #ifdef Windows + Apps for Windows + Azure Depth Platform + Azure Government + Bing Dev Center + Microsoft Edge Dev + Microsoft Azure + Microsoft 365 Developer + Old New Thing + Windows MIDI and Music dev + Windows Search Platform * Data Development + Azure Cosmos DB + Azure Data Studio + Azure SQL Database + OData + Revolutions R + SQL Server Data Tools * More [ ] Search Search * No results Cancel Why doesn't Windows use the 64-bit virtual address space below 0x00000000`7ffe0000? [png] Raymond Chen December 16th, 20225 3 A customer used VMMap and observed that for all of their 64-bit processes, nothing was allocated at any addresses below 0x00000000 `7ffe0000. Why does the virtual address space start at 0x00000000 `7ffe0000? Is it to make it easier to catch pointer truncation bugs? And what's so special about 0x00000000`7ffe0000? Okay, let's go through the questions one at a time. First, is it even true that the virtual address space starts at 0x00000000`7ffe0000? No. The virtual address space starts at the 64KB boundary. You can confirm this by calling GetSystemInfo and checking the lpMinimumApplicationAddress. It will be 0x00000000`00010000. If the address space starts at 64KB, why is the lower 2GB pretty much ignored? Because it turns out that the total address space is really big. Address Space Layout Randomization (ASLR) tries to put things at unpredictable addresses. The full user-mode address space on x86-64 is 128TB, and a randomly-generated 47-bit address is very unlikely to begin with 15 consecutive zero bits. The first 2GB of address space is only 0.003% of the total available address space, so it's a pretty small target. But why is there a page of memory consistently allocated at exactly 0x00000000`7ffe0000? That is a special page of memory that is mapped read-only into user mode from kernel mode, and it contains things like the current time, so that applications can get this information quickly without having to take a kernel transition. This page is at a fixed location for performance reasons. If a 64-bit application is not marked /LARGEADDRESSAWARE, then it receives a shrunken address space of only 2GB so that it doesn't have to deal with any "large addresses" (namely, those above 2GB). These "64-bit processes that don't understand addresses above 2GB" (also known in my kitchen as "really stupid 64-bit processes") still need to access the shared data, so the shared data must go below the 2GB boundary. Since virtual address space granularity on Windows is 64KB, reserving a single page actually reserves an entire 64KB block, from 0x00000000 `7ffe0000 to 0x00000000`7ffeffff. Also in this range is a second read-only page mapped from kernel mode, this time for sharing information with the hypervisor, specifically the partition reference time stamp counter. This second page is placed at a random location inside the 64KB range, not so much for ASLR reasons (since there are only 15 choices, which isn't very random), but just to make sure that nobody accidentally takes a dependency on a fixed address. As noted in the documentation, you find this partition reference time stamp counter page by reading the HV_X64_MSR_REFERENCE_TSC model-specific register. Okay, but why are these special shared pages in the range 0x00000000 `7ffe0000 to 0x00000000`7ffeffff? Why not put them right up at the 2GB boundary of 0x00000000`7fff0000 to 0x00000000`7fffffff? One reason is that the 64KB region immediately above and below the 2GB boundary are marked permanently invalid in order to simplify address validity checks: On 32-bit systems, the 2GB boundary marks the traditional boundary between user mode and kernel mode. If you put a "no man's land" between user mode and kernel mode, then you can validate a memory range by checking that it starts in user mode, and verifying that every page is accessible. You'll run into the inaccessible page before you get to the kernel mode addresses. Okay, that explains why there's a no man's land on 32-bit systems, but why do we also have it on 64-bit systems? On the Alpha AXP, most 32-bit constants can be generated in at most two instructions. But there's a range of values that requires three instructions: 0x7fff8000 to 0x7fffffff. Blocking off that region means that you never have to provide a relocation fixup that targets the problematic memory range. And the initial target of 64-bit Windows was the Alpha AXP. [png] Raymond Chen Follow Tagged Other Read next Not even trying to cross an airtight hatchway: Calling a function in your own process by synthesizing a function pointer You can already attack yourself in far more interesting ways. [png]Raymond Chen December 1, 2022 4 comments Dubious security vulnerability: Reading the files in the WindowsApps folder You already had access to those files, by virtue of the fact that they ran in the first place. [png]Raymond Chen November 29, 2022 2 comments 5 comments Leave a commentCancel reply Log in to join the discussion. * [png] Joshua Hudson December 17, 2022 12:02 pm 1 collapse this comment "really stupid 64 bit processes" Does that mean I can make an x32 process on Windows? An x32 process is one complied targeting amd64 instruction set but has sizeof(void*) = 4. This decreases cache pressure at the consequence of can't possibly exceed 4GB ram (well in this case 2GB unless VirtualAlloc will take a fixed address above 2GB despite no /LARGEADDRESSSEARE) Log in to Vote or Reply + [png] Jan Ringos December 17, 2022 5:35 pm 1 collapse this comment Only sort of. There is no x32 ABI on Windows, so pointers interacting with Windows API, and basically all other libraries, always needs to be 64-bit. But your own pointers absolutely can be 32-bit, and that indeed improves performance. See this synthetic benchmark and results I did some time ago. Log in to Vote or Reply * [png] Stevie White December 17, 2022 10:38 pm 0 collapse this comment Great write up Raymond, I had a feeling this was going to be an interesting one. The comments are also very interesting. Log in to Vote or Reply * [png] Andrew Kent-Morris December 18, 2022 11:31 am 0 collapse this comment I just wanted to thank you for the Cheers reference. Log in to Vote or Reply * [png] Robert Burke December 18, 2022 12:34 pm 0 collapse this comment Given that most applications see a 10%ish speedup from large pages, is there any plan to make large pages usable for applications that do not run as administrator or applications that might not run continually from startup on Windows, like Microsoft Excel or World of Warcraft? Log in to Vote or Reply Archive December 2022 November 2022 October 2022 September 2022 August 2022 July 2022 June 2022 May 2022 April 2022 March 2022 February 2022 January 2022 December 2021 November 2021 October 2021 September 2021 August 2021 July 2021 June 2021 May 2021 April 2021 March 2021 February 2021 January 2021 December 2020 November 2020 October 2020 September 2020 August 2020 July 2020 June 2020 May 2020 April 2020 March 2020 February 2020 January 2020 December 2019 November 2019 October 2019 September 2019 August 2019 July 2019 June 2019 May 2019 April 2019 March 2019 February 2019 January 2019 December 2018 November 2018 October 2018 September 2018 August 2018 July 2018 June 2018 May 2018 April 2018 March 2018 February 2018 January 2018 December 2017 November 2017 October 2017 September 2017 August 2017 July 2017 June 2017 May 2017 April 2017 March 2017 February 2017 January 2017 December 2016 November 2016 October 2016 September 2016 August 2016 July 2016 June 2016 May 2016 April 2016 March 2016 February 2016 January 2016 December 2015 November 2015 October 2015 September 2015 August 2015 July 2015 June 2015 May 2015 April 2015 March 2015 February 2015 January 2015 December 2014 November 2014 October 2014 September 2014 August 2014 July 2014 June 2014 May 2014 April 2014 March 2014 February 2014 January 2014 December 2013 November 2013 October 2013 September 2013 August 2013 July 2013 June 2013 May 2013 April 2013 March 2013 February 2013 January 2013 December 2012 November 2012 October 2012 September 2012 August 2012 July 2012 June 2012 May 2012 April 2012 March 2012 February 2012 January 2012 December 2011 November 2011 October 2011 September 2011 August 2011 July 2011 June 2011 May 2011 April 2011 March 2011 February 2011 January 2011 December 2010 November 2010 October 2010 September 2010 August 2010 July 2010 June 2010 May 2010 April 2010 March 2010 February 2010 January 2010 December 2009 November 2009 October 2009 September 2009 August 2009 July 2009 June 2009 May 2009 April 2009 March 2009 February 2009 January 2009 December 2008 November 2008 October 2008 September 2008 August 2008 July 2008 June 2008 May 2008 April 2008 March 2008 February 2008 January 2008 December 2007 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 May 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 Relevant Links I wrote a book Ground rules Disclaimers and such My necktie's Twitter Categories Code History Tips/Support Other Non-Computer Stay informed Login Theme * light-theme-iconLight * dark-theme-iconDark Insert/edit link Close Enter the destination URL URL [ ] Link Text [ ] [ ] Open link in a new tab Or link to existing content Search [ ] No search term specified. Showing recent items. Search or use up and down arrow keys to select an item. Cancel [Add Link] Code Block x Paste your code snippet [ ] Cancel Ok Feedback usabilla icon What's new * Surface Pro 9 * Surface Laptop 5 * Surface Studio 2+ * Surface Laptop Go 2 * Surface Laptop Studio * Surface Duo 2 * Microsoft 365 * Windows 11 apps Microsoft Store * Account profile * Download Center * Microsoft Store support * Returns * Order tracking * Personal shopping appointments * Microsoft Store Promise * Flexible Payments Education * Microsoft in education * Devices for education * Microsoft Teams for Education * Microsoft 365 Education * Education consultation appointment * Educator training and development * Deals for students and parents * Azure for students Business * Microsoft Cloud * Microsoft Security * Dynamics 365 * Microsoft 365 * Microsoft Power Platform * Microsoft Teams * Microsoft Industry * Small Business Developer & IT * Azure * Developer Center * Documentation * Microsoft Learn * Microsoft Tech Community * Azure Marketplace * AppSource * Visual Studio Company * Careers * About Microsoft * Company news * Privacy at Microsoft * Investors * Diversity and inclusion * Accessibility * Sustainability * Sitemap * Contact Microsoft * Privacy * Manage cookies * Terms of use * Trademarks * Safety & eco * About our ads * (c) Microsoft 2022