Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.