[Karunamon]

ME is one thing (though given the hoops one must jump through to set it up, I'm inclined to believe most of the vitriol directed at it is the paranoid FUD variety),

..but secure boot? What possible reason could you have for being against a system that prevents bootkits from pwning your machine? You can load your own keys and boot whatever OS you want on all but a tiny subset of appliance-like locked down hardware nobody cares about.

In general, code signing is a Good Thing, so long as the control remains in the hands of the user.

[nickpsecurity]

"..but secure boot? What possible reason could you have for being against a system that prevents bootkits from pwning your machine?"

The fact that I can do the same thing with firmware on a cheap ROM write-protected with a jumper. Additionally, the fact that there's competing I.P. in FOSS and corporate sectors for firmware that does trustworthy boot while leaving what's allowed in my control.

"In general, code signing is a Good Thing, so long as the control remains in the hands of the user."

With Microsoft and Intel style secure boot, it remains in the hands of Microsoft and Intel. And so on. Which is why we're against it.

[p_l]

Except that "Setup Mode" exists and every serious computing device that uses Secure Boot provides it, because big business customers wants it.

What is "Setup Mode"? It's "load your own root of trust and wipe any preinstalled keys". Nothing, nothing says that the root of trust has to be from Microsoft or Intel (and Secure Boot specification that is tested for Windows Logo certification would reject such system unless manufactured by Microsoft or Intel).

The difference with jumper is that you have standardized APIs etc. for the signing process, including a standardized "jumper".

[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.