docs: Remove references to shim as we don't directly support it
This commit is contained in:
parent
559bb10fa9
commit
0fea596ed7
|
@ -17,9 +17,9 @@ in the config file provides as much security as encrypting the kernel does.
|
|||
### What? But what if someone modifies the config file! Ha! You clearly have not thought about that!
|
||||
|
||||
We have. While this is a pointless effort on legacy x86 BIOS, it is a reasonable expectation on UEFI systems with Secure Boot. Limine provides a
|
||||
way to modify its own EFI executable to bake in the BLAKE2B checksum of the config file itself. The EFI executable gets then enrolled or otherwise
|
||||
verified by the Secure Boot loader through, eg., the shim project. This prevents modifications being done to the config file (and in turn the
|
||||
checksums contained there) from going unnoticed.
|
||||
way to modify its own EFI executable to bake in the BLAKE2B checksum of the config file itself. The EFI executable can then get signed with
|
||||
a key added to the firmware's keychain. This prevents modifications to the config file (and in turn the checksums contained there)
|
||||
from going unnoticed.
|
||||
|
||||
### What about ext2/3/4? Why is that supported then?
|
||||
|
||||
|
|
|
@ -141,7 +141,8 @@ either the root, `limine`, `boot`, or `boot/limine` directory of one of the
|
|||
partitions, formatted with a supported file system (the ESP partition is recommended).
|
||||
|
||||
### Secure Boot
|
||||
Limine can be booted with secure boot using shim. This will also allow one to enroll
|
||||
Limine can be booted with secure boot if the executable is signed and the key used to
|
||||
sign it is added to the firmware's keychain. This should be done in combination with enrolling
|
||||
the BLAKE2B hash of the Limine config file into the Limine EFI executable image itself for
|
||||
verification purposes.
|
||||
For more information see the `limine-enroll-config` program and [the philosophy](/PHILOSOPHY.md).
|
||||
|
|
Loading…
Reference in New Issue