[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v9wty9v4.fsf@oldenburg2.str.redhat.com>
Date: Tue, 25 Jun 2019 17:15:27 +0200
From: Florian Weimer <fweimer@...hat.com>
To: linux-api@...r.kernel.org, kernel-hardening@...ts.openwall.com, linux-x86_64@...r.kernel.org, linux-arch@...r.kernel.org
Cc: Andy Lutomirski <luto@...nel.org>, Kees Cook <keescook@...omium.org>, Carlos O'Donell <carlos@...hat.com>
Subject: Detecting the availability of VSYSCALL
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.
Is there any reliable way to detect that VSYSCALL is unavailable,
without resorting to parsing /proc/self/maps or opening file
descriptors?
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.
Thanks,
Florian
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.
