[PATCH v2] elf: Don't set .note.GNU-stack type to SHT_NOTE

[Jan Beulich]

On 13.01.2026 17:07, Michael Matz wrote:
> On Tue, 13 Jan 2026, Jan Beulich wrote:
>>> of such type (irrespective of name) are to conform to a certain format of 
>>> contents.  In particular it _must_ contain a header, which .note.GNU-stack 
>>> doesn't.
>>
>> Sam question to you then: Where exactly is this said in the spec? What am
>> I overlooking?
> 
> https://gabi.xinuos.com/elf/07-pheader.html#note-sections

Well, that's a different incarnation from what I usually use, but the wording
is very similar if not identical. Hence my question remains: Where is it said
there that zero entries isn't permitted? It says "holds a variable amount of
entries" (none at all fitting this well) and "each entry is an array of {4,8}
-byte words". Hence my request: Please give an exact quotation that makes
clear that "empty" isn't legal.

>>> First match wins, hence .note.GNU-stack must be special cased before a 
>>> .note.* catchall, if anything needs to be done at all.
>>
>> Well, something should be done imo. People simply using *(.note .note.*)
>> in their linker scripts is legitimate, I'm inclined to say.
> 
> With the historic accident that exists, it isn't.  I agree that it should 
> be, but it isn't.
> 
>> Those scripts may pre-date the introduction of .note.GNU-stack.
> 
> That may be, but it's increasingly unlikely.  .note.GNU-stack with the 
> current warts was introduced around 2003.
> 
>> And that 
>> "something" better wouldn't be "everyone needs to edit their linker 
>> scripts".
> 
> I think "everyone" is an exaggeration.  Even "many" would be.  It's 
> certainly fewer than those affected by suddenly generating invalid 
> SHT_NOTE sections.

I'm sure you understand how I meant "everyone".

Your reference to it having been around since 2003 also is only partly
relevant. Iirc you were involved in the internal bug where suddenly a
helper component of Xen didn't work anymore. That was a result of some
re-ordering of the linker scripts, making this non-SHT_NOTE section
named .note.GNU-stack suddenly end up first among all .note.*. As a
result, its SHT_PROGBITS-ness propagated to the entire .note section
in the output, rendering it useless to conforming consumers. IOW even
if the introduction was over 20 years ago, the mistake made back then
can still bite us (and who knows if it won't again for yet another
reason).

> Didn't we go through all of this last year or two years ago?  I have a 
> big dejavu that someone tried to make .note.GNU-stack SHT_NOTE before with 
> exactly the same discussions and outcome that we have now here.

Hmm, interesting. I have no recollection.

>>>>> Readelf should at least issue a warning for an empty SHT_NOTE which
>>>>> indicates a user error.
>>>>
>>>> I disagree; there's no "user error" there.
>>>
>>> An empty SHT_NOTE section would be an error, if such was generated by a 
>>> user it would indeed be a user error.  SHT_NOTE section must contain 12 
>>> bytes at least: namesz, descsz and type, each 32bits.
>>
>> See above - I'd be grateful if my misreading of the spec was corrected,
>> as that was (naturally) part of the foundation of the original patch.
>>
>> (As an aside, the spec I'm looking at also [still] mandates three 64-bit
>> items for ELF64. I have no idea whether that was formally relaxed
>> anywhere in the meantime.)
> 
> So you did find the section that mandates the header of 
> SHT_NOTE sections, yet you are still convinved that a zero-length SHT_NOTE 
> section is okay?  I'm confused.

See above - I simply can't spot any statement to the effect of what you're
claiming. (And strictly speaking there's no "header of SHT_NOTE sections"
anyway. Every "entry" has to have such a header. Then: No "entry", no header.

Jan