diff options
| author | Serge Hallyn <serge@hallyn.com> | 2021-07-14 07:49:34 -0500 |
|---|---|---|
| committer | Peter Jones <pjones@redhat.com> | 2021-07-15 18:55:56 -0400 |
| commit | 9a8a6cdb5e862648ee663eee6124bed05208639a (patch) | |
| tree | 51c4a4aabf554ed40bcb1ced020d98cb3d93116a | |
| parent | 9f973e4e95b1136b8c98051dbbdb1773072cc998 (diff) | |
| download | efi-boot-shim-9a8a6cdb5e862648ee663eee6124bed05208639a.tar.gz efi-boot-shim-9a8a6cdb5e862648ee663eee6124bed05208639a.zip | |
SBAT.md: trivial fixes
1. Use : instead of , to separate a list.
2. Fix spelling of therefore.
3. Pull unrelated clause out of parenthesized clause.
Signed-off-by: Serge Hallyn <serge@hallyn.com>
| -rw-r--r-- | SBAT.md | 6 |
1 files changed, 3 insertions, 3 deletions
@@ -6,7 +6,7 @@ In the PC ecosystem, [UEFI Secure Boot](https://docs.microsoft.com/en-us/windows is typically configured to trust 2 authorities for signing UEFI boot code, the Microsoft UEFI Certificate Authority (CA) and Windows CA. When malicious or security compromised code is detected, 2 revocation mechanisms are provided by -compatible UEFI implementations, signing certificate or image hash. The UEFI +compatible UEFI implementations: signing certificate or image hash. The UEFI Specification does not provides any well tested additional revocation mechanisms. @@ -269,7 +269,7 @@ that the global generation numbers will eventually move forward and exclude those products from booting on a UEFI Secure Boot enabled system. However a product made up of GRUB and a closed source kernel is just as conceivable. In that case the kernel version may never move forward once the product reaches -its end of support. Therefor it is recommended that the product-specific +its end of support. Therefore it is recommended that the product-specific generation number be incremented past the latest one shown in any binary for that product, effectively disabling that product on UEFI Secure Boot enabled systems. @@ -309,7 +309,7 @@ compromise. The initial SBAT implementation will add SBAT metadata to Shim and GRUB and enforce SBAT on all components labeled with it. Until a component (e.g. the -Linux kernel gains SBAT metadata) it can not be revoked via SBAT, but only by +Linux kernel) gains SBAT metadata it can not be revoked via SBAT, but only by revoking the keys signing that component. These keys will should live in separate, product-specific signed PE files that contain **only** the certificate and SBAT metadata for the key files. These key files can then be |