Bug 102520 - execshield proc variable needs to be removed
execshield proc variable needs to be removed
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
Blocks: 101028
  Show dependency treegraph
Reported: 2003-08-16 09:51 EDT by John Reiser
Modified: 2007-11-30 17:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-21 20:37:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
failed results of trying to change exec-shield parameter (2.57 KB, text/plain)
2003-08-16 09:53 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2003-08-16 09:51:41 EDT
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):

How reproducible:

Steps to Reproduce:
1. Run script (as root)
for j in 0 1 2 3
        echo; echo ===== $j
        echo $j >/proc/sys/kernel/exec-shield
        echo exec-shield = $(cat /proc/sys/kernel/exec-shield)
        cat /proc/self/maps

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
Comment 1 John Reiser 2003-08-16 09:53:00 EDT
Created attachment 93682 [details]
failed results of trying to change exec-shield parameter
Comment 2 Arjan van de Ven 2003-08-16 10:01:04 EDT
the /proc/sys/kernel/exec-shield value has absolutely no effect and will indeed
be removed.
Comment 3 John Reiser 2003-08-16 10:40:04 EDT
Is there [will there be] any way to get the old behavior of sequential
allocation beginning at TASK_UNMAPPED_BASE [or replacement]?
Comment 4 Arjan van de Ven 2003-08-16 10:41:27 EDT
there is no more TASK_UNMAPPED_BASE actually; allocations are now done top down
Comment 5 Jay Turner 2003-08-21 20:37:54 EDT
Fix confirmed with 2.4.21-1.1931.2.399.entsmp.

Note You need to log in before you can comment on or make changes to this bug.