-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
Cross bootstrap tools have broken stackprotector support #113977
Comments
Maybe this isn't the morally correct fix, but I'm also hitting this problem... Thoughts on merging the provided fix into Nixpkgs? |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/getting-started-with-nix-on-ppc64le/12712/2 |
Hmm, I think I would want input from someone more versed in stdenv. AFAICT the stage3 static libs are only used for the stage4 gcc, but that gcc is the one used in stdenv. So these libraries would never be exposed directly in nixpkgs, but would be used transitively by gcc when every package is built. So I'd need to know what issue the stackprotector hardening addresses, and if that's potentially an issue for us to disable it for dependencies of stdenv's gcc. It looks like in most cases, when stackprotector causes issues, we just turn it off. But that only seems to be the case for leaf packages; I would imagine stdenv requires much more scrutiny. |
For some reason, this is actually making it into nixpkgs for me. E.g. the cross compiler I grab here gives a gcc cross compiler from x8664 to riscv64. When I try to compile a kernel with that cross compiler toolchain (riscv64-unknown-linux-gnu-*), I get stack protector errors at link time (exactly as you've described). I'm not sure which stage gcc this is; perhaps this is completely different. I just pattern matched on the error you've described. |
The stack protector guards against buffer overflow in the built artifact. Hardening of a compiler's stack protector should have no impact on that compiler's output, and since this compiler is only used to compile stage4 I'd say this change is fine. |
This compiler /is/ stage4, and is exposed as stdenv.cc. Realistically, I think we have bigger fish to fry w.r.t. the security of nixpkgs. But I'm not a security expert so I'd want some more reassurance here. |
Oh, it might be worth it to rebuild the compiler in stage4 then. |
Hmm, I just found #40797 in the issue backlog and am wondering if it's related. |
I marked this as stale due to inactivity. → More info |
Proposed the possible fix as #181943 |
Confirmed this has been resolved by trofi's sysroot fix. Thanks! |
Describe the bug
The cross-compiled bootstrap tools produced by
make-bootstrap-tools-cross.nix
have faulty support for stack protector hardening (libssp) during the resulting stdenv bootstrap chain. The issue manifests as linker errors when building the stage4 gcc from the static stage3 libraries during stdenv bootstrap. This means that when initially bootstrapping a system from cross-compiled bootstrap tools, an ugly workaround is needed:To Reproduce
(The following steps are slightly modified from my original use case, to ease repro on commodity x86_64 hardware. You don't need any
--option system
fudging if you have a foreign arch system you can cross-compile to.)Steps to reproduce the behavior:
make-bootstrap-tools-cross.nix
for compilation to x86_64.nix build -f pkgs/stdenv/linux/make-bootstrap-tools-cross.nix --option system i686-linux x86_64.build
result/on-server/bootstrap-tools.tar.xz
topkgs/stdenv/linux/bootstrap-files/
and set it as the x86_64 bootstrap.nix build -f . stdenv
undefined reference to ``__stack_chk_guard'
linking errors near the end of the stage 4 gcc build. The stage3 static library dependencies of gcc (gmp, mpfr, mpc, and isl) must be overridden to disable stackprotector hardening for gcc to build.Log snippet:
Expected behavior
Successful build of stdenv using cross-compiled bootstrap files
Additional context
I first encountered this months ago when using cross-built bootstrap tools for powerpc64le, and assumed it was an arch-specific issue. However, when later using native-built bootstrap tools I realized the stackprotector hardening could be reenabled in the stage3 libraries. It wasn't until I tested i686 -> x86_64 bootstrap that I realized this was a more general issue.
Notify maintainers
Cross infra CODEOWNERS: @Ericson2314 @matthewbauer
The text was updated successfully, but these errors were encountered: