VM_GROWSDOWN

Posted Aug 20, 2010 17:05 UTC (Fri) by njs (subscriber, #40338)
In reply to: VM_GROWSDOWN by helge.bahmann
Parent article: An ancient kernel hole is closed

For 32-bit apps, address space is not at all cheap.

VM_GROWSDOWN

Posted Aug 20, 2010 19:26 UTC (Fri) by helge.bahmann (subscriber, #56804) [Link] (2 responses)

This is typically about 8MB and therefore <1% of the total address space (assuming 32-bit kernel). If your app cannot tolerate that, you are in worse trouble.

VM_GROWSDOWN

Posted Aug 21, 2010 4:28 UTC (Sat) by chad.netzer (subscriber, #4257) [Link] (1 responses)

Threaded processes can conceivably allocate a lot of (mostly unused?) stack space, and the kernel allows processes to specify a much bigger limit for those wacky applications that need it. Also, mmap'ing applications can put a lot of pressure on the 32-bit address mapping. So the address space may not be as cheap as you envision.

As the article mentions, and spender helpfully emphasizes, the Delalleau paper gives a good graphical overview of the situation.

http://cansecwest.com/core05/memory_vulns_delalleau.pdf

VM_GROWSDOWN

Posted Aug 21, 2010 11:58 UTC (Sat) by helge.bahmann (subscriber, #56804) [Link]

The stacks for threads are not allocated with VM_GROWSDOWN [*], so you already pay the "price" for a fully reserved address space there. VM_GROWSDOWN apparently onlys affect the main thread, so the expenditure of additional 8MB of address space is really only once (and if the admin likes fine-tuning, s/he can always rlimit this further down).

[*] I don't see how GROWSDOWN would make sense for thread stacks, to provide any meaningful growth potential for them you would have to thoughtfully sprinkle them throughout the address space and carefully dance around these locations with other mappings.