Arch Linux

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