Commit Graph

9 Commits

Author SHA1 Message Date
Ryan Lahfa 614b538f0f
Merge pull request #305 from nix-community/prepare-stub-for-dynamic-initrds
stub(*): support dynamic initrds
2024-03-01 08:24:07 +00:00
Raito Bezarius e2e8059df2 stub(*): merge dynamically initrds
For dynamic usecases, e.g. credentials or system extension images, we have a need
for dynamic merging of initrds.
2024-02-11 19:52:15 +01:00
Raito Bezarius 88bcd99ca8 stub(*): support dynamic initrds
With this feature, it is now possible to load dynamic initrds (possibly read from filesystem or generated on the fly)
and extend existing initrds.

This feature will be useful to implement addons in the future.
2024-02-11 19:52:11 +01:00
Julian Stecklina 5de0b3e54a stub: rename sections for UKI compatibility
systemd 255 is stricter in what it considers UKIs. It demands .linux
and .initrd sections. Rename our sections that contain the respective
filenames to match these names.
2024-02-10 20:53:15 +01:00
nikstur 234e4da1f3 rust-toolchain: 1.70 -> 1.75 2024-01-21 15:29:42 +01:00
Alois Wohlschlager b02a7e2a7f
stub: use command line from loader in insecure mode
When booting without Secure Boot active, it is not necessary to defend
against a malicious command line being passed from the loader. So just
use it in this case, to facilitaty some debugging and recovery use
cases.

Fixes: https://github.com/nix-community/lanzaboote/issues/226
2023-10-15 16:04:30 +02:00
Alois Wohlschlager db39223a7c
stub: make handling of insecure boot more explicit
When Secure Boot is not available (unsupported or disabled), Lanzaboote
will attempt to boot kernels and initrds even when they fail the hash
verification. Previously, this would happen by falling back to use
LoadImage on the kernel, which fails if Secure Boot is available, as the
kernel is not signed.
The SecureBoot variable offers a more explicit way of checking whether
Secure Boot is available. If the firmware supports Secure Boot, it
initializes this variable to 1 if it is enabled, and to 0 if it is
disabled. Applications are not supposed to modify this variable, and in
particular, since only trusted applications are loaded when Secure Boot
is active, we can assume it is never changed to 0 or deleted if Secure
Boot is active.
Hence, we can be sure of Secure Boot being inactive if this variable is
absent or set to 0, and thus treat all hash verification errors as
non-fatal and proceed to boot arbitrary kernels and initrds (a warning
is still logged in this case). In all other cases, we treat all hash
verification failures as fatal security violations, as it must be done
in the case where Secure Boot is active (it is expected that this does
not lead to any false positives in practice, unless there are bigger
problems anyway).
2023-10-15 15:58:01 +02:00
Julian Stecklina 17cadf6598 stub: update to latest uefi crates 2023-10-12 12:12:34 +02:00
nikstur 83f4376929 uefi: move uefi code to separate workspace 2023-09-13 17:46:05 +02:00