From: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
To: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
X86 ML <x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Pondering per-process vsyscall disablement
Date: Thu, 22 May 2014 16:04:22 -0700 [thread overview]
Message-ID: <CALCETrX4-qooSyLw3=zHGcMoWqQ2ozPB_WtKU2AtkMei-XZOUA@mail.gmail.com> (raw)
It would be nice to have a way for new programs to declare that they
don't need vsyscalls. What's the right way to do this? An ELF header
entry in the loader? An ELF header entry in the program? A new
arch_prctl?
As background, there's an old part of the x86_64 ABI that allows
programs to do gettimeofday, clock_gettime, and getcpu by calling to
fixed addresses of the form 0xffffffffff600n00 where n indicates which
of those three syscalls is being invoked. This is a security issue.
Since Linux 3.1, vsyscalls are emulated using NX and page faults. As
a result, vsyscalls no longer offer any performance advantage over
normal syscalls; in fact, they're much slower. As far as I know,
nothing newer than 2012 will attempt to use vsyscalls if a vdso is
present. (Sadly, a lot of things will still fall back to the vsyscall
page if there is no vdso, but that shouldn't matter, since there is
always a vdso.)
Despite the emulation, they could still be used as a weird form of ROP
gadget that lives at a fixed address. I'd like to offer a way for new
runtimes to indicate that they don't use vsyscalls so that the kernel
can selectively disable emulation and remove the fixed-address
executable code issue.
--Andy
next reply other threads:[~2014-05-22 23:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 23:04 Andy Lutomirski [this message]
2014-05-23 2:44 ` Pondering per-process vsyscall disablement Marian Marinov
[not found] ` <537EB60E.40204-108MBtLGafw@public.gmane.org>
2014-05-23 16:40 ` Andy Lutomirski
[not found] ` <CALCETrWgtQCRiHt+am8+DoOMVvTuxy05AB6zzg3iAheGs13L6A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-28 21:45 ` H. Peter Anvin
[not found] ` <538658EE.8030809-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2014-05-30 20:00 ` Andy Lutomirski
2014-05-30 20:05 ` H. Peter Anvin
[not found] ` <5388E499.6080101-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2014-05-30 20:11 ` Andy Lutomirski
[not found] ` <CALCETrX9s7xJRddB26ZiyjMEGbupbDj2qDHhio=80XSQ+staDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-05-30 20:20 ` H. Peter Anvin
[not found] ` <5388E814.1080504-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>
2014-05-30 20:35 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALCETrX4-qooSyLw3=zHGcMoWqQ2ozPB_WtKU2AtkMei-XZOUA@mail.gmail.com' \
--to=luto-klttt9wpgjjwatoyat5jvq@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).