GNU property saga

[Mark Wielaard]

Hi,

On Mon, 2019-03-04 at 17:25 +0000, Michael Matz wrote:
> I'll admit that I have lost track of the consensus about GNU
> properties and all the discussions last year.  But we want to
> somewhen get this into the psABI document.

Thanks for picking this up. These things have a way of creeping up in
the various code bases without ever really reaching consensus. Causing
sad faces everywhere. Lets see if we can agree on something.

As far as I understand we did reach (a somewhat forced) consensus on
how to represent the IBT and Shadow Stack and Stack Size support which
the current glibc dynamic loader depends on.

The consensus on representation of those properties is described here:
https://sourceware.org/ml/binutils/2018-09/msg00282.html

But there doesn't seem to be any consensus anyon other/new GNU property
features or notes that would require the new (and/or) semantics.
bintuils and glibc don't even agree on the names and values of these
new feature properties.

You already split the discussion of the and/or semantics of those new
property features off into another thread. I think the answer to the
questions you pose below should also be split for the existing GNU
Properties (IBT/SHST/STACK_SIZE) and the new property/note features.

>   I believe there were two points (with subitems) of contentions:
>
> 1) use PT_NOTE vs PT_xxx for program header containing the properties
> 
> I believe the consensus was to use a new PT_xxx value

As far as I understand the current consensus, for the existing property
features, it is actually the opposite. There will be a new PT_NOTE
segment with (for ELFCLASS64) larger alignment and padding. This is
what the current glibc dynamic loader depends on.

But for the new GNU Property features it does seem that people would
prefer to use a new PT_xxx value. There is a new constant in binutils:
#define PT_GNU_PROPERTY	(PT_LOOS + 0x474e553) /* GNU property */
But that isn't used anywhere else.

Question is, if we are going to use that for new GNU Property features,
should we also do that for the old ones and how does that impact the
existing binaries/dynamic libraries?

> 1a) use new SHT_xxx for sections contain such properties
> 
> I believe the consensus was to stay with SHT_NOTE, even though that
> is squarely against ELF spirit.

Yes, for the existing GNU Properties. But I think it would be a bad
idea for the new property features if those will use a new PT value
segment type. Then the rules for composing SHT_NOTEs become even more
complex. You already need to distinguish between existing (GNU) notes
which don't combine with the new (Property) notes because they use
different alignment and padding rules. Then you would also get even
different notes that don't combine with any of the existing ones. At
least, the rules for combining them are not clear to me.

Cheers,

Mark