Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linux: disable vsyscalls by default #25289

Closed
wants to merge 1 commit into from

Conversation

joachifm
Copy link
Contributor

Per the CONFIG_LEGACY_VSYSCALL_NONE description:

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.

Users that rely on the old behavior can enable it at boot time via
boot.kernelParams = [ "vsyscall=emulate" ] (or native for the bold).

This change is on the paranoid side, as vsyscall=emulate is intended to
be safe in the sense that an attacker shouldn't be able to benefit from
knowing the address mapping ahead of time.

An alternative to this is to just add vsyscall=none to the hardened profile. Either way is fine by me.

Per the CONFIG_LEGACY_VSYSCALL_NONE description:

   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.

Users that rely on the old behavior can enable it at boot time via
`boot.kernelParams = [ "vsyscall=emulate" ]` (or `native` for the bold).

This change is on the paranoid side, as `vsyscall=emulate` is intended to
be safe in the sense that an attacker shouldn't be able to benefit from
knowing the address mapping ahead of time.
@mention-bot
Copy link

@joachifm, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @dezgeg and @wkennington to be potential reviewers.

@joachifm
Copy link
Contributor Author

Some background on virtual syscalls: https://lwn.net/Articles/446528/

@copumpkin
Copy link
Member

What are the performance implications, if any?

@joachifm
Copy link
Contributor Author

My understanding is that non-legacy shouldn't use vsyscalls, recent glibc use vDSO instead.

@joachifm
Copy link
Contributor Author

joachifm commented Apr 28, 2017

I believe that implies that statically linked programs that rely on virtual syscalls flat out won't work with this.

@dezgeg
Copy link
Contributor

dezgeg commented Apr 28, 2017

FWIW matches my understanding as well (that glibc can still locate the VDSO via auxv).

@dezgeg
Copy link
Contributor

dezgeg commented Apr 28, 2017

Hmm I wouldn't imagine this specifically affects statically linked programs, just programs linked against very old glibcs...

@edolstra
Copy link
Member

I have no strong feelings about this, but it does seem that the "emulate" behaviour is already secure enough. So it might be more appropriate to add this to the hardened profile.

If I read that LWN article correctly, this will break programs using a Glibc from before around 2011. (Not just statically linked programs BTW, any Nix closure containing an old Glibc will also break.)

@joachifm
Copy link
Contributor Author

Alright, I'll probably add this to the profile instead

@joachifm
Copy link
Contributor Author

@dezgeg you could very well be right, I merely inferred from the name that it might not play well with static linking :)

@joachifm joachifm closed this in 6343353 Apr 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants