[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r27gjss3.fsf@oldenburg2.str.redhat.com>
Date: Wed, 26 Jun 2019 17:00:28 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Andy Lutomirski <luto@...nel.org>, 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>, Kees Cook <keescook@...omium.org>, Carlos O'Donell <carlos@...hat.com>, X86 ML <x86@...nel.org>
Subject: Re: Detecting the availability of VSYSCALL
* Andy Lutomirski:
> I didn’t add a flag because the vsyscall page was thoroughly obsolete
> when all this happened, and I wanted to encourage all new code to just
> parse the vDSO instead of piling on the hacks.
It turned out that the thorny cases just switched to system calls
instead. I think we finally completed the transition in glibc upstream
in 2018 (for x86).
> Anyway, you may be the right person to ask: is there some credible way
> that the kernel could detect new binaries that don’t need vsyscalls?
> Maybe a new ELF note on a static binary or on the ELF interpreter? We
> can dynamically switch it in principle.
For this kind of change, markup similar to PT_GNU_STACK would have been
appropriate, I think: Old kernels and loaders would have ignored the
program header and loaded the program anyway, but the vsyscall page
still existed, so that would have been fine. The kernel would have
needed to check the program interpreter or the main executable (without
a program interpreter, i.e., the statically linked case). Due the way
the vsyscalls are concentrated in glibc, a dynamically linked executable
would not have needed checking (or re-linking). I don't think we would
have implemented the full late enablement after dlopen we did for
executable stacks. In theory, any code could have jumped to the
vsyscall area, but in practice, it's just dynamically linked glibc and
static binaries.
But nowadays, unmarked glibcs which do not depend on vsyscall vastly
outnumber unmarked glibcs which requrie it. Therefore, markup of
binaries does not seem to be reasonable to day. I could imagine a
personality flag you can set (if yoy have CAP_SYS_ADMIN) that re-enables
vsyscall support for new subprocesses. And a container runtime would do
this based on metadata found in the image. This way, the container host
itself could be protected, and you could still run legacy images which
require vsyscall.
For the non-container case, if you know that you'll run legacy
workloads, you'd still have the boot parameter. But I think it could
default to vsyscall=none in many more cases.
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.
