[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVh1f5wJNMbMoVqY=bq-7G=uQ84BUkepf5RksA3vUopNQ@mail.gmail.com>
Date: Tue, 25 Jun 2019 13:11:25 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Linux API <linux-api@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, linux-x86_64@...r.kernel.org,
linux-arch <linux-arch@...r.kernel.org>, Andy Lutomirski <luto@...nel.org>,
Kees Cook <keescook@...omium.org>, "Carlos O'Donell" <carlos@...hat.com>, X86 ML <x86@...nel.org>
Subject: Re: Detecting the availability of VSYSCALL
On Tue, Jun 25, 2019 at 9:39 AM Florian Weimer <fweimer@...hat.com> wrote:
>
> * Thomas Gleixner:
>
> > On Tue, 25 Jun 2019, Florian Weimer wrote:
> >> We're trying to create portable binaries which use VSYSCALL on older
> >> kernels (to avoid performance regressions), but gracefully degrade to
> >> full system calls on kernels which do not have VSYSCALL support compiled
> >> in (or disabled at boot).
> >>
> >> For technical reasons, we cannot use vDSO fallback. Trying vDSO first
> >> and only then use VSYSCALL is the way this has been tackled in the past,
> >> which is why this userspace ABI breakage goes generally unnoticed. But
> >> we don't have a dynamic linker in our scenario.
> >
> > I'm not following. On newer kernels which usually have vsyscall disabled
> > you need to use real syscalls anyway, so why are you so worried about
> > performance on older kernels. That doesn't make sense.
>
> We want binaries that run fast on VSYSCALL kernels, but can fall back to
> full system calls on kernels that do not have them (instead of
> crashing).
Define "VSYSCALL kernels." On any remotely recent kernel (*all* new
kernels and all kernels for the last several years that haven't
specifically requested vsyscall=native), using vsyscalls is much, much
slower than just doing syscalls. I know a way you can tell whether
vsyscalls are fast, but it's unreliable, and I'm disinclined to
suggest it. There are also at least two pending patch series that
will interfere.
>
> We could parse the vDSO and prefer the functions found there, but this
> is for the statically linked case. We currently do not have a (minimal)
> dynamic loader there in that version of the code base, so that doesn't
> really work for us.
Is anything preventing you from adding a vDSO parser? I wrote one
just for this type of use:
$ wc -l tools/testing/selftests/vDSO/parse_vdso.c
269 tools/testing/selftests/vDSO/parse_vdso.c
(289 lines includes quite a bit of comment.)
$ head -n8 tools/testing/selftests/vDSO/parse_vdso.c
/*
* parse_vdso.c: Linux reference vDSO parser
* Written by Andrew Lutomirski, 2011-2014.
*
* This code is meant to be linked in to various programs that run on Linux.
* As such, it is available with as few restrictions as possible. This file
* is licensed under the Creative Commons Zero License, version 1.0,
* available at http://creativecommons.org/publicdomain/zero/1.0/legalcode
If this license is too restrictive for you, I could probably be
convinced to relicense it, I'd be surprised :) In hindsight, I kind
of wish I'd used MIT instead, since the Go runtime took advantage of
the CC0 license to import it without attribution *and* break it quite
badly in the process.
IMO the correct solution is to parse the vDSO and, if that fails, to
use plain syscalls as a fallback. You should not ship anything that
uses a vsyscall under any circumstances, unless you need the last
ounce of performance on that one ancient version of OpenSuSE that
crashes if the vDSO is enabled.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
