Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lld silently ignores .note.GNU-stack section that requests exectuable stack #121234

Open
emaste opened this issue Dec 27, 2024 · 1 comment
Open
Labels

Comments

@emaste
Copy link
Member

emaste commented Dec 27, 2024

lld contains the comment

    // The GNU linker uses .note.GNU-stack section as a marker indicating
    // that the code in the object file does not expect that the stack is
    // executable (in terms of NX bit). If all input files have the marker,
    // the GNU linker adds a PT_GNU_STACK segment to tells the loader to
    // make the stack non-executable. Most object files have this section as
    // of 2017.

This is not entirely correct -- the presence of .note.GNU-stack does not necessarily indicate that the object file is compatible with non-exec stack. That is indeed the most common case, but the note actually indicates the object's expected stack protection -- it may have an X flag to indicate an object file that requires executable stack. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278939 for the FreeBSD issue that prompted this.

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
...
  [14] .note.GNU-stack   PROGBITS        0000000000000000 0077d8 000000 00   X  0   0  1

Executable stacks should be exceedingly rare and I have no issue with requiring an explicit -z execstack, but I think we should at least produce an error if there's a .note.GNU-stack that specifies exec stack and -z execstack is not specified. We should not silently produce broken output.

@github-actions github-actions bot added the lld label Dec 27, 2024
@emaste
Copy link
Member Author

emaste commented Dec 27, 2024

See also #57009

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant