linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marian Marinov <mm@1h.com>
To: Andy Lutomirski <luto@amacapital.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	X86 ML <x86@kernel.org>, Linux API <linux-api@vger.kernel.org>
Subject: Re: Pondering per-process vsyscall disablement
Date: Fri, 23 May 2014 05:44:30 +0300	[thread overview]
Message-ID: <537EB60E.40204@1h.com> (raw)
In-Reply-To: <CALCETrX4-qooSyLw3=zHGcMoWqQ2ozPB_WtKU2AtkMei-XZOUA@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/23/2014 02:04 AM, Andy Lutomirski wrote:
> 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.
> 
> 
Wouldn't it be more useful if the check is against a bitmask added as extended attribute for that executable?
This way the administrators and will have the flexibility to simply add the new attribute to the executable.

Marian

> --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html Please read the FAQ at
> http://www.tux.org/lkml/
> 


- -- 
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hackman@jabber.org
ICQ: 7556201
Mobile: +359 886 660 270
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlN+tg4ACgkQ4mt9JeIbjJRGkgCgjnD2s+J9kIr5oEDeL3VKHNvX
X4cAn17zC0aPKyTCVekmqZRlVukqLWyC
=vrfk
-----END PGP SIGNATURE-----

  reply	other threads:[~2014-05-23  2:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 23:04 Pondering per-process vsyscall disablement Andy Lutomirski
2014-05-23  2:44 ` Marian Marinov [this message]
     [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=537EB60E.40204@1h.com \
    --to=mm@1h.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=x86@kernel.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).