vsyscall is now disabled on latest Linux distros
25 Nov 2016 18:37:13 UTC
Topic 203129
(moderation:
On latest Linux distros, vsyscall is defaulted to none for security reasons. However, this breaks some very old binaries, including some binaries from this project that are statically-linked against ancient versions of glibc:
[409088.422405] einstein_O1MD1C[24011] vsyscall attempted with vsyscall=none ip:ffffffffff600000 cs:33 sp:7fff00641428 ax:ffffffffff600000 si:0 di:7fff00641490
[409090.299630] einstein_O1MD1C[24012] vsyscall attempted with vsyscall=none ip:ffffffffff600000 cs:33 sp:7ffce7f80868 ax:ffffffffff600000 si:0 di:7ffce7f808d0
.......
[463800.722200] einstein_O1MD1C[8895] vsyscall attempted with vsyscall=none ip:ffffffffff600000 cs:33 sp:7fffa9992df8 ax:ffffffffff600000 si:0 di:7fffa9992e60
I guess you are referring to
)
I guess you are referring to this host
Which distro / kernel (looks like 4.8) you are using?
Exactly.
)
Exactly. Debian stretch/sid
I've seen those errors on my
)
I've seen those errors on my Desktop too after I started the run. This update in Stretch must have happened between the tuning run and now as I've not seen this back then. Currently this happens to only 6% of Linux tasks so I will look into this next week.
Short update on the
)
Short update on the situation:
I tried to work around this problem but there are too many different pieces of the software affected to implement a good workaround. We are investigating ways to build a new application that we send to hosts with a 4.8 kernel version. So far the FGRPB1 application seems to be not affected and I'm not sure why.
If you are running Debian Stretch with the 4.8 kernel you might want to disable the GW search and switch to FGRPB1 in the meantime. This will probably affect other distributions too once they disable vsyscall by default.
From Rosetta forums. Another
)
From Rosetta forums. Another workaround is adding vsyscall=emulate to kernel command line.
... just a guess. don't know
)
... just a guess. don't know whether it's worth the effort:
Christian, is there a way to compile the app in such a way that it's forbidden to use swap and/or tmp-files ?
Juha wrote:From Rosetta
)
That basically resets it to the way it was before the 4.8 update and opens the kernel to attacks. So we don't recommend to use this approach.
That seems to be unrelated to the vsyscall problem but to answer it anyway. No, the application does not know about where the space comes from when it requests memory. It's the task of the operating system to manage memory and usually it does a good job and there is no need for an application to tell the OS what to do and not to do.
This issue reemerged again
)
This issue reemerged again with current Debian testing (buster) and kernel 4.11. If you are running this version please make sure to use the "vsyscall=emulate" workaround. We are working on setting up a build machine that can build apps compatible with buster and older versions.
This is the help text from
)
This is the help text from vsyscall=emulate in the kernel "make menuconfig":
The kernel traps and emulates calls into the fixed vsyscall address mapping. This makes the mapping non-executable, but it still contains known contents, which could be used in certain rare security vulnerability exploits. This configuration is recommended when userspace still uses the vsyscall area.This is for vsyscall=native:
Actual executable code is located in the fixed vsyscall address mapping, implementing time() efficiently. Since this makes the mapping executable, it can be used during security vulnerability exploitation (traditionally as ROP gadgets). This configuration is not recommended.And for vsyscall=none:There will be no vsyscall mapping at all. This will eliminate any risk of ASLR bypass due to the vsyscall fixed address mapping. Attempts to use the vsyscalls will be reported to dmesg, so that either old or malicious userspace programs can be identified.I have to choose one of those three options. Which is recommended for BOINC projects? At present I have vsyscall=emulate in my kernel (the latest stable gentoo sources 4.12.12) and I still get the dmesg notices from this project and from SETI@home. I haven't noticed any from other projects.
--
Rgds
Peter.
In order to activate
)
In order to activate "vsyscall=emulate" you need to restart the PC because this setting is only read at boot time. You also need to maker sure it is in the right place. On current Debian testing I had to add it to /etc/default/grub like this:
GRUB_CMDLINE_LINUX_DEFAULT="quiet vsyscall=emulate"