Re: The Achilles Heel Of Secure Boot: Certificate Revocation
Nuno Silva <[email protected]>
| Newsgroups | comp.misc |
|---|---|
| Organization | A noiseless patient Spider |
| Message-ID | <[email protected]> |
On 2026-07-17, Scott Dorsey wrote: > Lawrence =?iso-8859-13?q?D=FFOliveiro?= <[email protected]> wrote: >>On Wed, 15 Jul 2026 12:20:09 -0000 (UTC), John McCue wrote: >> >>> IMO I always believed this is a ploy by Microsoft to lock down PCs >>> similar to what is going on with Smart Phones. But so far it has >>> failed due to pushback by various Linux Companies. If Linux was at >>> the point it was in the 90s, I think M/S would have succeeded. >> >>There is a genuine risk from attackers getting physical access to the >>machine -- Secure Boot was an attempt to defend against this sort of >>thing. > > I think the very idea of trying to block an attacker with physical > access is probably misguided. There are some applications for which it > may actually be useful but there are far more systems where availability > is as or more important than confidentiality. > >>But you are right in that Microsoft’s implementation has been >>typically poorly managed and riddled with holes. > > I think the concept is a bad one, and I think that invariably you are going > to have a single point of failure which is bad. Having it be microsoft is > just worse. > --scott And even without Microsoft, this appeared in an area that's not exactly known for compliance and perfect implementation. Secure Boot and UEFI, this time we will get PC firmware right, pinky promise! And considering Microsoft, don't forget it'd not be the first time they intentionally tried to break compatibility at the firmware level to put other systems at a disadvantage: On 1999-01-24, Bill Gates wrote: > One thing I find myself wondering about is whether we shouldn't try > and make the "ACPI" extensions somehow Windows specific. > > If [sic] seems unfortunate if we do this work and get our partners to > do the work and the result is that Linux works great without having to > do the work. > > Maybe there is no way to avoid this problem but it does bother me. > > Maybe we could define the APIs so that they work well with NT and not > the others even if they are open. > > Or maybe we could patent something related to this. (transcribed from the PDF below, apologies for any transcription error, caffeine still kicking in) <https://web.archive.org/web/20070202174648if_/http://www.iowaconsumercase.org/011607/3000/PX03020.pdf> -- Nuno Silva