[PATCH v5 07/12] aarch64: enable BTI at runtime

H.J. Lu hjl.tools@gmail.com
Fri Jun 19 13:03:16 GMT 2020


On Fri, Jun 19, 2020 at 5:32 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 06/18/2020 13:16, H.J. Lu wrote:
> > On Thu, Jun 18, 2020 at 8:38 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > >
> > > The 06/12/2020 08:18, H.J. Lu wrote:
> > > > On Fri, Jun 12, 2020 at 8:08 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > > > > The 06/12/2020 06:43, H.J. Lu wrote:
> > > > > > Can you make _dl_process_pt_gnu_property more generic so that it
> > > > > > can be shared with x86?  If there is PT_GNU_PROPERTY, we don't
> > > > > > need to check for multiple property notes.  Thanks.
> > > > >
> > > > > it can use a hook for NT_GNU_PROPERTY_TYPE_0 notes
> > > > > that is called for each property, e.g.
> > > > >
> > > > > int
> > > > > _dl_process_gnu_property_note0(uint32_t type, uint32_t datasz, const void *data);
> > >
> > > i also had to pass the link_map.
> > >
> > > > > however this only helps on x86 if PT_GNU_PROPERTY
> > > > > processing is before PT_NOTE processing otherwise
> > > > > you cannot skip handling the notes.
> > > >
> > > > On x86-64, there are
> > > >
> > > > Program Headers:
> > > >   Type           Offset             VirtAddr           PhysAddr
> > > >                  FileSiz            MemSiz              Flags  Align
> > > ...
> > > >   NOTE           0x0000000000000338 0x0000000000000338 0x0000000000000338
> > > >                  0x0000000000000020 0x0000000000000020  R      0x8
> > > >   NOTE           0x0000000000000358 0x0000000000000358 0x0000000000000358
> > > >                  0x0000000000000044 0x0000000000000044  R      0x4
> > > >   GNU_PROPERTY   0x0000000000000338 0x0000000000000338 0x0000000000000338
> > > >                  0x0000000000000020 0x0000000000000020  R      0x8
> > > ...
> > > > Only the PT_NOTE segment with the correct alignment may contain property.
> > > > In the first pass, we record such PT_NOTE segment, but don't process it.
> > > > After all segments have been processed, we process the saved PT_NOTE segment
> > > > if there is no GNU_PROPERTY segment.
> > >
> > > i refactored the code but didn't change the x86 side.
> > >
> > > note: in rtld there is only one pass (load segments
> > > are already mapped) while dlopen does the property
> > > handling in the second pass over program headers.
> > >
> > > attaching v5 of the patch:
> > >
> > > - moved _dl_process_pt_gnu_property to generic code
> > >   (into dl-load.c), this assumes PT_GNU_PROPERTY
> > >   is a gnu platform abi and the integer types used
> > >   for accessing it work on all targets.
> > >
> > > - made _dl_process_pt_gnu_property return type void
> > >   and remove all failure handling (invalid notes
> > >   are ignored).
> > >
> > > - only handle one NT_GNU_PROPERTY_TYPE_0.
> > >
> > > - added _dl_process_gnu_property target hook.
> > >
> > > - removed reviewed-by because of significant changes.
> > >
> > > tested on aarch64.
> > >
> >
> > Can you incorporate this patch into yours?
> >
> > The old _dl_process_pt_note and _rtld_process_pt_note differ in how
> > the program header is read.  The old _dl_process_pt_note is called
> > before PT_LOAD segments are mapped and _rtld_process_pt_note is called
> > after PT_LOAD segments are mapped.  Since PT_GNU_PROPERTY is processed
> > after PT_LOAD segments are mapped, we can process PT_NOTE together with
> > PT_GNU_PROPERTY.  We can remove the old _dl_process_pt_note and rename
> > _rtld_process_pt_note to _dl_process_pt_note.
> >
> > NOTE: We scan program headers backward so that PT_NOTE can be skipped
> > if PT_GNU_PROPERTY exits.
>
> this makes sense to me and it can be a follow up
> patch on top of my PT_GNU_PROPERTY patch, it
> does not have to be integrated. (it's not ideal
> to intergate it with the bti enablement, so i
> would have to split that patch to do the property
> things and bti things separately)
>

My patch deletes/renames codes just added by your patch.
Can you split your patch into 2 and incorporate my patch with
the first one?

Thanks.

-- 
H.J.


More information about the Libc-alpha mailing list