This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 427641 - exec-shield GPF handler vs fixmap vDSO
exec-shield GPF handler vs fixmap vDSO
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-05 23:24 EST by John Reiser
Modified: 2011-12-13 17:28 EST (History)
5 users (show)

See Also:
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 17:39:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Reiser 2008-01-05 23:24:52 EST
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-05 23:26:10 EST
Also present in kernel-2.6.23.12-52.fc7.
Comment 2 Jon Stanley 2008-01-06 13:57:23 EST

*** This bug has been marked as a duplicate of 375681 ***
Comment 3 John Reiser 2008-01-06 15:04:29 EST
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 15:39:09 EST
(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 13:42:00 EST
(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 18:57:36 EST
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-29 21:07:20 EST
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-29 21:17:24 EST
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-30 19:44:31 EST
Fixed in 2.6.23.14-125
Comment 10 Fedora Update System 2008-02-10 22:34:08 EST
kernel-2.6.23.15-137.fc8 has been submitted as an update for Fedora 8
Comment 11 Fedora Update System 2008-02-11 17:38:54 EST
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.