Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold

[Florian Weimer <fweimer at redhat dot com>]

On 08/16/2018 03:19 PM, H.J. Lu wrote:
> On Thu, Aug 16, 2018 at 6:00 AM, Florian Weimer <fweimer@redhat.com> wrote:
> > On 08/07/2018 10:41 PM, H.J. Lu wrote:
> > > The .note.gnu.property section with NT_GNU_PROPERTY_TYPE_0 has been
> > > added to Linux Extensions to gABI:
> > >
> > > https://github.com/hjl-tools/linux-abi
> > >
> > > GNU_PROPERTY_X86_ISA_1_USED and GNU_PROPERTY_X86_ISA_1_NEEDED are
> > > processor-specific program property types for i386 and x86-64.
> >
> >
> > The specification is incomplete as far as alignment matters are concerned.
>
> https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf
>
> has
>
> 2.1.7 Alignment of Note Sections
>
> All entries in a PT_NOTE segment have the same alignment which equals to the
> p_align field in program header.
> According to gABI, each note entry should be aligned to 4 bytes in 32-bit
> objects or 8 bytes in 64-bit objects. But .note.ABI-tag section (see
> Section 2.1.6) and .note.gnu.build-id section (see Section 2.1.4) are
> aligned
> to 4 bytes in both 32-bit and 64-bit objects. Note parser should use p_align for
> note alignment, instead of assuming alignment based on ELF file class.

This is still ambiguous, particularly based on your comments below.

> > Is the link editor supposed to maintain separate segments for notes with
> > different alignments?  Or is it possible to merge the notes into a single
> > segment, potentially after adjusting alignment?
>
> It is possible.  We just need to place 4-byte aligned notes after 8-byte
> aligned notes.

Based on section 2.1.7, this would not be valid by itself because the 
section needs to have 8-byte alignment (to satisfy the property notes 
requirement).  All notes in the segment need to have the same alignment 
(because p_align is supposed to be used for parsing).  So reordering 
alone will not produce a valid segment.

Part of the problem is that the note header is 12 bytes (not a multiple 
of 8), and that the name and descriptor lengths do not include the 
padding (which makes sense), so you really need a correct source of 
alignment.

If we want to generate a single segment (and I think we should), we need 
to realign the notes to a common alignment, either 4 or 8 bytes.  That's 
what gold seems todo right now, with 4-byte alignment.

> > Is the link editor *required* to produce 8-byte alignment for notes in
> > ELFCLASS64 objects?
>
> It is decided by the alignment of NOTE section, not by linker.
>
> > Currently, we do not have agreement between binutils (particularly gold) and
> > the glibc dynamic loader when it comes to alignment of PT_NOTE segments.
> > glibc will disregard property notes in ELFCLASS64 objects which have 4-byte
> > alignment, but gold produces such notes.  This needs to be fixed.
>
> I don't believe this is true.  See above.

Which part?  I see the 4-byte segment alignment with gold from 
binutils-2.31.1-11.fc29.x86_64.

> After this commit:
>
> commit 8d81ce0c6d6ca923571e8b2bac132929f9a02973
> Author: H.J. Lu <hjl.tools@gmail.com>
> Date:   Tue Nov 28 09:56:47 2017 -0800
>
>      Properly compute offsets of note descriptor and next note [BZ #22370]
…
> glibc can handle both 4 byte and 8 byte NOTE alignments.

There's still this code in glibc, in sysdeps/x86/dl-prop.h:

  /* The NT_GNU_PROPERTY_TYPE_0 note must be aliged to 4 bytes in
     32-bit objects and to 8 bytes in 64-bit objects.  Skip notes
     with incorrect alignment.  */
  if (align != (__ELF_NATIVE_CLASS / 8))
    return;

Thanks,
Florian