Update after Morten Linderud comments

Some sentenses were badly worded and did not convey the meaning I
intended.
There also was a blatent error regarding the number of UEFI executables
signed with the Microsoft Third Party CA.

posts/secure_boot.md

@@ -30,12 +30,13 @@ software.
 
 ## Secure Boot, the technology
 
-Secure Boot[^spec] is an attempt at ensuring that only authorized software is run on a
-machine. It does so by bootstrapping the security of the system at boot time,
-giving way to other technologies to keep the system secure, later on. Secure
-boot works by authorizing only select executables to be run. Authorized
-executables are signed using public cryptography, and the keys used to verify
-those signatures are stored securely in UEFI "databases".
+Secure Boot[^spec] helps running only authorized software on a machine. It
+does so by bootstrapping the security of the system at boot time, by verifying
+signatures on various software components, before giving way to other
+technologies to keep the system secure, later on. Secure boot works by
+authorizing only select executables to be run. Authorized executables are
+signed using public cryptography, and the keys used to verify those signatures
+are stored securely in UEFI "databases".
 
 [^spec]: [UEFI Specifications](https://uefi.org/specs/access)
 
@@ -48,17 +49,19 @@ the case of GNU/Systemd/Linux, the bootloader runs the Linux kernel, which
 shuts down all UEFI Boot Services, before dropping its privileges and then
 doing "Linux stuff" (like starting the userland part of the operating system).
 This privilege drop is very important because this is what ensures that no code
-past that point is able to tamper with the UEFI environment, including UEFI
-variables, which contains sensitive data.
+past that point is able to tamper with the UEFI sensitive information,
+including UEFI variables, which contains sensitive data.
 
 Secure Boot aims at securing "everything" that is executed prior to that
-privilege drop. Once the privileges are drop, it is up to the operating system
-to ensure that only authorized software is run. Most Linux distros do not even
-try to do it, although there are notable exceptions (Chrome OS, Android, just
-to name a few). If we run one of the distros that do not leverage technologies
+privilege drop. Once the privileges are drop, Secure Boot is done and it is up
+to the operating system to extend that integrity/authenticity protection and
+ensure that only authorized software is run. Most Linux distros do not even try
+to do it, although there are notable exceptions (Chrome OS, Android, just to
+name a few). If we run one of the distros that do not leverage technologies
 such as dm-verity, fs-verity (with signatures) or Linux IMA (Integrity
-Management Architecture), then Secure Boot is strictly insufficient to protect
-user data integrity or even system integrity in general.
+Management Architecture), then Secure Boot protected the boot integrity for
+basically nothing, because the security chain is broken by the operating
+system, and user data is at risk from possibly any tainted userland executable.
 
 Nevertheless, ANSSI, the French Infosec Agency recommends in its GNU/Linux
 security guide[^linuxguide] to enable Secure Boot (R3) for all systems
@@ -88,11 +91,12 @@ attempts to prove that it is not only useless but incoherent and misleading.
 Secure boot relies on a set of public keys to verify authorized software
 authenticity. By default, most vendors ship Microsoft public keys. These keys
 sign all Microsoft Windows version, of course, but to avoid a monopoly, other
-executables were signed. The list is rather short because with each signature
-and authorized software, the attack surface grows and the probability of a
-vulnerability raises. Several were already found in the recent past (e.g.
-CVE-2020-10713[^CVE-2020-10713], CVE-2022-34301[^CVE-2022-34301],
-CVE-2022-34302[^CVE-2022-34302], CVE-2022-34303[^CVE-2022-34303].
+executables were signed. The list is ought to be short (and unfortunately, it
+is not) because with each signature and authorized software, the attack surface
+grows and the probability of a vulnerability raises. Several were already found
+in the recent past (e.g. CVE-2020-10713[^CVE-2020-10713],
+CVE-2022-34301[^CVE-2022-34301], CVE-2022-34302[^CVE-2022-34302],
+CVE-2022-34303[^CVE-2022-34303].
 
 [^CVE-2020-10713]: [CVE-2020-10713](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10713)
 
@@ -110,15 +114,16 @@ Intel[^intelUpgrade] or Lenovo[^lenovoUpgrade].
 
 [^lenovoUpgrade]: [Lenovo flash BIOS with UEFI tool](https://support.lenovo.com/us/en/solutions/ht118103-flash-bios-with-uefi-tool-ideacentre-stick-300)
 
-Grub and the kernels are not directly authorized by Microsoft, as it would
+Grub and the kernels are not directly authorized by Microsoft, as it would
 require for each and every single version to be signed individually by
 Microsoft. Instead, a binary called Shim[^shim] was developed. This rather
 small, auditable, innocuous-looking program is signed by Microsoft. Its role is
-basically that of a trojan horse. Indeed, its only purpose is to
-cryptographically verify the authenticity of any executable. However, this
-time, the list of public keys used to verify these executables is not directly
-under the control of Microsoft. These public keys are either built in Shim
-itself or stored in a EFI variable serving as a database.
+basically that of a trojan horse (or a security pivot, depending on the way you
+look at it). Indeed, its only purpose is to cryptographically verify the
+authenticity of any executable. However, this time, the list of public keys
+used to verify these executables is not directly under the control of
+Microsoft. These public keys are either built in Shim itself or stored in a EFI
+variable serving as a database.
 
 [^shim]: [shim source code](https://github.com/rhboot/shim)