docs: tweaks to the boot loader spec #10415
Conversation
bdf0552 to
28d8187
Compare
A couple of changes: 1. Clearly name the drop-in entry files "Type #1", and the unified kernel images "Type #2", and be clearer that the latter is specific to UEFI. 2. Suffix all directory paths with a trailing "/" to clarify that these are directories. Also, enclose them all in ``. 3. Add introductory paragraph that explains that there is Type #1 and Type #2 and what they are about. 4. Explain that Type #2 is about signed UEFI SecureBoot. 5. Don't claim that $BOOT/loader/ contains really all files defined by the spec, because that's not true, Type #2 images are not located there after all. Fixes: systemd#10399
This is not what distros use, let's not point users to obsolete stuff.
b1dcd3a to
07ec9c8
Compare
i-c-o-n
left a comment
There was a problem hiding this comment.
Looks good. I like the clear distinction. Makes it easier to refer to BLS; e.g. a boot loader can document that it implements BLS Type#1.
@poettering
Though, as I'm not involved with (U)EFI, I have some general questions left. You mentioned somewhere else, the PE format would be required for SecureBoot. Is that to allow the EFI firmware to load the Unified Image directly? Or is the signature verification of UEFI SecureBoot offered as some kind of service that the boot loader uses? If the boot loader would implement the signature verification it wouldn't be tied to a specific format, I guess.
And about the file path: Why not place the Unified Images in /loader/entries/ too?
|
thanks for the review! much appreciated. let's merge. |
Yes, UEFI firmeware executes PE binaries directly, and if SecureBoot is enabled it will check the signature while doing so. Hence, if we create unified images we pack the kernel, the initrd, the cmdline, some metadata and a boot logo to display in one single PE image that hence can be signed as one and hence can be validated directly by the firmware.
There are other schemes. sd-boot (the EFI boot menu thingy included in systemd for those who care) also has support for the sim/mok EFI protocol, which is an alternative way to do validation. In that case it's not the firmware itself that validates, but it has a much more specific usecase.
|
The EFI spec suggests you put your stuff into |
A couple of changes:
Clearly name the drop-in entry files "Type build: generate pkg-config files during configure #1", and the unified
kernel images "Type path-lookup: use secure_getenv() #2", and be clearer that the latter is specific
to UEFI.
Suffix all directory paths with a trailing "/" to clarify that these
are directories. Also, enclose them all in ``.
Add introductory paragraph that explains that there is Type build: generate pkg-config files during configure #1 and
Type path-lookup: use secure_getenv() #2 and what they are about.
Explain that Type path-lookup: use secure_getenv() #2 is about signed UEFI SecureBoot.
Don't claim that $BOOT/loader/ contains really all files defined by
the spec, because that's not true, Type path-lookup: use secure_getenv() #2 images are not located there
after all.
Fixes: #10399