cc-wrapper: disable incompatible hardening options in cpu bit size cross

[RossComputerGuy]

Description of changes

As the title says, this disables incompatible hardening options when cross compiling between the same ISA but different bit size. This prevents the issue of the zerocallregs hardening option from being used when using clang to build Linux and Linux is building for aarch64 but builds vdso32.

@K900 initially suggested the idea that we prevent that behavior inside of the cc-wrapper instead of hardcoding derivations to disable the zerocallregs hardening option altogether inside of the Linux kernel derivation.

Can be tested by building pkgsLLVM.linux on aarch64-linux.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[RossComputerGuy]

@ofborg eval

[RossComputerGuy]

@ofborg eval

[emilazy]

Nice! Would this let us drop some of the various hardeningDisable = [ "zerocallusedregs" ] instances that have popped up across the tree? (e.g. Rust, systemd)

[RossComputerGuy]

Likely, it'll probably a more reasonable change to use hardeningUnsupportedFlagsByTargetPlatform in more cases because of nuisances between different packages.

[alyssais]

I think it's important @Ericson2314 has a look at the lib changes before this goes in. I'm not sure myself whether it makes sense to try to map between 64-bit and 32-bit triples, because there could be multiple sensible options.

[RossComputerGuy]

Yeah, the problem here is we have to detect when clang is using the 32 bit or 64 bit triple. I figured it was easier to use lib.systems to help with that and then pulling only the arch out and matching based on that inside cc-wrapper. More feedback on this implementation would be great.

[tomberek]

Currently blocked on review. (@Ericson2314 , can you take a look?)

[emilazy]

After further discussion on Matrix, I don’t believe this is the right approach to the problem. The fundamental issue is that we are setting default hardening flags for a different host platform than we’re compiling for. This is essentially a cross‐compilation scenario and so #354622 would be a step in the right direction. In this case, it wouldn’t fix it, because we’re using the same wrapped compiler to build for two different architectures. Unfortunately, that is fundamentally broken right now in general. Maintaining a mapping between 64‐ and 32‐bit architectures is also not really something that can make sense in general. I believe the appropriate ways forward are:

• Use an unwrapped compiler to compile the VDSO32 for now; this would work with Clang since it’s natively multi‐target, and with GCC since it’s effectively “dual‐target”. I think this is the most expedient short‐term fix.

• Make it easier to re‐wrap our compilers for different architectures, and use a re‐wrapped compiler.

• Rework our wrappers to work natively multi‐target. This would be the best option but would be a large undertaking.