|
Message-ID: <CAMzpN2h+yWD0qHz=3WX1bsYOjn9okYo6AyiwmgFzzFwUvGhZMA@mail.gmail.com> Date: Wed, 2 Sep 2015 09:57:26 -0400 From: Brian Gerst <brgerst@...il.com> To: Andy Lutomirski <luto@...capital.net> Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Kees Cook <keescook@...omium.org>, gcc@....gnu.org, libc-alpha <libc-alpha@...rceware.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Binutils <binutils@...rceware.org> Subject: Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers? On Tue, Sep 1, 2015 at 10:21 PM, Andy Lutomirski <luto@...capital.net> wrote: > On Sep 1, 2015 6:53 PM, "Brian Gerst" <brgerst@...il.com> wrote: >> >> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski <luto@...capital.net> wrote: >> > Hi all- >> > >> > Linux has a handful of weird features that are only supported for >> > backwards compatibility. The big one is the x86_64 vsyscall page, but >> > uselib probably belongs on the list, too, and we might end up with >> > more at some point. >> > >> > I'd like to add a way that new programs can turn these features off. >> > In particular, I want the vsyscall page to be completely gone from the >> > perspective of any new enough program. This is straightforward if we >> > add a system call to ask for the vsyscall page to be disabled, but I'm >> > wondering if we can come up with a non-syscall way to do it. >> > >> > I think that the ideal behavior would be that anything linked against >> > a sufficiently new libc would be detected, but I don't see a good way >> > to do that using existing toolchain features. >> > >> > Ideas? We could add a new phdr for this, but then we'd need to play >> > linker script games, and I'm not sure that could be done in a clean, >> > extensible way. >> >> >> The vsyscall page is mapped in the fixmap region, which is shared >> between all processes. You can't turn it off for an individual >> process. > > Why not? > > We already emulate all attempts to execute it, and that's trivial to > turn of per process. Project Zero pointed out that read access is a > problem, too, but we can flip the U/S bit in the pgd once we evict > pvclock from the fixmap. > > And we definitely need to evict pvclock from the fixmap regardless. Sure, you can turn off emulation per-process. But the page mapping will be the same for every process because it is in the kernel part of the page tables which is shared by all processes. -- Brian Gerst
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.