GNU property saga

GNU property saga

[Michael Matz]

Hello,

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.  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

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.

2) semantics of individual ranges of the GNU_PROPERTY_xxx value.

Basically the properties are split into three ranges, where each 
individual member represents itself a set of 32 members (via an uint32) 
representing a feature/property each.  The semantics of the higher level 
(the three ranges) are a fixed set of logical combinations of input 
values:
  * there is a range representing the AND of all input values
  * there is a range representing the OR of all input values
  * there is a range representing something strange (OR_AND), which tries
    to capture the notion of difference between "input-unknown" and 
    "input-known-not-there"

I believe there is consensus on the semantics of the AND and OR range.
Was there ever consensus on the OR_AND thingy?  It strikes me as not 
really implementing what is wanted, especially in relation to future 
extensibility (I'll write a mail about this).

Were there other points of contention, or was that all?

(FWIW, the current textual diff to the psABI document adding GNU 
properties is at 
https://gitlab.com/x86-psABIs/x86-64-ABI/merge_requests/1/diffs )


Ciao,
Michael.

OR_AND semantics (was: GNU property saga)

[Michael Matz]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Hi,

On Mon, 4 Mar 2019, Michael Matz wrote:

> Was there ever consensus on the OR_AND thingy?  It strikes me as not 
> really implementing what is wanted, especially in relation to future 
> extensibility (I'll write a mail about this).

So, starting a subthread about only this.  The current description of the 
OR_AND range is this:

----------------
\item[GNU_PROPERTY_X86_UINT32_OR_AND_LO..GNU_PROPERTY_X86_UINT32_OR_AND_HI]
   A bit in the output \code{pr_data} field is set if it is set in any
   relocatable input \code{pr_data} fields and this property is present
   in all relocatable input files.  A missing property implies that its
   bits have unknown values.  When all bits in the the output
   \code{pr_data} field are zero, this property should not be removed
   from output to indicate it has zero in all bits.  If the property
   is in output, all input relocatables have the property.  If the bit
   is 1, some input relocatables have the feature.  If the bit is 0,
	
   none of input relocatables have the feature.
----------------

So, it's clear that the individual bits of the uint32 are independend of 
each other and hence can represent separate features/properties.  This 
means that the phrase "and this property is present in all relocatable 
input files" in not well defined: example situation:

* producer A knows about bits 4 and 5 of FEATURE_X (assumed to be in the 
  OR_AND range), it will set the FEATURE_X property in a.o (and bit 4
  and 5 therein to whatever is correct/requested)
* producer B is older and happens to know only bit 4 of FEATURE_X, so it 
  will set FEATURE_X in b.o, and bit 4 to whatever value is correct, but
  bit 5 will be zero.

Now the above language would include FEATURE_X in the output, but bit 4 
would be reliable (set a.bit4 && b.bit4) while bit 5 would be unreliable 
(it is zero, even if it is one in a.o and _would_ be one in b.o had we 
used a newer producer).

So there's still the confusion between absense and zero-is-unknown and 
zero-is-known, which the OR_AND range was designed to make clear (at least 
as far as I understood it from various mails trying to explain situations 
in which it would help).

So, either I misunderstood the reason of existence for OR_AND, or there's 
some unspelled assumption in the usage of OR_AND (e.g. that there must 
never be producers knowing a different set of bits per FEATURE_xxx uint32 
set), or the language above doesn't capture the intent.

What is it?


Ciao,
Michael.

Re: OR_AND semantics (was: GNU property saga)

[Cary Coutant]

> > Was there ever consensus on the OR_AND thingy?  It strikes me as not
> > really implementing what is wanted, especially in relation to future
> > extensibility (I'll write a mail about this).
> ...
> So, it's clear that the individual bits of the uint32 are independend of
> each other and hence can represent separate features/properties.  This
> means that the phrase "and this property is present in all relocatable
> input files" in not well defined: example situation:
>
> * producer A knows about bits 4 and 5 of FEATURE_X (assumed to be in the
>   OR_AND range), it will set the FEATURE_X property in a.o (and bit 4
>   and 5 therein to whatever is correct/requested)
> * producer B is older and happens to know only bit 4 of FEATURE_X, so it
>   will set FEATURE_X in b.o, and bit 4 to whatever value is correct, but
>   bit 5 will be zero.
>
> Now the above language would include FEATURE_X in the output, but bit 4
> would be reliable (set a.bit4 && b.bit4) while bit 5 would be unreliable
> (it is zero, even if it is one in a.o and _would_ be one in b.o had we
> used a newer producer).

I'm guessing that HJ is operating under the premise that if the older
producer B was unaware of bit 5 of FEATURE_X, then the object must
not, in fact, use that feature. His design is all-or-nothing: If the
FEATURE_X property is there, then we have accurate yes/no information
for each feature described by that property. That would work if he's
careful to move a new feature to a completely new FEATURE_Y property
whenever it's possible that an older consumer might have used that
feature before the means of recording it was defined.

Jim and I each suggested an improvement where each feature is
described by two bits: one bit from FEATURE_X_KNOWN and a
corresponding bit from FEATURE_X_USED*. The bits in FEATURE_X_KNOWN
would be ANDed, while the bits in FEATURE_X_USED would be ORed. This
would give us the following four cases:

(a) KNOWN = 0, USED = 0: The feature is not known to be used, but not
all objects provided a value.

(b) KNOWN = 0, USED = 1: The feature is used by at least one object,
but not all objects provided a value.

(c) KNOWN = 1, USED = 0: The feature is not used in any object, and
all objects provided a value.

(d) KNOWN = 1, USED = 1: The feature is used by at least one object,
and all objects provided a value.

Using the OR_AND scheme, case (a) is represented by a missing
property, and case (b) is folded into (a): If not all objects provide
the property, we discard the property, and all features revert to case
(a).

The OR_AND scheme would be equivalent to an OR scheme where missing
properties are treated as all ones -- in that case, we'd end up with
all ones rather than a missing property. For each feature, 0 means we
know the feature is not used, while 1 means we aren't necessarily
sure.

Alternatively, it would be equivalent to an AND scheme where the
meaning of each feature is inverted and missing properties are treated
as all zeroes: 1 means the feature is NOT used, and any object with a
missing property would result in all zeroes. For each feature, 1 means
we know the feature is NOT used, while 0 means we aren't necessarily
sure.

I was trying to understand why HJ didn't care about case (b) -- if a
feature is used by at least one object, what difference does it make
whether we have some objects that didn't say whether they used the
feature? I believe his answer is that the use case for these
properties is to allow the OS to decide whether it can allocate a
program to a downgraded processor, based on whether we know for sure
that the program does *not* use a particular feature. Thus, case (c)
is the important one where the downgrade is feasible, and all other
cases mean that it is not (either because we know the feature is used,
or because we do not know it's not used).

But it seems to me that there's an equally useful purpose for these
properties, if we can distinguish between cases (a) and (b). If we
want to allow the OS to refuse to execute a program that it knows
requires unsupported features, case (b) tells us that we do know the
program uses the feature, and the OS could provide a graceful error
message in that case, as it could for case (d). In case (a), we still
wouldn't know for sure whether the program will run successfully, but
we're no worse off than today.

-cary


* I originally wrote in terms of FEATURE_X_NEEDED, based on a
misstatement in an early email from HJ that led me to believe the
psABI had USED and NEEDED reversed. This scheme works for both USED
and NEEDED, and it's even feasible to use one set of KNOWN bits that
pairs with both a set of USED bits and a set of NEEDED bits.


>
> So there's still the confusion between absense and zero-is-unknown and
> zero-is-known, which the OR_AND range was designed to make clear (at least
> as far as I understood it from various mails trying to explain situations
> in which it would help).
>
> So, either I misunderstood the reason of existence for OR_AND, or there's
> some unspelled assumption in the usage of OR_AND (e.g. that there must
> never be producers knowing a different set of bits per FEATURE_xxx uint32
> set), or the language above doesn't capture the intent.
>
> What is it?
>
>
> Ciao,
> Michael.
>
> --
> You received this message because you are subscribed to the Google Groups "X86-64 System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to x86-64-abi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: OR_AND semantics (was: GNU property saga)

[Michael Matz]

Hello,

On Mon, 4 Mar 2019, Cary Coutant wrote:

> I'm guessing that HJ is operating under the premise that if the older 
> producer B was unaware of bit 5 of FEATURE_X, then the object must not, 
> in fact, use that feature. His design is all-or-nothing: If the 
> FEATURE_X property is there, then we have accurate yes/no information 
> for each feature described by that property. That would work if he's 
> careful to move a new feature to a completely new FEATURE_Y property 
> whenever it's possible that an older consumer might have used that 
> feature before the means of recording it was defined.

Yes, that's the implicit assumption theory I had.

> Jim and I each suggested an improvement where each feature is described 
> by two bits: one bit from FEATURE_X_KNOWN and a corresponding bit from 
> FEATURE_X_USED*. The bits in FEATURE_X_KNOWN would be ANDed, while the 
> bits in FEATURE_X_USED would be ORed. This would give us the following 
> four cases:

And yes, that would be my cut at designing such property feature as well.  
One set of bits that spells out what can be relied upon, and another set 
of bits that contains the actual used/unused state.  Nice, easy, obvious.

> I was trying to understand why HJ didn't care about case (b) -- if a
> feature is used by at least one object, what difference does it make
> whether we have some objects that didn't say whether they used the
> feature? I believe his answer is that the use case for these
> properties is to allow the OS to decide whether it can allocate a
> program to a downgraded processor, based on whether we know for sure
> that the program does *not* use a particular feature. Thus, case (c)
> is the important one where the downgrade is feasible, and all other
> cases mean that it is not (either because we know the feature is used,
> or because we do not know it's not used).

That might be, but truth be told, I'm more comfortable with an orthogonal 
design that can express more than we need right now, than with a design 
where two concepts (known and used) are merged in a non-natural way.

HJ: what's your issue with the KNOWN+USED approach?  I would envision an 
encoding where e.g. even IDs encode the 32 KNOWN bits, and odd IDs encode 
the 32 USED bits.  Optionally we could retain the differentiation between 
OR vs. AND for the logical combination of the USED bits (where the KNOWN 
bits are always ANDed), though I'm not sure I would see the point for 
this.

I really have stomach aches with the current design of the properties.


Ciao,
Michael.

Re: OR_AND semantics (was: GNU property saga)

[Cary Coutant]

> > I was trying to understand why HJ didn't care about case (b) -- if a
> > feature is used by at least one object, what difference does it make
> > whether we have some objects that didn't say whether they used the
> > feature? I believe his answer is that the use case for these
> > properties is to allow the OS to decide whether it can allocate a
> > program to a downgraded processor, based on whether we know for sure
> > that the program does *not* use a particular feature. Thus, case (c)
> > is the important one where the downgrade is feasible, and all other
> > cases mean that it is not (either because we know the feature is used,
> > or because we do not know it's not used).
>
> That might be, but truth be told, I'm more comfortable with an orthogonal
> design that can express more than we need right now, than with a design
> where two concepts (known and used) are merged in a non-natural way.

Agreed.

> HJ: what's your issue with the KNOWN+USED approach?  I would envision an
> encoding where e.g. even IDs encode the 32 KNOWN bits, and odd IDs encode
> the 32 USED bits.  Optionally we could retain the differentiation between
> OR vs. AND for the logical combination of the USED bits (where the KNOWN
> bits are always ANDed), though I'm not sure I would see the point for
> this.

There are other properties that need AND: ones where the OS depends on
the program supporting something, like IBT and SHSTK, rather than the
program depending on a feature supported by OS or CPU. So they
wouldn't always be paired as KNOWN/USED, there would also be some AND
properties standing on their own. In addition, if we want NEEDED
features in addition to USED features, they could form a triplet:
KNOWN/USED/NEEDED. Still, I think using the even/odd bit as an
indication whether we need to OR or AND is reasonable (kind of like
how we use that bit to indicate what kind of tag is used for DT
entries). If we can eliminate the need for the OR_AND beast, I think
we could assert that the only combining methods we need are OR and
AND.

(I went back and looked at one of HJ's early proposals for properties,
and the even/odd bit is the approach he originally took.)

> I really have stomach aches with the current design of the properties.

As you can tell from my posts on this topic, I agree strongly enough
to have tilted at this windmill far longer than I normally would have.
Thanks for chiming in!

-cary

Re: OR_AND semantics (was: GNU property saga)

[H.J. Lu]

On Tue, Mar 5, 2019 at 1:40 AM Michael Matz <matz@suse.de> wrote:
>
> Hi,
>
> On Mon, 4 Mar 2019, Michael Matz wrote:
>
> > Was there ever consensus on the OR_AND thingy?  It strikes me as not
> > really implementing what is wanted, especially in relation to future
> > extensibility (I'll write a mail about this).
>
> So, starting a subthread about only this.  The current description of the
> OR_AND range is this:
>
> ----------------
> \item[GNU_PROPERTY_X86_UINT32_OR_AND_LO..GNU_PROPERTY_X86_UINT32_OR_AND_HI]
>    A bit in the output \code{pr_data} field is set if it is set in any
>    relocatable input \code{pr_data} fields and this property is present
>    in all relocatable input files.  A missing property implies that its
>    bits have unknown values.  When all bits in the the output
>    \code{pr_data} field are zero, this property should not be removed
>    from output to indicate it has zero in all bits.  If the property
>    is in output, all input relocatables have the property.  If the bit
>    is 1, some input relocatables have the feature.  If the bit is 0,
> 
>    none of input relocatables have the feature.
> ----------------
>
> So, it's clear that the individual bits of the uint32 are independend of
> each other and hence can represent separate features/properties.  This
> means that the phrase "and this property is present in all relocatable
> input files" in not well defined: example situation:
>
> * producer A knows about bits 4 and 5 of FEATURE_X (assumed to be in the
>   OR_AND range), it will set the FEATURE_X property in a.o (and bit 4
>   and 5 therein to whatever is correct/requested)
> * producer B is older and happens to know only bit 4 of FEATURE_X, so it
>   will set FEATURE_X in b.o, and bit 4 to whatever value is correct, but
>   bit 5 will be zero.
>
> Now the above language would include FEATURE_X in the output, but bit 4
> would be reliable (set a.bit4 && b.bit4) while bit 5 would be unreliable
> (it is zero, even if it is one in a.o and _would_ be one in b.o had we
> used a newer producer).

We can't add a bit to FEATURE_X in such a way that  FEATURE_X generated
by older producers become invalid.   We must add the bit to FEATURE_Y which is
unsupported to all prior producers.  Am I missing something obvious?

> So there's still the confusion between absense and zero-is-unknown and
> zero-is-known, which the OR_AND range was designed to make clear (at least
> as far as I understood it from various mails trying to explain situations
> in which it would help).
>
> So, either I misunderstood the reason of existence for OR_AND, or there's
> some unspelled assumption in the usage of OR_AND (e.g. that there must
> never be producers knowing a different set of bits per FEATURE_xxx uint32
> set), or the language above doesn't capture the intent.
>
> What is it?
>

-- 
H.J.

Re: OR_AND semantics (was: GNU property saga)

[Cary Coutant]

> > Now the above language would include FEATURE_X in the output, but bit 4
> > would be reliable (set a.bit4 && b.bit4) while bit 5 would be unreliable
> > (it is zero, even if it is one in a.o and _would_ be one in b.o had we
> > used a newer producer).
>
> We can't add a bit to FEATURE_X in such a way that  FEATURE_X generated
> by older producers become invalid.   We must add the bit to FEATURE_Y which is
> unsupported to all prior producers.  Am I missing something obvious?

Yes, I think so. This is the point Michael (and I) were making. By
using KNOWN bits, you can add new feature bits without having to start
a whole new word of bits.

-cary

Re: OR_AND semantics (was: GNU property saga)

[Jim Dehnert]

On Thu, Mar 7, 2019 at 10:06 PM Cary Coutant <ccoutant@gmail.com> wrote:

> > > Now the above language would include FEATURE_X in the output, but bit 4
> > > would be reliable (set a.bit4 && b.bit4) while bit 5 would be
> unreliable
> > > (it is zero, even if it is one in a.o and _would_ be one in b.o had we
> > > used a newer producer).
> >
> > We can't add a bit to FEATURE_X in such a way that  FEATURE_X generated
> > by older producers become invalid.   We must add the bit to FEATURE_Y
> which is
> > unsupported to all prior producers.  Am I missing something obvious?
>
> Yes, I think so. This is the point Michael (and I) were making. By
> using KNOWN bits, you can add new feature bits without having to start
> a whole new word of bits.
>

You also don't need to assume that a producer that has implemented support
for the tenth feature bit is also generating valid values for the
previously-defined nine, just because the words containing them are present.

Jim

>
> -cary
>
> --
> You received this message because you are subscribed to the Google Groups
> "X86-64 System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to x86-64-abi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>


-- 
--
             Jim Dehnert
             dehnert@gmail.com

Re: OR_AND semantics (was: GNU property saga)

[H.J. Lu]

On Fri, Mar 8, 2019 at 2:25 PM Jim Dehnert <dehnert@gmail.com> wrote:
>
>
>
> On Thu, Mar 7, 2019 at 10:06 PM Cary Coutant <ccoutant@gmail.com> wrote:
>>
>> > > Now the above language would include FEATURE_X in the output, but bit 4
>> > > would be reliable (set a.bit4 && b.bit4) while bit 5 would be unreliable
>> > > (it is zero, even if it is one in a.o and _would_ be one in b.o had we
>> > > used a newer producer).
>> >
>> > We can't add a bit to FEATURE_X in such a way that  FEATURE_X generated
>> > by older producers become invalid.   We must add the bit to FEATURE_Y which is
>> > unsupported to all prior producers.  Am I missing something obvious?
>>
>> Yes, I think so. This is the point Michael (and I) were making. By
>> using KNOWN bits, you can add new feature bits without having to start
>> a whole new word of bits.

So is this the only difference?  We don't always need to add a new set of
feature bits for a new feature if the new new feature will never be valid for
older producers like a new ISA bit.  But a new bit for the old ISA needs a
new set of bits.  This way, we only need to lookup one property for the
feature X instead of 2.

BTW, OR covers (b) in

(a) KNOWN = 0, USED = 0: The feature is not known to be used, but not
all objects provided a value.

(b) KNOWN = 0, USED = 1: The feature is used by at least one object,
but not all objects provided a value.

(c) KNOWN = 1, USED = 0: The feature is not used in any object, and
all objects provided a value.

(d) KNOWN = 1, USED = 1: The feature is used by at least one object,
and all objects provided a value.

since there is no functional difference for the feature X in output
object between

1. The feature is used by at least one object, but not all objects
provided a value.
2. The feature is used by at least one object, and all objects provided a value.

We only need to know if the feature X is used.   We do need "all
objects provided
a value" info for USED == 0 case.

>
> You also don't need to assume that a producer that has implemented support for the tenth feature bit is also generating valid values for the previously-defined nine, just because the words containing them are present.
>


-- 
H.J.

Re: 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

Re: 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