cc-wrapper: add zerocallusedregs hardening flag, add pkgsExtraHardening package set

[risicle]

Description of changes

More information on -fzero-call-used-regs: https://www.jerkeby.se/newsletter/posts/rop-reduction-zero-call-user-regs/

Short version: this hardening flag (available in gcc >= 11) reduces the number of ROP gadgets present in code by inserting instructions zeroing registers on function returns. The choice of used-gpr as a setting for regular use comes from the conclusions of the above article noting other projects making this choice.

This flag is also available in clang >= 15 but only for x86_64 & aarch64, and our hardeningUnsupportedFlags mechanism isn't sophisticated enough to manage variation by target platform (we could trivially vary hardeningUnsupportedFlags based on stdenv.targetPlatform, but that might produce the wrong result when called as a cross-compiler). So for now I've had to disable it for clang. (Perhaps hardeningUnsupportedFlags could accept a function taking a platform? let's not get too diverted..) Not such a problem after all, implemented, see comment below 👇

The more visible change in this PR is adding a new package set, pkgsExtraHardening, which I'd like to use as a testing ground for new hardening flags or flags which are still known to cause some problems. Users of other "hardened" features may be interested in using this package set. The name is a little clunky - I was also considering pkgsHarder (pkgsMeHarder? maybe not..)

Have tested bootstrapping pkgsExtraHardening on macos 12 x86_64, nixos x86_64 (+pkgsi686Linux, pkgsLLVM, pkgsCross.aarch64-multiplatform...). A couple of months ago I built quite a lot of nixos x86_64 with this flag set and struggled to find anything that had a problem with it.

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.05 Release Notes (or backporting 23.05 and 23.11 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.

[RaitoBezarius]

Two questions:

• Does the new package scope gets built by Hydra?
• What is the code size consequence on enabling those mitigations on a NixOS system? (Can we compare it?)

Other than that, I love that feature!

[risicle]

Does the new package scope gets built by Hydra?

Nope.

What is the code size consequence on enabling those mitigations on a NixOS system? (Can we compare it?)

Good question. Find out. (Would be good for more people than just me to have tried this...)

But seeing as this looks destined for being enabled by default in the kernel (at some point), I would have expected to hear more noise about it if there were a significant impact.

This is just the first of several new hardening flags I want to introduce in this release cycle, but am going to try and concentrate on one at a time.

[risicle]

Ok, I've nerd-sniped myself into implementing the per-platform hardeningUnsupportedFlags. I've been reliably informed that a compiler's target is effectively fixed when it is cc-wrapper'ed, so we don't have to worry about e.g. runtime target detection, even for compilers like clang that are multi-target by nature.

I've explained more in the commit message, but this adds a new passthru attr, hardeningUnsupportedFlagsByTargetPlatform, to the affected clang derivations. Using a new attribute for this allows more straightforward overriding patterns, and continues to support hardeningUnsupportedFlags as long as the "innermost" hardeningUnsupportedFlagsByTargetPlatform implementation falls back to the package's hardeningUnsupportedFlags however it sees fit.

Tested successful bootstrap of pkgsExtraHardening on macos 12 x86_64 & nixos x86_64 pkgsLLVM.pkgsExtraHardening (and pkgsLLVM.pkgsStatic.pkgsExtraHardening)

[RaitoBezarius]

The internals look fairly reasonable, but I'm not expert on those parts (but I went through those rabbit holes quite often).

I would like the stdenv (IIRC) documentation to be updated though with the new per-platform flag.

[risicle]

hardeningUnsupportedFlagsByTargetPlatform isn't an attr on stdenv, it's an attr on the compiler derivation - I don't think we've documented the interface between the compiler and cc-wrapper (e.g. hardeningUnsupportedFlags) before.

pkgsExtraHardening should probably get some documentation, and these changes should get added to the release notes - but I'd like to know if people are going to throw these ideas out (or ask for significant changes) before I go and write these.

Speaking of which #273840 could still do with a review.

[risicle]

@ofborg eval

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/3151

[risicle]

@ofborg eval

[cole-h]

As mentioned on matrix: ofborg is failing because:

This SHA and context has reached the maximum number of statuses.

If you force-push a new git sha, it'll start working again. Unfortunately, this is a GitHub limitation (maybe something happened during an outage that caused this), so that's the only workaround I can think of (aside from submitting a brand new PR altogether, which seems less ideal if a force-push would work).

It seems like the only way to get around this is to open a new PR that isn't burdened by the hundreds of commit statuses that GitHub's API takes issue with :/

[risicle]

@cole-h oh, could this be ofborg trying to extend its evaluation into pkgsExtraHardening? I think I just assumed that ofborg and hydra would ignore other package sets...

[risicle]

Added some release notes (and rebased again in the vain hope of pleasing ofborg)

[cole-h]

I think you'll need to add pkgsExtraHardening to this list:

nixpkgs/pkgs/top-level/release-attrpaths-superset.nix

Line 50 in 28dbc86

# cross packagesets

EDIT: Yeah, that let ofborg continue to do its thing on my test PR: #282387