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

Remove executable flag from GNU_STACK segment #2857

Merged
merged 1 commit into from
Nov 16, 2021

Conversation

ko-zu
Copy link
Contributor

@ko-zu ko-zu commented Nov 13, 2021

Putting stack marking into every assembly file is required to indicate
that the stack does not need to be executable.
Executable flag on stack conflicts with some security measures, Systemd
MemoryDenyWriteExecute=yes for example.

The current dev branch produces libzstd.so that uses executable GNU_STACK on Linux amd64 machines. It makes some of systemd daemons crash as they cannot load the library because of systemd security option MemoryDenyWriteExecute=yes

$ readelf -lW lib/libzstd.so | grep RWE
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10

This executable stack makes systemd angry. Systemd has a security option MemoryDenyWriteExecute=yes that blocks memory allocation with writable and executable flags on.

To emulate the option, on ubuntu 21.10,

$ sudo systemd-run -t -p MemoryDenyWriteExecute=yes /lib/systemd/systemd-timesyncd -v
Running as unit: run-u782.service
Press ^] three times within 1s to disconnect TTY.
/lib/systemd/systemd-timesyncd: error while loading shared libraries: libzstd.so.1: cannot enable executable stack as shared object requires: Operation not permitted

Putting stack marking into every assembly files is required to indicate
that the stack does not need to be executable.
Executable flag on stack conflicts with some security measures, Systemd
MemoryDenyWriteExecute=yes for example.
@terrelln
Copy link
Contributor

Thanks @ko-zu! We noticed this issue internally a few weeks ago, when our builds broke systemd. Looking into this was on my todo list, so you've solved a huge problem for me!

I've opened up Issue #2865 to add a test case for this, so we don't regress in the future. We'll make sure to do it before our next release.

@terrelln terrelln merged commit f343f27 into facebook:dev Nov 16, 2021
terrelln added a commit to terrelln/zstd that referenced this pull request Nov 30, 2021
Adds a test for PR facebook#2857.

Tests that libzstd.so doesn't have the exec-stack bit set using
readelf. If the stack is marked executable systemd will refuse
to link against zstd. We now test that it isn't set on every PR.
terrelln added a commit to terrelln/zstd that referenced this pull request Nov 30, 2021
Tests that libzstd.so doesn't have the exec-stack bit set using
readelf. If the stack is marked executable systemd will refuse
to link against zstd. We now test that it isn't set on every PR.

Adds a test for PR facebook#2857
Fixes Issue facebook#2865
terrelln added a commit to terrelln/zstd that referenced this pull request Dec 1, 2021
Tests that libzstd.so doesn't have the exec-stack bit set using
readelf. If the stack is marked executable systemd will refuse
to link against zstd. We now test that it isn't set on every PR.

Adds a test for PR facebook#2857
Fixes Issue facebook#2865
felixhandte added a commit to felixhandte/zstd that referenced this pull request Dec 30, 2021
Apparently, even when the assembly file is empty (because
`ZSTD_ENABLE_ASM_X86_64_BMI2` is false), it still is marked as possibly
needing an executable stack and so the whole library is marked as such. This
commit applies a simple patch for this problem by moving the noexecstack
indication outside the macro guard.

This commit builds on facebook#2857.

This commit addresses facebook#2963.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants