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

Jan Beulich jbeulich@suse.com
Tue Jan 13 15:49:19 GMT 2026


On 13.01.2026 16:28, Michael Matz wrote:
> On Tue, 13 Jan 2026, Jan Beulich wrote:
>>> 1. The meaning of the SHT_NOTE section is determined by the contents of
>>> the section, not by section names.
>>
>> The meaning of .note.GNU-stack has been tied to its name, no matter what
>> the section type (and it was never meant to have any contents).
>>
>>> 2. The sh_flags field of the SHT_NOTE section has no impact on the meaning of
>>> the section.
>>
>> Generally not, but whichever type it has - .note.GNU-stack is special.
>>
>> Also, what wording in the spec do you derive this from?
>>
>>> 3. SHT_NOTE sections are mapped to the PT_NOTE segment.
>>
>> Again, whichever type it has - .note.GNU-stack has been special.
>>
>>> .note.GNU-stack section is none of the above.  From day one, .note.GNU-stack
>>> has been a SHT_PROGBITS section.   It is simply wrong to set it to SHT_NOTE.
>>
>> Well, to me it simply was wrong (from day one) to make it SHT_PROGBITS
>> (or to name it the way it is named).
> 
> What was wrong from the beginning was its name.  But as you rightly point 
> out, it is the name that gives it its semantics, so we can't change that 
> anymore.
> 
> It's type cannot be SHT_NOTE, because as H.J. rightly points out sections 
> 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?

> So, when it was introduced, and as it never had contents, there would have 
> been two correct section types: SHT_PROGBITS and SHT_NOBITS.  PROGBITS was 
> chosen, there's doesn't seem to be any argument in to favor one over the 
> other.
> 
> So, while I sympathize with the want to align the sections name pattern 
> matching .note.* with its type, it simply cannot be done.  The name cannot 
> be changed for compatibility, and the type cannot by SHT_NOTE for 
> correctness.  The only way I see would be to completely phase out 
> .note.GNU-stack and replace it by some other marker than a section.
> 
>> Furthermore, if we were to stick to SHT_PROGBITS (i.e. my change to be
>> reverted), what would be your alternative proposal to address the
>> linker script issue (which is what all of this started from)?
> 
> 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. Those
scripts may pre-date the introduction of .note.GNU-stack. And that
"something" better wouldn't be "everyone needs to edit their linker
scripts".

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

Jan


More information about the Binutils mailing list