GNU property saga

[Mark Wielaard]

On Tue, 2019-05-07 at 15:29 +0000, Szabolcs Nagy wrote:
> On 20/03/2019 14:51, Mark Wielaard wrote:
> > 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?
> 
> what is a "new gnu property feature"?

The original GNU Properties were just for Control Flow Enforcement
(STACK_SIZE, NO_COPY_ON_PROTECTED and X86_FEATUREs IBT and SHSTK).
Those are in a special aligned SHT_NOTE section and PT_NOTE segment
with adjusted padding. These are recognized by the glibc dynamic loader
and some other tools.

There are also some new experimental properties, the X86_ISA Needed and
Used cpu instruction sets. For these new properties there doesn't seem
to be any consensus. binutils and glibc define some of them with
similar (but not always equal) GNU_PROPERTY names, but different
constants. There is discussion how the used and needed bits should be
interpreted (what if there is no such flag), see the other thread for a
discussion of that. And binutils seems to put them in a new
PT_GNU_PROPERTY segment which isn't recognized by anything else.

> if PT_GNU_PROPERTY is preferred, then aarch64 should use that.
> (aarch64 now uses gnu properties as well, but it does not have
> legacy binaries yet to be compatible with, only code in bfd
> that can be still fixed.)
> 
> but if current elf loaders/linkers only support PT_NOTE then
> switching to PT_GNU_PROPERTY may be messy (?)

Indeed. We first need consensus on all the issues above.

> > > 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.
> 
> that tells me PT_NOTE and SHT_NOTE for gnu properties
> should be left as they are today?

Yes, I think it would be best to keep with that for the original (CET
control flow related) GNU Properties.

But maybe for new ISA/cpuset used/needed instruction set properties we
should keep them separate and just start over and define a new
SHT_GNU_PROPERTIES and PT_GNU_PROPERTIES format.

Cheers,

Mark