Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 207020

Summary: vDSO placement ignores exec-shield; inhibits NX simulation
Product: [Fedora] Fedora Reporter: John Reiser <jreiser>
Component: kernelAssignee: Ingo Molnar <mingo>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: davej, security-response-team, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-03 00:50:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description John Reiser 2006-09-18 19:48:57 UTC
Description of problem: On i386, the kernel is placing the vDSO into the address
space without honoring the strategy requested by /proc/sys/kernel/exec-shield. 
Requests are: If bit 3 (value 8) is set, then just below the .text of PT_INTERP
(  If bit 2 (value 4) is set, then just below the .text of main.  Other
combinations for just below STACKTOP, and random.  Insteasd, the observed
behavior is the vDSO is placed just below stacklimit.  On x86 that do not have
NX hardware, this means that simulating NX by reducing the segment limit of %cs
is not effective at all, because the segment limit of %cs must cover the vDSO. 
So the observed behavior cannot protect against execution on the main heap,
whereas the requested policy could.  Also, placement just below stacklimit means
that the stack never can be expanded once it is reached (no soft limit).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. cat /proc/self/maps
Actual results:
08048000-0804d000 r-xp 00000000 03:47 1207729    /bin/cat
0804d000-0804e000 rwxp 00004000 03:47 1207729    /bin/cat
09813000-09834000 rwxp 09813000 00:00 0 
4bab1000-4baca000 r-xp 00000000 03:47 1925778    /lib/
4baca000-4bacb000 r-xp 00018000 03:47 1925778    /lib/
4bacb000-4bacc000 rwxp 00019000 03:47 1925778    /lib/
4c480000-4c5b7000 r-xp 00000000 03:47 1925785    /lib/
4c5b7000-4c5b9000 r-xp 00137000 03:47 1925785    /lib/
4c5b9000-4c5ba000 rwxp 00139000 03:47 1925785    /lib/
4c5ba000-4c5bd000 rwxp 4c5ba000 00:00 0 
b7d2a000-b7f2a000 r-xp 00000000 03:47 472129     /usr/lib/locale/locale-archive
b7f2a000-b7f2c000 rwxp b7f2a000 00:00 0 
b7f3b000-b7f3c000 r-xp b7f3b000 00:00 0          [vdso]
bfc2b000-bfc40000 rw-p bfc2b000 00:00 0          [stack]

and that is independent of /proc/sys/kernel/exec-shield (in particular, the
values 9 or 5.)

Expected results:
After "echo 9 >/proc/sys/kernel/exec-shield":
4bab0000-4bab1000 r-xp 00000000 00:00 0          [vDSO]
4bab1000-4baca000 r-xp 00000000 03:47 1925778    /lib/

After "echo 5 >/proc/sys/kernel/exec-shield":
08047000-08048000 r-xp 00000000 00:00 0          [vDSO]
08048000-0804d000 r-xp 00000000 03:47 1207729    /bin/cat

Additional info:
There is some history in bug #162797.  The patch was included as an update to
FC5 very shortly after final release.

Comment 1 Dave Jones 2006-10-03 00:50:03 UTC
should be fixed in todays build