On Fri, Aug 12, 2011 at 18:19 -0500, H. Peter Anvin wrote: > Vasiliy Kulikov <segoon@xxxxxxxxxxxx> wrote: > > >This patch changes mmap base address allocator logic to incline to > >allocate addresses from the first 16 Mbs of address space. These > >addresses start from zero byte (0x00AABBCC). ... To make it clear: The VM space is not significantly reduced - an additional gap, which is used for ASCII-protected region, is calculated the same way as the common mmap gap is calculated. The maximum size of the gap is 1MB for the upstream kernel default ASLR entropy - a trifle IMO. If the new allocator fails to find appropriate vma in the protected zone, the old one tries to do the job. So, no visible changes for userspace. As to the benefit: 1) For small PIE programs, which don't use much libraries, all executable regions are moved to the protected zone. 2) For non-PIE programs if image starts from 0x00AABBCC address and fits into the zone the same rule of small libs applies. 3) For non-PIE programs with images above 0x01000000 and/or programs with much libraries some code sections are outsize of the protected region. The protection works for (1) and (2) programs. It doesn't work for (3). (1) is not too seldom. Programs, which need such protection (network daemons, programs parsing untrusted input, etc.), are usually small enough. In our distro, Openwall GNU/*/Linux, almost all daemon programs fit into the region. As the changes are not intrusive, we'd want to see this feature in the upstream kernel. If you know why the patch cannot be a part of the upstream kernel - please tell me, I'll try to address the issues. Thanks, -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>