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

OVMF: add passthru.mergedFirmware parameter; xen: use the merged OVMF blob #373560

Merged
merged 2 commits into from
Jan 23, 2025

Conversation

SigmaSquadron
Copy link
Contributor

Fixes #373416

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:
  • 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/)
  • 25.05 Release Notes (or backporting 24.11 and 25.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.

This is the final firmware blob that's expected by hypervisors, like Xen.
The `passthru.firmware` attribute refers to the OVMF_CODE.fd blob, which
is not aligned properly and exceeds the BIOS boundaries set by Xen.
See NixOS#373416 and https://www.mail-archive.com/[email protected]/msg118481.html

Signed-off-by: Fernando Rodrigues <[email protected]>
@github-actions github-actions bot added the 6.topic: xen-project The Xen Project hypervisor label Jan 13, 2025
@SigmaSquadron
Copy link
Contributor Author

SigmaSquadron commented Jan 13, 2025

A question: since OVMF_CODE.fd is indeed the wrong blob to use, why does everything in Nixpkgs use it as the de-facto UEFI firmware blob? Why aren't we using the merged version in things like nixos/qemu-vm?

@nix-owners nix-owners bot requested a review from philiptaron January 13, 2025 21:37
Fixes NixOS#373416

Signed-off-by: Fernando Rodrigues <[email protected]>
@github-actions github-actions bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 11-100 labels Jan 13, 2025
@nix-owners nix-owners bot requested review from hehongbo and CertainLach January 13, 2025 21:43
@adamcstephens
Copy link
Contributor

A question: since OVMF_CODE.fd is indeed the wrong blob to use, why does everything in Nixpkgs use it as the de-facto UEFI firmware blob? Why aren't we using the merged version in things like nixos/qemu-vm?

I couldn't find any official documentation on qemu's site for working with OVMF, but it obviously works as configured. As I understand it the split is to provide the CODE/fw as read-only, but allow for a separate VARS location for read-write state. If you combine them, this could in theory reduce security as the boot code could be modified by the VM in read-write mode.

I wasn't aware until this Xen issue that there was even a combined version. Maybe other hypervisors care as well, but qemu doesn't consider the separated files "wrong".

@wegank wegank added the 12.approvals: 1 This PR was reviewed and approved by one reputable person label Jan 15, 2025
@philiptaron
Copy link
Contributor

Unrelated to this PR: is there a thought to move the pkgs/build-support/xen into pkgs/by-name/xe/xen in some way? They appear deeply connected.

@adamcstephens adamcstephens merged commit 37b9208 into NixOS:master Jan 23, 2025
26 of 28 checks passed
@SigmaSquadron SigmaSquadron deleted the push-knuzomwlzmvy branch January 23, 2025 16:55
@SigmaSquadron
Copy link
Contributor Author

is there a thought to move the pkgs/build-support/xen into pkgs/by-name/xe/xen in some way? They appear deeply connected.

I don't think we can, because we need the generic builder in order to build variants of Xen, like the one in #341429. We would need to have callPackage ../../xe/xen/package.nix in qubes-vmm-xen, or duplicate the entire builder.

@adamcstephens
Copy link
Contributor

adamcstephens commented Jan 23, 2025

It's against by-name rules (and the CI checks) to reference across packages in by-name. You could probably move the builder to by-name/bu/buildXenPackage/package.nix for auto loading though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
6.topic: xen-project The Xen Project hypervisor 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin 10.rebuild-linux: 11-100 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.

OVMF passthru.firmware: MMIO emulation failed
4 participants