grsecurity forums

Are there any documented workarounds to get SEGMEXEC to work with more than 3GB of virtual memory (which also implies <= 1GB of physical RAM) on x86 systems?

For example, would something along the lines of enabling PAE (CONFIG_HIGHMEM64G) and upping PaX's segmentation offset be possible somehow?

I'm going on the assumption that the performance hit from enabling PAE would be less than that of using PAGEEXEC on my systems, but I have no data either way.

Thanks.

personman wrote:Are there any documented workarounds to get SEGMEXEC to work with more than 3GB of virtual memory (which also implies <= 1GB of physical RAM) on x86 systems?

check out the 2.2 patch which supports different user/kernel splits already, the same changes would be needed for 2.4/2.6 as well.

For example, would something along the lines of enabling PAE (CONFIG_HIGHMEM64G) and upping PaX's segmentation offset be possible somehow?

the two are independent, PAE increases the amount of physical memory you can access, it has no effect on the usable userland virtual memory size which SEGMEXEC affects. furthermore, PAE as used on linux forces a userland size to be a multiple of 1GB, so you couldn't get anything bigger than 3GB anyway. what could be done and is on my todo list actually is to change the userland memory layout under the assumption that most apps map a 'small' amount of executable code (executable + libs) only, this will allow to increase the SEGMEXEC task size to something like 2.5 GB or so (3 GB - size of executable/libs modulo randomization).