Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Sep 2, 2015 6:57 AM, "Brian Gerst" wrote: > > On Tue, Sep 1, 2015 at 10:21 PM, Andy Lutomirski wrote: > > On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote: > >> > >> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski > >> 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. True, but I don't think that means that the mapping has to be readable in all processes. Once it's the only user-readable mapping in the top 512 GB, we can turn off user access to the whole top 512 GB. The only other user accessible thing in the top 512GB (and the only other user accessible thing in a kernel address at all) is the KVM pvclock mapping. We should turn that off, too, because it's exploitable in more or less the same way as the vsyscall page. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 wrote: > On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote: >> >> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Sep 1, 2015 6:12 PM, "Ian Lance Taylor" wrote: > > On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote: > > > > 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. > > What sets up the vsyscall page, and what information does it have > before doing so? > > I'm guessing it's the kernel that sets it up, and that all it can see > at that point is the program headers. Currently it's global and nothing thinks about it per-process at all. The kernel can do whatever it likes going forward, subject to backwards compatibility. Doing something at ELF load time is probably the right approach. > > We could pass information using an appropriate note section. My > recollection is that the linkers will turn an SHF_ALLOC note section > into a PT_NOTE program header. Oh, interesting. I'll check that. Glibc and competitors could add notes to their statically-linked bits. The unpleasant case is a new dynamic binary linked against an old libc, but that might be irrelevant in practice. After all, I think that a lot of libc competitors never supported the vsyscall page at all, and even glibc isn't really backwards compatible that way. We could also require that both the binary and interpreter have the note, which would more or less solve the backwards compatibility issue. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote: > > On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski 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. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski 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. -- Brian Gerst -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote: > > 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. What sets up the vsyscall page, and what information does it have before doing so? I'm guessing it's the kernel that sets it up, and that all it can see at that point is the program headers. We could pass information using an appropriate note section. My recollection is that the linkers will turn an SHF_ALLOC note section into a PT_NOTE program header. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
