This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V2 [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 20 Sep 2018 05:36:49 -0700
- Subject: Re: V2 [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
- References: <CAMe9rOoXP7fz+XaM5hFnzDa=qSzz=8r3HkoddaTscrh7HUt03g@mail.gmail.com> <87a7ocmtvd.fsf@oldenburg.str.redhat.com>
On Thu, Sep 20, 2018 at 1:54 AM, Florian Weimer <fweimer@redhat.com> wrote:
> * H. J. Lu:
>
>> From e1c6cdeb7530c37ddb6688b17435c1c9a373a09c Mon Sep 17 00:00:00 2001
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>> Date: Fri, 10 Aug 2018 18:43:22 -0700
>> Subject: [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
>>
>> The older linker treats .note.gnu.property section as a generic note
>> section and just concatenates all .note.gnu.property sections from the
>> inputs to the output. When the older linker is used to created the
>> program on CET-enabled OS, the generated output has .note.gnu.property
>> section with multiple NT_GNU_PROPERTY_TYPE_0 notes whose IBT and SHSTK
>> enable bits are set even if the program isn't CET enabled. Such program
>> will crash on CET-enabled machines. This patch updates the note parser:
>>
>> 1. Skip note parsing if a NT_GNU_PROPERTY_TYPE_0 note has been processed.
>> 2. Check multiple NT_GNU_PROPERTY_TYPE_0 notes.
>>
>> [BZ #23509]
>> * sysdeps/x86/dl-prop.h (_dl_process_cet_property_note): Skip
>> note parsing if a NT_GNU_PROPERTY_TYPE_0 note has been processed.
>> Update the l_cet field when processing NT_GNU_PROPERTY_TYPE_0 note.
>> Check multiple NT_GNU_PROPERTY_TYPE_0 notes.
>> * sysdeps/x86/link_map.h (l_cet): Expand to 3 bits, Add
>> lc_unknown.
>
> As far as I can tell, this patch catches only the case where a single
> PT_NOTE segment contains multiple notes. If there are multiple PT_NOTE
> segments with notes, and each one contains a single note, the patch will
> still enable CET.
I believe this is covered by CET smoke test:
https://github.com/hjl-tools/cet-smoke-test
My patch should work in all cases. If it misses some cases, please add it
to master branch at
https://github.com/hjl-tools/cet-smoke-test
under the "note" directory.
> Is my summary accurate? Do you think it is safe to treat PT_NOTE
> segments in isolation?
What do you mean by that? The only assumption I made is that
property note must follow the spec. Any violation makes it invalid.
> If yes, this should be mentioned in the commit message.
>
> This seems to be an unrelated change?
>
> + /* Property type must be in ascending order. */
> + if (type < last_type)
> + return;
>
This is the part of property spec. If properties aren't properly
sorted, it is invalid.
--
H.J.