Newer
Older
From 9a8a6cdb5e862648ee663eee6124bed05208639a Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serge@hallyn.com>
Date: Wed, 14 Jul 2021 07:49:34 -0500
Subject: [PATCH 08/26] SBAT.md: trivial fixes
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
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>
---
SBAT.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/SBAT.md b/SBAT.md
index 1a5ecad..c1edf15 100644
--- a/SBAT.md
+++ b/SBAT.md
@@ -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
--
2.32.0