Skip to content
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

lanzaboote-stub: init at 0.3.0 #231951

Closed
wants to merge 4 commits into from
Closed

lanzaboote-stub: init at 0.3.0 #231951

wants to merge 4 commits into from

Conversation

RaitoBezarius
Copy link
Member

@RaitoBezarius RaitoBezarius commented May 14, 2023

Description of changes

This brings https://github.com/nix-community/lanzaboote UEFI stub in-tree.

Dependents:

Dependencies:

Related:

Current design

Stub and tool are packaged in the global hierarchy as: lanzaboote-tool and lanzaboote-uefi-stub, no assumption on the system are encoded inside their package respectively.

It is expected to build the UEFI stub using a UEFI system with a UEFI compiler.

The linker is a flavored linker which will propagate adequately the lld Windows-style driver for arguments.

lanzaboote-tool is supposed to be wrapped to know about its lanzaboote-stub, unfortunately, this is impossible to achieve inside of nixpkgs, multiple attempts were proposed to the reviewers in the next section and were all rejected. Therefore, the only solution is to give up on having a wrapped lanzaboote-tool and propose a semi-wrapped lanzaboote-tool and expect the user to understand they have to export the LANZABOOTE_STUB environment variable to know about the stub itself.

This is what we do in the systemd-boot NixOS module ourselves and we expect to work in many cases, either case, author would like to move this PR forward ideally and not concern themselves further with the semi wrapping issue stemming from the impossibility to build a package as a data via cross-compilation inside of nixpkgs, alas.

What has been tried?
  • Trivial implementation using nixpkgs reimport inside of pkgs/ hierarchy: NACK because it reimports nixpkgs inside nixpkgs.
  • Introduction of a UEFI system example: NACK because there is divergence on the system data, see discussion on MinGW style vs MSVC and GNU-Config as a general.
  • Complicated implementation by locally rebooting nixpkgs inside the package definition of the tool to compile the stub using a hacked stdenv: NACK because it's too complicated.
  • Complicated implementation by locally rebooting a new package scope called uefiPkgs for cross compilation inside nixpkgs without a direct reimport: NACK because it's too complicated and does not compose well.
Some funny questions

It seems like this PR tries to move to make UEFI a proper target in nixpkgs, but there's already plenty of "data as UEFI binaries" inside of nixpkgs without any cross compilation involved per se:

  • EDK2/OVMF firmware
  • systemd-boot
  • GRUB EFI

Ideally, we should treat the same way as in this PR, I suppose this will be very hard given their build system.

Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • 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/)
  • 23.05 Release Notes (or backporting 22.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.

@github-actions github-actions bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` labels Jun 13, 2023
@RaitoBezarius RaitoBezarius changed the title lanzaboote: init at 0.3.0 lanzaboote-tool, lanzaboote-stub: init at 0.3.0, nixos/systemd-boot: init secureboot with lanzaboote Jun 13, 2023
pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/top-level/all-packages.nix Outdated Show resolved Hide resolved
@RaitoBezarius

This comment was marked as duplicate.

pkgs/tools/system/lanzaboote/stub.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/stub.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/stub.nix Outdated Show resolved Hide resolved
@pasqui23 pasqui23 requested review from ElvishJerricco, a user and Kranzes June 17, 2023 12:36
@ghost
Copy link

ghost commented Jun 19, 2023

#235230 is done; reviewing this PR is next on my list.

pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/tool.nix Outdated Show resolved Hide resolved
pkgs/tools/system/lanzaboote/stub.nix Outdated Show resolved Hide resolved
@RaitoBezarius RaitoBezarius force-pushed the lanzaboote branch 3 times, most recently from 5586367 to e2723f0 Compare July 8, 2023 17:11
@ghost ghost requested a review from infinisil as a code owner November 1, 2023 07:53
@ghost
Copy link

ghost commented Nov 1, 2023

Pushed to this branch:

When I run CI locally it passes. Let's see what ofborg says.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got CI to pass.

My opinion remains unchanged: UEFI is a boondoggle.

But if the boon must be doggled, at least it will be done using Nix and Rust. 🤷‍♂️

homepage = "https://github.com/nix-community/lanzaboote";
license = licenses.gpl3Only;
mainProgram = "lanzaboote_stub.efi";
platforms = [ "x86_64-uefi" "i686-uefi" "aarch64-uefi" ];
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
platforms = [ "x86_64-uefi" "i686-uefi" "aarch64-uefi" ];
hydraPlatforms = [ lib.systems.inspect.platformPatterns.isUefi ];

platforms = [ "x86_64-uefi" "i686-uefi" "aarch64-uefi" ];
# i686: Builtins errors
# aarch64: compile fine but...
broken = stdenv.isi686 || stdenv.isAarch64;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
broken = stdenv.isi686 || stdenv.isAarch64;
broken = with stdenv.hostPlatform; isi686 || isAarch64;

linker = "lld";
};


Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

@@ -112,6 +115,7 @@ in {
redox = filterDoubles predicates.isRedox;
windows = filterDoubles predicates.isWindows;
genode = filterDoubles predicates.isGenode;
uefi = filterDoubles predicates.isEfiEnvironment;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
uefi = filterDoubles predicates.isEfiEnvironment;
uefi = filterDoubles predicates.isUefi;

@@ -91,6 +91,10 @@ rec {
isMusl = with abis; map (a: { abi = a; }) [ musl musleabi musleabihf muslabin32 muslabi64 ];
isUClibc = with abis; map (a: { abi = a; }) [ uclibc uclibceabi uclibceabihf ];

isEfiEnvironment = [
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
isEfiEnvironment = [
isUefi = [

mainProgram = "lanzaboote_stub.efi";
platforms = [ "x86_64-uefi" "i686-uefi" "aarch64-uefi" ];
# i686: Builtins errors
# aarch64: compile fine but...
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# aarch64: compile fine but...
# aarch64: compile fine but unable to test on real hardware

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't it be # aarch64: compiles fine but unable to test on real hardware?

@ofborg ofborg bot added 10.rebuild-linux-stdenv This PR causes stdenv to rebuild 10.rebuild-darwin: 11-100 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+ and removed 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 1-10 labels Nov 1, 2023
@ghost
Copy link

ghost commented Nov 1, 2023

If you rebase this to a more recent staging (or switch branch to master) I think the ofborg rebuild tags will go away.

@RaitoBezarius
Copy link
Member Author

If you rebase this to a more recent staging (or switch branch to master) I think the ofborg rebuild tags will go away.

I just need to do it when I don't feel like I will fuck up :D.

@ghost ghost mentioned this pull request Nov 4, 2023
12 tasks
@wegank wegank added the 12.approvals: 1 This PR was reviewed and approved by one reputable person label Mar 9, 2024
@wegank wegank added the 2.status: merge conflict This PR has merge conflicts with the target branch label May 3, 2024
@TobiPeterG
Copy link

Is there any progress on this? :)

@wegank wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 4, 2024
@baloo
Copy link
Member

baloo commented Nov 3, 2024

Got CI to pass.

@ghost

I'm a bit late to the party, but I'm trying to revive it in #353050, but I'm getting compilation errors on compiler-rt and I'm not sure which derivation you tried to build. None of the options I tried worked.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Nov 3, 2024
@wegank wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jan 2, 2025
@nixos-discourse
Copy link

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

https://discourse.nixos.org/t/installation-medium-has-invalid-secure-boot-signature/58952/6

@Mic92
Copy link
Member

Mic92 commented Jan 19, 2025

This pull requests is stalled.

@Mic92 Mic92 closed this Jan 19, 2025
@RaitoBezarius
Copy link
Member Author

This pull requests is stalled.

Can I ask you the courtesy to ping the author of PR whom you close PRs? (Or put the documentation of that new nixpkgs process in your closing messages?)

Thank you.

@Mic92
Copy link
Member

Mic92 commented Jan 20, 2025

Well, do you want to work on this? You said me in several occasions that you don't want to contribute to nixpkgs anymore and working on your NixOS fork. I do not think we should add too many processes to nixpkgs because it will make it too hard to understand how to make changes, so please just re-open the pull request again if you want to work on this. Otherwise just delete the branch.

@RaitoBezarius
Copy link
Member Author

Well, do you want to work on this? You said me in several occasions that you don't want to contribute to nixpkgs anymore and working on your NixOS fork. I do not think we should add too many processes to nixpkgs because it will make it too hard to understand how to make changes, so please just re-open the pull request again if you want to work on this. Otherwise just delete the branch.

Again, all of this has nothing to do with my request. Simply ask before doing what when it comes to other people's work is what I would like you to do. Thank you.

@Mic92
Copy link
Member

Mic92 commented Jan 20, 2025

Well, usually I ask them to re-open their pull request if they want to continue to work on the pull request. But I was 95% sure you would want not do that, so I kept it at that.

@RaitoBezarius
Copy link
Member Author

Well, usually I ask them to re-open their pull request if they want to continue to work on the pull request. But I was 95% sure you would want not do that, so I kept it at that.

If you want to make up your own rules, please consider discussing it with others before applying them out of the blue, especially when it comes to the work of others. "Closing then asking to re-open" is not courtesy, it's just you doing whatever you think is acceptable to do at any time, and you are continuing to shove your view.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.status: merge conflict This PR has merge conflicts with the target branch 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 6.topic: lib The Nixpkgs function library 8.has: package (new) This PR adds a new package 10.rebuild-darwin: 11-100 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+ 10.rebuild-linux-stdenv This PR causes stdenv to rebuild 12.approvals: 1 This PR was reviewed and approved by one reputable person
Projects
None yet
Development

Successfully merging this pull request may close these issues.