nixos/binfmt: Avoid adding to extra-sandbox-paths with fixBinary

[dramforever]

Static emulators should not require setting nix.settings.extra-sandbox-paths.

I hope this way of organizing the defaults makes sense.

Honestly I think non-static emulators should be thrown away altogether but I just want to make the static case happier for now.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux (The NixOS test, after some modification wrt systems used)
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[jcaesar]

I originally kept the extra sandbox paths.

• Not adding them is extra complexity.
• Even if the interpreters are not accessed through those paths, the impurity is introduced, just through the kernel. Adding the paths is a (maybe weird?) way of documenting that fact.

I wonder, what's the downside to having those paths? Performance impact on sandbox setup?

In either case, I don't feel strongly about this. Feel free.

Honestly I think non-static emulators should be thrown away altogether but I just want to make the static case happier for now.

• Static emulators are a bit larger, closure-size wise. (Then again, binfmt emulation is a heavy technique anyway.)
• Is e.g. pkgsStatic.wine a thing that builds reliably?
• Building nix packages isn't the only reason you might want binfmt emulation.

[dramforever]

Even if the interpreters are not accessed through those paths, the impurity is introduced, just through the kernel. Adding the paths is a (maybe weird?) way of documenting that fact.

It should be possible, with some work in Nix, to make use of the fact that "binfmt_misc namespaces" exist (actually just that each user namespace has its own binfmt_misc): torvalds/linux@21ca59b. This way, we can avoid having binfmt_misc emulators contaminate native and cross builds altogether. I intend to work towards that.

I originally didn't mention this because I haven't got that working yet, and because I thought avoiding impurity as much as possible was obvious.

[dramforever]

Re: dynamic vs static emulators, I will concede that dynamically linked emulators should be avoided for chroot-like use cases, so including emulated containers, emulated-native Nix builds. For non-chroot use cases dynamically linked emulators work well.

In particular, the /nix/store arrangement avoids having to chroot in many cases as well.

[jcaesar]

I thought avoiding impurity as much as possible was obvious.

This PR isn't avoiding any impurity. But I guess it's a first step towards setting up binfmt_misc on builds where it is necessary only (and wiping it where it isn't?). That would be slick. 👍

[jcaesar]

(nixpkgs-review is useless here but passes. The test evaluates and builds on x86_64-linux too. Likewise, nixosTests.systemd-binfmt.basic.config.nodes.machine.nix.settings.extra-sandbox-paths remains nonempty, so it doesn't break setting the path when it's necessary either.)

[dramforever]

In case anyone was waiting for this

• Add binfmt_misc configuration for the build sandbox nix#15539