Bug 102520 - execshield proc variable needs to be removed
Summary: execshield proc variable needs to be removed
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
Blocks: 101028
TreeView+ depends on / blocked
Reported: 2003-08-16 13:51 UTC by John Reiser
Modified: 2007-11-30 22:06 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-22 00:37:54 UTC
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 13:53 UTC, John Reiser
no flags Details

Description John Reiser 2003-08-16 13:51:41 UTC
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 13:53:00 UTC
Created attachment 93682 [details]
failed results of trying to change exec-shield parameter

Comment 2 Arjan van de Ven 2003-08-16 14:01:04 UTC
the /proc/sys/kernel/exec-shield value has absolutely no effect and will indeed
be removed.

Comment 3 John Reiser 2003-08-16 14:40:04 UTC
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 14:41:27 UTC
there is no more TASK_UNMAPPED_BASE actually; allocations are now done top down

Comment 5 Jay Turner 2003-08-22 00:37:54 UTC
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.