search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.37k stars 13.59k forks source link

Feature Request: emulatedPkgs #296787

Open physics-enthusiast opened 5 months ago

physics-enthusiast commented 5 months ago

Followup to NixOS/nix#2561, now that binfmt_misc namespaces have been merged into the 6.7 kernel. While painfully slow, emulation via binfmt_misc and QEMU is still significantly more reliable than hoping that crossPkgs happens to not be broken that day. It would hence be helpful from a stability perspective to be able to use foreign-architecture emulation on a per-derivation basis. This would be especially nice from a convenience perspective for cases where the binaries are intended to be run on the same NixOS system they are built on (for e.g. a declarative cross-arch VM or container), so that they can be added in a single rebuild (currently, an intermediate rebuild may sometimes be required to first enable global emulation of the relevant platform). Additionally, this could solve some of the reproducibility issues associated with the current global registration system by separating and isolating run-time emulation (boot.binfmt.emulatedSystems) from build-time emulation (emulatedPkgs) via the same chroot mechanism that the Nix builder already uses. The main difficulty aside from the implementation itself might be deciding what these derivations should do when the system doesn't support binfmt namespacing, since even within just the NixOS systems those with kernel >6.7 are still very much the minority.

physics-enthusiast commented 5 months ago

Tagging @Mic92 since he raised the original issue.

justinlovinger commented 5 months ago

The main difficulty aside from the implementation itself might be deciding what these derivations should do when the system doesn't support binfmt namespacing, since even within just the NixOS systems those with kernel >6.7 are still very much the minority.

This is a problem that will naturally solve itself in time. In the meantime, I think it's reasonable for these derivations to fail if the necessary kernel-features are not available.

physics-enthusiast commented 5 months ago

Currently trying to figure out a way to test for binfmt_misc namespace capability in the kernel that isn't just attempting to register an interpreter directly, in case someone who disabled/relaxed the sandbox attempts to build one of these derivations. In those cases if the user also somehow ends up with root (not sure whether this is likely/possible), the build could potentially "succeed" but silently alter global binfmt settings, which would be fairly problematic. In the worst case it's possible to make a system unbootable this way (by attempting to register an interpreter for the native platform). The last scenario requires that a user alters precisely the right settings in precisely the wrong ways, but it is still possible. If anyone has any ideas do feel free to let me know.