[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