linux-kernel - Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKOQZ8xS5-BmoX2QeONbmJuSMZvL1fLoxkgyoVy5mpFWziZ3Dg@mail.gmail.com>
Date:	Tue, 1 Sep 2015 18:12:12 -0700
From:	Ian Lance Taylor <iant@...gle.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Kees Cook <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	libc-alpha <libc-alpha@...rceware.org>,
	"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
	GCC Development <gcc@....gnu.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 5:51 PM, Andy Lutomirski <luto@...capital.net> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/