Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#57462 - [linux] Re-enable CONFIG_X86_VSYSCALL_EMULATION

Attached to Project: Arch Linux
Opened by Mauro Santos (R00KIE) - Saturday, 10 February 2018, 16:37 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 10 February 2018, 16:41 GMT
Task Type Feature Request
Category Kernel
Status Closed
Assigned To No-one
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Kernel 4.15.X seems to be breaking some docker containers[1] and also breaks chroots.

I have tracked the problem to the change made to CONFIG_X86_VSYSCALL_EMULATION. Before it was enabled, now it is disabled. There was also a change in the default of the emulation type but more on that later.

This can be hard to debug or figure out if you don't know what you are looking for. When I attempt to chroot into a directory containing centos 5, on the terminal I get an error and in the output of dmesg there is only this:

bash[30482]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007ffe93bdcdc8 error 15

I have recompiled the kernel with CONFIG_X86_VSYSCALL_EMULATION=y but kept CONFIG_LEGACY_VSYSCALL_NONE=y, trying to chroot results in the same error in the terminal but this time there is an extra tidbit of information in the output of dmesg:

bash[861] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffe838e06e8 ax:ffffffffff600400 si:7ffe838e2948 di:0
bash[861]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007ffe838e06e8 error 15

Passing vsyscall=emulate in the kernel command line makes things work without any warnings or problems.

The description here[2] says: "This enables emulation of the legacy vsyscall page. Disabling it is roughly equivalent to booting with vsyscall=none, except that it will also disable the helpful warning if a program tries to use a vsyscall.".

Except for the slightly increased runtime pagetable memory usage I'd say that turning X86_VSYSCALL_EMULATION back on and keeping the default as LEGACY_VSYSCALL_NONE=y should not hurt security wise but has two advantages:
- Provides an obvious clue in the output of dmesg as to what the problem is.
- There is a way to easily re-enable it without having to recompile the whole kernel for users who need this feature.

[1] https://bbs.archlinux.org/viewtopic.php?id=234282
[2] https://cateee.net/lkddb/web-lkddb/X86_VSYSCALL_EMULATION.html
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 10 February 2018, 16:41 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#57336   FS#57423   FS#57446 

Loading...