[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <534B9F63-E949-4CF5-ACAC-71381190846F@amacapital.net>
Date: Wed, 26 Jun 2019 08:21:05 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Florian Weimer <fweimer@...hat.com>
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
> On Jun 26, 2019, at 8:00 AM, Florian Weimer <fweimer@...hat.com> wrote:
>
> * 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.
>
I’m wondering if we can still do it: add a note or other ELF indicator that says “I don’t need vsyscalls.” Then we can change the default mode to “no vsyscalls if the flag is there, else execute-only vsyscalls”.
Would glibc go along with this? Would enterprise distros consider backporting such a thing?
I
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.
