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

libs built with executable stack on non amd64 architectures #2963

Closed
pixelb opened this issue Dec 29, 2021 · 1 comment
Closed

libs built with executable stack on non amd64 architectures #2963

pixelb opened this issue Dec 29, 2021 · 1 comment
Assignees
Labels
build release-blocking Must be done by the release

Comments

@pixelb
Copy link
Contributor

pixelb commented Dec 29, 2021

Due to the effectively empty huf_decompress_amd64.S on non amd64 architectures,
the empty assembly file is still significant, and causes libs to be built with an executable stack.
This triggers various security issues, most obvious being failure to boot on non x86_64 fedora systems,
due to systemd not loading as it sees the dependent libzstd.so.1 as a security issue (which it is).

There were a few solutions discussed at https://bugzilla.redhat.com/2035802

A possible fix may be just to move the "non executable stack" directive outside the ifdef in the huf_decompress_amd64.S file

@jpalus
Copy link

jpalus commented Dec 29, 2021

You beat me to it by 5 minutes :)

Can confirm that today 2 of my arm 32-bit boards (armv6hl and armv7hnl) did not boot after upgrade of zstd to 1.5.1.

For reference:

a5f2c45528032ed20c33e0f8cd2c163a800a0017 is the first bad commit
commit a5f2c45528032ed20c33e0f8cd2c163a800a0017
Author: Nick Terrell <terrelln@fb.com>
Date:   Fri Sep 17 11:43:04 2021 -0700

    Huffman ASM

pld-gitsync pushed a commit to pld-linux/zstd that referenced this issue Dec 29, 2021
felixhandte added a commit to felixhandte/zstd that referenced this issue 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.
@felixhandte felixhandte assigned felixhandte and unassigned terrelln Jan 4, 2022
@felixhandte felixhandte added build release-blocking Must be done by the release labels Jan 5, 2022
LeSpocky pushed a commit to LeSpocky/ptxdist that referenced this issue Jan 16, 2022
…platforms

Without this, many systemd services, including journald and udevd fail to
start on non x86_64 platforms with:
"error while loading shared libraries: libzstd.so.1: cannot enable
executable stack as shared object requires: Operation not permitted"

See also: facebook/zstd#2963

Cherry-pick the relevant patches from upstream to fix this.

Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build release-blocking Must be done by the release
Projects
None yet
Development

No branches or pull requests

4 participants