From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030709 Description of problem: A program which analyzes another running program wants to see the previous behavior of mmap(0, ...) beginning its search for a free page frame at TASK_UNMAPPED_BASE (0x40000000 typical). Exec-shield randomizes the value to be something larger than 0x00100000 instead. This behavior is supposed to be controlled by /proc/sys/kernel/exec-shield, but trying all four legal values [0, 1, 2, 3] has no observable effect: the address used for mmap(0, ...) is always random > 0x00100000. Version-Release number of selected component (if applicable): kernel-2.4.21-1.1931.2.393.ent How reproducible: Always Steps to Reproduce: 1. Run script (as root) ----- #!/bin/bash for j in 0 1 2 3 do echo; echo ===== $j echo $j >/proc/sys/kernel/exec-shield echo exec-shield = $(cat /proc/sys/kernel/exec-shield) cat /proc/self/maps done ----- 2. 3. Actual Results: Shared libraries are seen at "random" addresses > 0x00100000; output attached. Expected Results: One of those values for exec-shield should force the old behavior of allocating page frames sequentially beginning at TASK_UNMAPPED_BASE (typically 0x40000000 in 2.4.20, for example). Additional info: # uname -a Linux taroon 2.4.21-1.1931.2.393.ent #1 Wed Aug 13 21:38:34 EDT 2003 i686 athlon i386 GNU/Linux
Created attachment 93682 [details] failed results of trying to change exec-shield parameter
the /proc/sys/kernel/exec-shield value has absolutely no effect and will indeed be removed.
Is there [will there be] any way to get the old behavior of sequential allocation beginning at TASK_UNMAPPED_BASE [or replacement]?
there is no more TASK_UNMAPPED_BASE actually; allocations are now done top down instead.
Fix confirmed with 2.4.21-1.1931.2.399.entsmp.