[Karunamon]

The fact that I can do the same thing with firmware on a cheap ROM write-protected with a jumper

Except secure boot isn't about firmware, it's about the code loaded on DASDs.

>With Microsoft and Intel style secure boot, it remains in the hands of Microsoft and Intel.

As long as you can program your own keys into it, I'm not sure how you come to that conclusion.

[dsp1234]

As long as you can program your own keys into it

Is this not the definition of gatekeeper?

A system where you have to ask permission, but that permission is always granted is inherently different from a system where no permission is ever needed.

Among other things, that permission can be revoked at any time for any reason.

[Karunamon]

but that permission is always granted is inherently different from a system where no permission is ever needed.

Indeed. And that system, the one we've been using for a few decades leaves you vulnerable to bootkits in such a way that you'll never know you've been owned.

The PKI has to have a trust root anchored somewhere for the concept to work, and it can be anchored under your control using your keys.

[nickpsecurity]

No, we've been using a shitty system that's a legacy holdover from days and companies that don't care about security at all. You could just as easily design a system that had a safe, vetted firmware with nonvolatile storage inside. With a jumper or secret, you can put in new firmware you designed yourself or trust from others. That gets stored in there for later stage in a multi-stage boot process. That initial part is immutable means you can always reset if something happens. Secret can be generated on device and displayed to you via a dedicated serial port if you want.

Many possibilities. The idea that trusted boot can only work if Microsoft controls the secret and says a third party I.P. is allowed is ludicrous. Disproven by other implementations that didn't require them. Worst case, the root of trust is put in during first initialization with antifuses burning it in and pre-wired stuff reading results back out as maybe a hash. You can always know what you're starting with via a hash and it can't change after being set that first time.

For some reason, you're limiting yourself to only third-party, PKI solutions with high TCB and trust issues. The stuff I described has been immune or resistant to bootkits since the old mainframes that required you to physically insert write-protected firmware:

https://en.wikipedia.org/wiki/GEC_4000_series

Today, that could be a disk, SD card, USB drive, or smartcard you made yourself.

[Karunamon]

I'm still not sure why we're talking about firmware in the context of secure boot. The firmware isn't changing and isn't vulnerable to being rewritten by something with system permissions (excepting microcode updates and the like) - the boot sector is, which is exactly the thing that secure boot cares about.

[nickpsecurity]

"Among other things, that permission can be revoked at any time for any reason."

BOOM! They can charge you for it and they can revoke it. Many companies did "open" platforms or software that later closed things off. Plus, they get more information about you than they even need.

So, we can choose between a security standard that's in our control or theirs. And by theirs, we're talking about companies with a history of real scumbaggery. The design should default to us with no asking for permission. Numerous ones in CompSci and I.P. markets can do that. No excuse except Microsoft and Intel's profits and schemes.