We are getting this warning:
warning: some crates are on edition 2021 which defaults to `resolver = "2"`, but virtual workspaces default to `resolver = "1"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
Silence by opting into the new behavior.
`Option<&T>` has the same ABI layout as `*const T`, so we have some room for
improvement where we get more Rust convenience. Further, a bug is fixed where
INVALID_PARAMETER wasn't returned when the BUFFER_SIZE pointer is NULL.
See UEFI 2.10 13.2.2. EFI_LOAD_FILE2_PROTOCOL.LoadFile() for reference.
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
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).
goblin 0.7.1 introduces certification support for PE files. This seems to be broken, because we get:
Parsing PE failed Malformed entity: Unable to extract certificate. Probably cert_size:1599360838 is malformed!
from goblin when trying to parse our PE file in memory.
See #237 for context.
This includes the options of all modules used in the evaluation, not
just the ones from `<nixpkgs/nixos>` in the local manual.
Right now this breaks with
error: attribute 'loader' missing
at /nix/store/wf59fvxch3l5s7x0pnpfv7b26q6y010x-source/nix/modules/lanzaboote.nix:26:17:
25| configurationLimit = mkOption {
26| default = config.boot.loader.systemd-boot.configurationLimit;
| ^
27| example = 120;
I'm not sure what's up with `config.boot.loader` (had the exact same
issue with `disko`), but using `defaultText` is the common workaround
for that.
Due to the temporarily doubled ESP space usage, it is now easier to run
into the out of space issue (once). Document how to proceed in this case
without having to delete any generations.
Furthermore, recovery in case of ESP corruption is now slightly more
involved, because not all files are rewritten all the time. Adjust the
documentation accordingly.
Atomic write works by first writing a temporary file, then syncing that
temporary file to ensure it is fully on disk before the program can
continue, and in the last step renaming the temporary file to the
target. The middle step was missing, which is likely to lead to a
truncated target file being present after power loss. Add this step.
Furthermore, even with this fix, atomicity is not fully guaranteed,
because FAT32 can become corrupted after power loss due to its design
shortcomings. Even though we cannot really do anything about this case,
adjust the comment to at least acknowledge the situation.
Since most files (stubs, kernels and initrds) on the ESP are properly
input-addressed or content-addressed now, there is no point in
overwriting them any more. Hence we detect what generations are already
properly installed, and don't reinstall them any more.
This approach leads to two distinct improvements:
* Rollbacks are more reliable, because initrd secrets and stubs do not
change any more for existing generations (with the necessary exception
of stubs in case of signature key rotation). In particular, the risk
of a newer stub breaking (for example, because of bad interactions
with certain firmware) old and previously working generations is
avoided.
* Kernels and initrds that are not going to be (re)installed anyway are
not read and hashed any more. This significantly reduces the I/O and
CPU time required for the installation process, particularly when
there is a large number of generations.
The following drawbacks are noted:
* The first time installation is performed after these changes, most of
the ESP is re-written at a different path; as a result, the disk usage
increases to roughly the double until the GC is performed.
* If multiple generations share a bare initrd, but have different
secrets scripts, the final initrds will now be separated, leading to
increased disk usage. However, this situation should be rare, and the
previous behavior was arguably incorrect anyway.
* If the files on the ESP are corrupted, running the installation again
will not overwrite them with the correct versions. Since the files are
written atomically, this situation should not happen except in case of
file system corruption, and it is questionable whether overwriting
really fixes the problem in this case.
The stubs on the ESP are now input-addressed, where the inputs are the
system toplevel and the public key used for signature. This way, it is
guaranteed that any stub at a given path will boot the desired system,
even in the presence of one of the two edge-cases where it was not
previously guaranteed:
* The latest generation was deleted at one point, and its generation
number was reused by a different system configuration. This is
detected because the toplevel will change.
* The secure boot signing key was rotated, so old stubs would not boot
at all any more. This is detected because the public key will change.
Avoiding these two cases will allow to skip reinstallation of stubs that
are already in place at the correct path.
Julian Stecklina