vsyscall is now disabled on latest Linux distros

dword1511
dword1511
Joined: 17 Aug 06
Posts: 2
Credit: 87321519
RAC: 0
Topic 203129

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

AgentB
AgentB
Joined: 17 Mar 12
Posts: 915
Credit: 513211304
RAC: 0

I guess you are referring to

I guess you are referring to this host 

Which distro / kernel (looks like 4.8) you are using?

 

dword1511
dword1511
Joined: 17 Aug 06
Posts: 2
Credit: 87321519
RAC: 0

Exactly.

Exactly. Debian stretch/sid

Christian Beer
Christian Beer
Joined: 9 Feb 05
Posts: 595
Credit: 118587687
RAC: 110897

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.

Christian Beer
Christian Beer
Joined: 9 Feb 05
Posts: 595
Credit: 118587687
RAC: 110897

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.

Juha
Juha
Joined: 27 Nov 14
Posts: 49
Credit: 4962246
RAC: 23

From Rosetta forums. Another

From Rosetta forums. Another workaround is adding vsyscall=emulate to kernel command line.

22
22
Joined: 6 Nov 11
Posts: 14
Credit: 757787830
RAC: 3878

... 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 ?

Christian Beer
Christian Beer
Joined: 9 Feb 05
Posts: 595
Credit: 118587687
RAC: 110897

Juha wrote:From Rosetta

Juha wrote:
From Rosetta forums. Another workaround is adding vsyscall=emulate to kernel command line.

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.

22 wrote:

... 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 ?

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.

Christian Beer
Christian Beer
Joined: 9 Feb 05
Posts: 595
Credit: 118587687
RAC: 110897

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.

UnionJack
UnionJack
Joined: 9 Feb 05
Posts: 15
Credit: 69898100
RAC: 17714

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.

Christian Beer
Christian Beer
Joined: 9 Feb 05
Posts: 595
Credit: 118587687
RAC: 110897

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"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.