But at this point I think it's pretty clear that Secure Boot as a technology has done exactly what the critics have said since its original proposal: it offers a modest theoretical security increase but delivers a huge vendor lock-in tool. Net negative.

This (in-home abuse) is a legitimate use case but even then, it's pretty unlikely for an abuser to know how to install a compromised kernel but not (e.g.) a physical keylogger or a hidden camera pointed at the keyboard.

TPM is for CEO LARPers, because *of course* it is.

(For abuse, you want something that's hidden AND encrypted AND deniable. E.g. local VM images that you use for schoolwork but are easy to accidentally set to encrypted.)

in non-embedded computers, secure boot is often meant to be used in conduction with the TPM. disabling secure boot would change the PCR measurements, and thus render (for example) the disk encryption keys inaccessible

That latter approach is actually slightly _easier_ than backdooring a kernel.

¹ some disclaimers apply, maybe lots of disclaimers in practice given various UEFI implementation bugs and etc, never mind servers that have IPMI/BMC access to UEFI settings and etc etc.

To be fair, it actually *is* some bullshit that isn't protecting anyone from anything real.

(The primary goal of SB is to protect your data from a specific type of high-cost targeted attack that affects C-level executives and nobody else. If you're not carrying investment plans or nuclear launch codes, turn it off and use full-disk encryption instead. That's all you need.)

(GF had a bitlocker issue recently, which she had never enabled...I had a mild panic attack that she'd lost everything to some ransomware but it was more of a manufacturer's default password situation -- so similarly bullshit lol)