On Mon, Jun 10, 2019 at 07:24:43PM +0200, Florian Weimer wrote: > * Yu-cheng Yu: > > > To me, looking at PT_GNU_PROPERTY and not trying to support anything is a > > logical choice. And it breaks only a limited set of toolchains. > > > > I will simplify the parser and leave this patch as-is for anyone who wants to > > back-port. Are there any objections or concerns? > > Red Hat Enterprise Linux 8 does not use PT_GNU_PROPERTY and is probably > the largest collection of CET-enabled binaries that exists today. For clarity, RHEL is actively parsing these properties today? > My hope was that we would backport the upstream kernel patches for CET, > port the glibc dynamic loader to the new kernel interface, and be ready > to run with CET enabled in principle (except that porting userspace > libraries such as OpenSSL has not really started upstream, so many > processes where CET is particularly desirable will still run without > it). > > I'm not sure if it is a good idea to port the legacy support if it's not > part of the mainline kernel because it comes awfully close to creating > our own private ABI. I guess we can aim to factor things so that PT_NOTE scanning is available as a fallback on arches for which the absence of PT_GNU_PROPERTY is not authoritative. Can we argue that the lack of PT_GNU_PROPERTY is an ABI bug, fix it for new binaries and hence limit the efforts we go to to support theoretical binaries that lack the phdrs entry? If we can make practical simplifications to the parsing, such as limiting the maximum PT_NOTE size that we will search for the program properties to 1K (say), or requiring NT_NOTE_GNU_PROPERTY_TYPE_0 to sit by itself in a single PT_NOTE then that could help minimse the exec overheads and the number of places for bugs to hide in the kernel. What we can do here depends on what the tools currently do and what binaries are out there. Cheers ---Dave
