Bug 427641 - exec-shield GPF handler vs fixmap vDSO
Summary: exec-shield GPF handler vs fixmap vDSO
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 8
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-06 04:24 UTC by John Reiser
Modified: 2011-12-13 22:28 UTC (History)
5 users (show)

Fixed In Version: 2.6.23.15-137.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-11 22:39:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description John Reiser 2008-01-06 04:24:52 UTC
Description of problem: kernel hangs at boot if the kernel boot parameter
"vdso=2" is specified.


Version-Release number of selected component (if applicable):
kernel-2.6.23.9-85.fc8

How reproducible:
Always

Steps to Reproduce:
1. Append " vdso=2" to the kernel boot command line.
2. Boot.
3.
  
Actual results:
Hang with console messages:
  init[1] general protection eip=3167d9 esp=bfbdd89c error:0
and repetition counts into the multi-millions.

Expected results:
Enable VDSO_COMPAT feature, which puts the vdso at a very high virtual address.
 Specifying "vdso=0" does not remove the vdso.  Instead, vdso=0 still puts the
vdso into the address space, it just doesn't tell you where (it merely omits the
AT_SYSINFO* parameters.)  What I want is no vdso, or vdso outside the range 0 to
0xa0000000 (2.56GB).

Additional info:
Somewhat related to bug # 229304.

Comment 1 John Reiser 2008-01-06 04:26:10 UTC
Also present in kernel-2.6.23.12-52.fc7.


Comment 2 Jon Stanley 2008-01-06 18:57:23 UTC

*** This bug has been marked as a duplicate of 375681 ***

Comment 3 John Reiser 2008-01-06 20:04:29 UTC
Please re-open, because vdso=2 is not a duplicate of vdso=off (or vdso=0) as is
the case in bug # 375681.

The documented [linux/Documentation/kernel-parameters.txt] and desired behavior
with vdso=2 is for the vdso to be present and announced to the process via
AT_SYSINFO*, but for the vdso page to be placed at a very high virtual address,
higher than any other valid user-accessible address, higher than anywhere in the
stack, higher than any pointer to (or characters of) a commandline argument or
environment variable, higher than any AT_* vector.

Also, the documentation says that "vdso=0" works, whereas comments to bug #
375681 shows that it didn't work then.

Comment 4 Jon Stanley 2008-01-06 20:39:09 UTC
(In reply to comment #3)

> The documented [linux/Documentation/kernel-parameters.txt] and desired behavior
> with vdso=2 is for the vdso to be present and announced to the process via
> AT_SYSINFO*, but for the vdso page to be placed at a very high virtual address,
> higher than any other valid user-accessible address, higher than anywhere in the
> stack, higher than any pointer to (or characters of) a commandline argument or
> environment variable, higher than any AT_* vector.

Sorry. per comment #0 you mention that you want no vdso, which vdso=off would
have given you.  What about the sysctl recommended in bug 375681?  Has the
behavior of that changed at all?

It's also worth noting that I could not reproduce this on my laptop (a Core 2
Duo with 2GB RAM).  Then I tried on a VMWare guest that I gave the maximum
amount of RAM (3600MB) and it is reproducible there.

> Also, the documentation says that "vdso=0" works, whereas comments to bug #
> 375681 shows that it didn't work then.

Right, but vdso=off did.

Comment 5 John Reiser 2008-01-07 18:42:00 UTC
(In reply to comment #4)

> What about the sysctl recommended in bug 375681?

Running (as root) "sysctl vm.vdso_enabled=2" causes *every* new process to crash
with Segmentation fault.  Existing processes run, but the system is unusable for
anything else.  Shutdown fails; hardware reset is necessary.

> It's also worth noting that I could not reproduce this on my laptop (a Core 2
> Duo with 2GB RAM).  Then I tried on a VMWare guest that I gave the maximum
> amount of RAM (3600MB) and it is reproducible there.

Booting vdso=2 always hangs for me on i686 (amd64 in i686 mode, NVidia CK804
chipset) with 1GB RAM.

Comment 6 Christopher Brown 2008-01-29 23:57:36 UTC
Its easy for me to replicate this, both with current and rawhide kernels. It
might be resolved in Roland McGrath's patchset which didn't make 2.6.24 however....

http://lkml.org/lkml/2007/11/19/277

Comment 7 Roland McGrath 2008-01-30 02:07:20 UTC
If you have a live shell you can do "echo 1 > /proc/sys/vm/vdso_enabled" without
needing to exec any new programs that hit the problem.

Reproduced and isolated with 2.6.23.14-107.fc8.  workaround:

 stap -g -e 'function ebx:long() %{ THIS->__retvalue = c->regs->ebx;
c->regs->ebx=0xfffff000; %} probe kernel.statement(0xc10060cd) { printf("%s %d
limit=%x\n", execname(), pid(), ebx()); }'&


Comment 8 Roland McGrath 2008-01-30 02:17:24 UTC
I committed a fix to rawhide's linux-2.6-execshield.patch; backporting this to
F-8 should cover it, or it can wait til F-8 rebases from the 2.6.24-based code.

Reassigning to punt worrying about F-8.

--- linux-2.6.23.noarch/arch/i386/kernel/traps.c.~1~
+++ linux-2.6.23.noarch/arch/i386/kernel/traps.c
@@ -599,6 +599,9 @@ unsigned long limit;
 		for (vma = current->mm->mmap; vma; vma = vma->vm_next)
 			if ((vma->vm_flags & VM_EXEC) && (vma->vm_end > limit))
 				limit = vma->vm_end;
+		vma = get_gate_vma(current);
+		if (vma && (vma->vm_flags & VM_EXEC) && (vma->vm_end > limit))
+			limit = vma->vm_end;
 		spin_unlock(&current->mm->page_table_lock);
 		if (limit >= TASK_SIZE)
 			limit = -1UL;



Comment 9 Chuck Ebbert 2008-01-31 00:44:31 UTC
Fixed in 2.6.23.14-125

Comment 10 Fedora Update System 2008-02-11 03:34:08 UTC
kernel-2.6.23.15-137.fc8 has been submitted as an update for Fedora 8

Comment 11 Fedora Update System 2008-02-11 22:38:54 UTC
kernel-2.6.23.15-137.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.


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