PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold

[Florian Weimer]

On 08/22/2018 01:02 AM, Cary Coutant wrote:
>>>>> But like you, I don't yet see the value of the 8-byte alignment.  We could
>>>>> decide that the current gold behavior is valid, fix glibc, and move on.
>>>>
>>>> Right. gold seems to produce normal GNU abi ELF Notes, which should
>>>> be accepted as is.
>>>
>>> NT_GNU_PROPERTY_TYPE_0 should stay to follow gABI.
>>
>> That doesn't make any sense. gABI doesn't have a concept of 32bit word
>> ELF notes that are 8-byte aligned. That is just a bug in ld when it
>> generates the note. It also doesn't make sense to generate GNU ELF notes
>> with slightly different padding added depending on type in the same ELF
>> file. That just creates confusion, causes you to define different
>> alignments of notes resulting in extra PT_LOAD segments and results in
>> bugs like we are discussing now where ELF note parsers fail to parse
>> some (valid) notes. Lets just agree that the gold linker is correct and
>> produces consistent GNU abi ELF notes. And lets just fix ld to do the same.
> 
> I thought the outcome of the old discussion on the gABI/psABI mailing
> lists was that there was no value in breaking compatibility by
> introducing an 8-byte aligned note section.

The code for generating them is still in BFD ld and has been there for 
several binutils releases.  <cet.h> in GCC 8 generates 8-byte-aligned 
notes, too.

glibc 2.28 assumes that no 4-byte-aligned PT_NOTE segments contain GNU 
property notes and will search for such notes in 8-byte aligned segments 
only.  The glibc changes were formally reviewed and checked for 
interoperability with BFD ld.  I think we have (had) community consensus 
for them.

We have built and hundreds (if not thousands) of binaries with 
8-byte-aligned notes and shipped them (in Fedora), assuming that there 
was upstream consensus about this x86-64 psABI extension.

> As it is, the psABI definition of the gnu properties note is a
> definitional disaster: like a proper note, it's got three 4-byte words
> (namesz, descsz, and type), followed by the name field (which happens
> to be 4 bytes long in this case), then a desc field. For this note,
> the desc field contains a properties array, where each property has
> two 4-byte values (pr_type and pr_datasz) and a data field padded to a
> multiple of 8 bytes. But it describes the properties array as an array
> of 8-byte words, even though it's really composed of the two 4-byte
> words and an arbitrary-length buffer (which according to the spec, is
> always 8 bytes). Why an 8-byte alignment, though? It doesn't provide
> any conceivable benefit.
> 
> I think gold is doing the right thing by placing the output in a
> 4-byte aligned note section, and combining it with other note sections
> in a 4-byte aligned PT_NOTE segment.

Based on what I've seen, this is a technically feasible option.

But we have existing binaries with 8-byte-aligned notes, and those won't 
go away soon.  There is a cost to having 8-byte-aligned notes (gold 
fixes, elfutils fixes, plenty of other fixes), and to having 
4-byte-aligned notes only (CET-compatible binaries will not be treated 
as such because their 8-byte-aligned PT_NOTE section is invalid).

I don't know if there is anything else that is coming down the pipe 
which would benefit from 8-byte-aligned notes.  Nick has been working on 
.gnu.build.attributes non-allocated note sections.  They are nominally 
4-byte-aligned, but contain 64-bit relocations, but so far, the linker 
has not complained, so maybe this is okay.

> As long as HJ is planning on breaking compatibility with his new
> definition of the x86 properties [1], why not just throw it away and
> do it right? Let's stop using NOTE sections for something they weren't
> designed for, and instead use a special section type and segment type
> (in keeping with existing models like Sun, HP, MIPS, and Arm).

This, too, would invalidate existing binaries.

> Why should the loader have to go parsing everything in a generic PT_NOTE
> segment anyway?

With 8-byte alignment, in practice, it is currently quite fast to 
discover the new notes because the other notes have 4-byte alignment, so 
the PT_NOTE segment with the property notes should be pleasantly short.

Again, maybe we shouldn't have built all those binaries, but we thought 
the binutils community at least was in favor of the 8-byte-aligned 
notes,  This puts me in a difficult decision: The technical facts seem 
to favor 4-byte-aligned notes (but again, there might be further 
features that actually need 8-byte alignment).  But the existing 
binaries with 8-byte-aligned notes provide a strong business 
justification for Red Hat to keep support for the 8-byte-aligned notes.

Thanks,
Florian