[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1906251824500.32342@nanos.tec.linutronix.de>
Date: Tue, 25 Jun 2019 18:30:29 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Florian Weimer <fweimer@...hat.com>
cc: linux-api@...r.kernel.org, kernel-hardening@...ts.openwall.com,
linux-x86_64@...r.kernel.org, linux-arch@...r.kernel.org,
Andy Lutomirski <luto@...nel.org>, Kees Cook <keescook@...omium.org>,
Carlos O'Donell <carlos@...hat.com>, x86@...nel.org
Subject: Re: Detecting the availability of VSYSCALL
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.
> Is there any reliable way to detect that VSYSCALL is unavailable,
> without resorting to parsing /proc/self/maps or opening file
> descriptors?
Not that I'm aware of except
sigaction(SIG_SEGV,....)
/me hides
> Should we try mapping something at the magic address (without MAP_FIXED)
> and see if we get back a different address? Something in the auxiliary
> vector would work for us, too, but nothing seems to exists there
> unfortunately.
Would, but there is no such thing.
Thanks,
tglx
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.
