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

[Michael Matz]

Hello,

On Tue, 13 Jan 2026, Jan Beulich wrote:

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

It was clear to me from that language in the spec.  With your 
clarification on how you read it, yes I can see that that is a valid 
reading as well, maybe more valid even; i.e. zero sized section would 
contain no entries.  Hmm.

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

Ah, maybe that was causing the deja-vu, indeed.

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

I'm inclined to reverse my opinion from upthread.  I.e. from a pure
specification perspective zero-sized SHT_NOTE sections are okay 
(corresponding to a no-entry note section/segment).  It will then 
automatically contribute into the PT_NOTE segment, but harmlessly so, as 
it contains no entries.  It will also continue to cause generation of the 
PT_GNU_STACK program header based on its name, exactly what we want.

There are more warts of .note.GNU-stack that need at least a little 
pondering:
(a) the usage of section flags to convey information, i.e. being 
    SHF_EXECINSTR to mean needing an executable stack.
    It's slightly surprising to find such flag on a SHT_NOTE section.
    (And what does it mean for the resulting PT_NOTE segment?)
(b) in .s files the .note.GNU-stack section is often generated by
    .section .note.GNU-stack,"",@progbits
    it may be surprising if the resulting .o file has a SHT_NOTE type,
    instead of the explicitely requested SHT_PROGBITS

I think none of those would hinder the usage of SHT_NOTE for 
.note.GNU-stack.  (a) shouldn't pose a problem anywhere, and the surprise 
is very limited.  For (b) the asm directive should probably continue to 
then make the gnu-stack section be SHT_PROGBITS, but either way the link 
editor needs to continue accepting PROGBITS .note.GNU-stack anyway, as a 
compatility measure.

Were there other reasons to reject the idea to .note.GNU-stack being 
SHT_NOTE (i.e. besides a presumed invalidity of zero-sized note sections 
and contribution into PT_NOTE)?  If there weren't I think I now agree with 
you that automatically generated .note.GNU-stack sections (or those not 
explicitely requesting a section type) can have type SHT_NOTE.

But the question remains if it _should_ have such?  Due to the warts above 
.note.GNU-stack will always need special handling somewhere, so changing 
the section type doesn't get rid of all of them (and perhaps adds some 
more special casing for the PT_NOTEs flags).  I don't know the answer to 
that, I can see arguments both ways :-/


Ciao,
Michael.