Noone asked me, but if you are curious what my take on the recent sbat/SecureBoot kerfuffle is, I'll let you know anyway:

Frankly, I find SecureBoot ultimately pretty uninteresting tech. It casts a very wide net: it basically is a politically charged global allowlist, yet is useful as a very very lose denylist only, because it necessarily contains so so so much stuff. I think the value for security is relatively limited, because it it attempts to be universal, and hence can never be focussed.

Much more interesting is Measured Boot when tying disk encryption to it. Various OSes, including Windows have been supporting this since about forever. And it's so much better: it basically makes no restrictions on what you can run on your PC. All it enforces is: my encrypted disk can only be decrypted if the OS of my choice is booted in the version of my choice. And that's a *way* more powerful concept, because it is *focussed* on your installation, because…

…it is is "democratic", in the sense that anyone can do this without having to get their keys into some centralized keyring.

Hence, to me it implications of SB are simply not worth it, it brings very little to the table security wise, but creates massive headaches on deployment. MB otoh actually provides a high level of security, and you don't have to ask anyone to put together your own policies.

Hence if you ask me: focus on making MB a thing on Linux, and bother with SB only to the level…

…you really have to.

(I am trying to do my part on this of course, i.e. in systemd we measure a lot of things during boot now, and our FDE logic is hooked up with it.)

[That all said, I think SB might have some value if you enroll your own keys, which however can only work on very specific hw, and in VMs, but is probably not a solution realistic for general purpose PCs]

One beef I have with GNU/FSF folks btw, is that they started that abominable campaign against TPMs back in the day, completely misunderstanding that TPMs are kinda the "democratic" thing, and if anything they should have criticized SecureBoot, but not TPMs.

@pid_eins What about enrolling your own keys and manually signing your kernels?

@anselmschueler see further down in the thread. I already commented about that.

Measured boot can be a powerful technology for users, but it's also an extremely dual-use technology with both good ("trust your software stack and results") and bad ("website trusts that your browser will display ads and not allow copying/saving"; "app trusts that you don't have root on your phone") uses. Doubly so with the possibility of remote attestation.

@josh well, if you open up access to your logs (protected via measurements or not) to players you don't want to use them, it's kinda your own fault. Just don't do that. If you web browser passes quotes of your system to the web, it's a bug in the browser, not a problem of the TPM.

Every computing is dual-use, if you so will, I fail to see why this one should be more or less "dual-use" than anything else.

@pid_eins Isn't this what macOS is doing these days on the M-series machines?

The problem comes in when a service provider requires that information as a condition of receiving service.

I'm not saying the existence of the technology is a net negative, just that it isn't an unalloyed good.

@josh after 15 years of TPMs and they becoming quite ubiquitious, I am still not seeing how they ever have been misused like this outside of theories and labs.

To me this appears to be mostly FUD from FSF/GNU.

I think if Linux OSes would actually start using TPMs properly, the net outcome for everyone would be *good*, and not bad. It would be much harder to gain persistence for an attacker, for example. And that's a massive benefit, for everyone.

TPMs mostly haven't been. Secure enclaves *have*, though, quite extensively.

@duxsco yeah, I have doubts though that enrolling your own keys is something that can be made "just work" on general purpose PCs.

Yes, you can do it locally, if you know your hardware very well, or if you only care about VMs or so. But for the general population, I doubt self-enrolling is really an option. Too many problems given that hw extension cards provide signed firmware too.

@pid_eins Yep, it is more like a protocol for interoperation. Not having TPM standard would result the FSF's doomsday scenario.

@pid_eins is there a post where you explain your standpoint on tpms in more detail? in particular, do you think that owners of physical machines have power over TEEs?

@slink secure enclaves and tpms are different things. You can implement a vtpm in a secure enclave of course, but from a tpm user pov that is a mostly irrelevant detail.

I have never played much with secure enclaves directly. But if done correctly I think they would be great to have, so far the track record on what intel provided there wasn't that stellar though.

@pid_eins but the default Windows behaviour for measured boot is tied to secure boot because using anything other than PCR 7 is extremely fragile

@duxsco my own focus with systemd is definitely on providing generic components that help make any Linux based systems more secure. hence, I do care a lot about solutions that provide security and can be deployed on *generic* systems in the wild, without prior knowledge of what they provide or not. It's the "general population", or the broader IT ecosystem I care about, not some nerdy niche.

@mjg59 @pid_eins but this is what systemd-pcrlock solves?

@mjg59 on my windows laptop here bitlocker locks to 0, 2, 4, 8, 9, 10, 11. Which I think is today's default on modern Windows. (I certainly didn't change it). PCR 7 is not included interestingly.

And I think the TPM stuff in windows pretty much works, no?

systemd-pcrlock tries to lock to even more PCRs by default (but might exclude some if there are measurements we don't recognize).

@mjg59 ms policy editor docs seem to suggest what i just listed is actually the default binding of windows.

@pid_eins default with secure boot enabled is just 7 and 11 because otherwise you need to reseal over a bunch of real world cases

@pid_eins ah interesting it's influenced by whether or not the third party CA is used

@pid_eins @josh did you see that Google was literally proposing hardware attestation APIs for the web earlier this year? >_<

@pid_eins what the hell are you talking about https://www.fsf.org/campaigns/campaigns/secure-boot-vs-restricted-boot/ this is 2011 right after secure boot came out, and also there's tons of early motherboards that made user key enrollment impossible and to this day Microsoft have an unfair control over the whole thing. why else would you need to get shims signed by them?

@shironeko I am talking about this drivel:

https://www.fsf.org/news/treacherous.html
https://www.fsf.org/news/lifes-better-together-when-you-avoid-windows-11
https://www.gnu.org/philosophy/you-the-problem-tpm2-solves.html
https://www.fsf.org/windows/

Some of this is just plain dumb and uniformed.