A different threat model

Posted Mar 3, 2026 15:50 UTC (Tue) by tux3 (subscriber, #101245)
Parent article: Garrett: To update blobs or not to update blobs

So this presents various things to consider that might be brought up by different sides, but this is mostly centered on whether the vendor might be attacking you via updates vs via the original hardware that you already implicitly trust.
But often my threat model is the opposite, on modern hardware it's like the *user* is the threat in the threat model!

It's not that I expect a state-sponsored attacker to burn a CPU-level backdoor to root my home devices, where I don't have any valuable $WORK stuff or that I'm hiding evil plans to [redacted] the [redacted]. But I still don't like not being the owner of the firmware I run. I don't trust closed firmware not to be a buggy mess in general, alleged backdoors or not.

When my AMD CPU has a vuln that allows a local attacker to load unsigned microcode, I want it patched on my servers, and I absolutely want it unpatched on my homes devices, because maybe I will get to be the threat in the threat model and run my own code on the CPU I bought, someday. If the BIOS has a flaw that lets me patch it with unsigned code, that's wonderful. Maybe someday I will be able to patch open firmware.
I won't upgrade my Sony headphone's firmware, because the airoha vuln might finally let me patch the voices and customize the unused button to stop it auto-connecting to the wrong device every time it boots.
I won't upgrade my console's firmware. Maybe someday someone finds a glitch and I can have my music player, and my ebook reader, and all my little homebrews that I like.
I wish I could glitch my Android phone to bypass verified boot. But that one I update, à contrecœur .

I trust the hardware vendors to not burn expensive backdoors on me, but I don't trust their firmware to do things that are in my best interest, or increasingly that let me run code at all without hardware attestation getting in the way.
Patch your servers. Break your home devices.

to post comments

A different threat model

Posted Mar 3, 2026 15:58 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> because maybe I will get to be the threat in the threat model and run my own code on the CPU

....While also enabling other bad actors to do the same.

A different threat model

Posted Mar 3, 2026 16:02 UTC (Tue) by tux3 (subscriber, #101245) [Link] (2 responses)

It's relevant that these vulns tend to be local privesc from root to CPU firmware. But any important data I have is in home anyways (XKCD 1200. There's always a relevant XKCD!).
If I'm a bad actor, I will do supply chain attacks against $PACKAGE_MANAGER and watering hole exploits in Firefox long before considering setting up a rootkit via microcode.

A different threat model

Posted Mar 3, 2026 16:33 UTC (Tue) by amw (subscriber, #29081) [Link]

Here's the link to save everyone having to do the search: https://xkcd.com/1200/

A different threat model

Posted Mar 3, 2026 17:12 UTC (Tue) by MortenSickel (subscriber, #3238) [Link]

In fact, this time there are two xkcds: https://xkcd.com/538/

A different threat model

Posted Mar 5, 2026 13:03 UTC (Thu) by davecb (subscriber, #1574) [Link] (1 responses)

I wonder if the machine should generate their own update key on first use and publish it to the user. It would have to be a fairly stringent first use (ie, no user data present), or attackers would just do an os reinstall to give them an attack path.

A different threat model

Posted Mar 5, 2026 14:14 UTC (Thu) by intelfx (subscriber, #130118) [Link]

> I wonder if the machine should generate their own update key on first use and publish it to the user. It would have to be a fairly stringent first use (ie, no user data present), or attackers would just do an os reinstall to give them an attack path.

In an ideal world, absolutely.

In the word we live in, though, the vendors have every incentive (financial and otherwise) to absolutely oppose anything of the sort.