On Wed, 7/15/2026 7:15 AM, Dennis wrote:
On Tue, 14 Jul 2026 23:33:41 -0400, Paul <nospam@needed.invalid> wrote:
And in other news, pass an eyeball over this.
https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/
FFS!
What a mess!
Anything that complex is screaming for a re-think.
That's the concern, that the implementation was not thought through
at all when it was invented. It's like a size 11 foot and a size 7 shoe,
for asset storage.
There was another rethink. It was called "Pluton", one laptop with
an AMD processor in it, has a prototype of Pluton inside it. The
current "status" of the Pluton project is unknown. There is one paragraph
at the end here, with a thumbnail description of it. This implies
some server-chips have it. Whether, or how many, consumer chips
have it, we don't know if it is on or off or dead.
https://en.wikipedia.org/wiki/Azure_Sphere#Microsoft_Pluton
Lots of Secure Enclave ideas, have had issues. TPM is just one
of these ideas. Intel had a Secure Enclave, it had to be
pinned off in microcode, due to the fact there was an
exploit for it, where you couldn't get the malware out of the
thing. And microcode was the switch they used, to stop that entirely.
This is a recurring pattern. The best security comes from
security schemes that are discussed in public. You need
a large audience. You need to snag the intellect of just
the right people, to find holes in your scheme. Using
just "one of our geniuses at work" is not sufficient in
a lot of these cases. Lots and lots of things can be
siloed and worked on in secret -- security and/or crypto
is not one of them. The best results come from lots of eyeballs.
*******
From the Ars article above:
"In short, where dbx revokes binaries, SBAT and Microsoft?s Secure Boot SVN revoke versions,?
Smol r explained. ?When a vulnerability is found in a UEFI application supporting one of
these version-based revocation mechanisms, what really needs to be kept out is every build up to
and including the broken one?and that can be captured by a version number much easier than by
a long list of hashes.? <=== hashes, a lot of them, stored in 4x32K area, is the normal mechanism...
Each component in the UEFI loader carries metadata that is signed by the same certificate
authenticating the binary itself. This metadata names the component and assigns it a
generation number that is incremented each time a new security fix ships. <=== SBAT file, is an example...
A boot-only variable in the UEFI stores the minimum acceptable generation number allowed
for each component.
The variable number is enforced by the shim rather than the firmware.
"
which is fine. what that does not explain, is what gates the updating
of the Boot-only variable, and is causing the Windows attempts to update SBAT to fail (that is, if it really is failing, we don't know!). Typically,
SBAT is a text file, about four lines long, for some of the mechanisms the "shim" will be enforcing. The SBAT even revokes old versions of itself.
And in case you were wondering what that shim deal is, you can attack
a Windows machine with a Linux boot material. The "armor" on the LInux
side must be present on your machine, to prevent Linux based attacks
on a machine that seems to only run Windows software. Once the door is
opened to allow other OSes to boot on a machine, the "armor" must be
maintained for all possible boot paths. That's why the Microsoft SBAT
update, has the word "GRUB" inside it, which is the Linux GRand Unified Boot.
Paul
--- PyGate Linux v1.5.18
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)