Garrett: To update blobs or not to update blobs

[Posted March 3, 2026 by corbet]

Matthew Garrett examines the factors that go into the decision about whether to install a firmware update or not.

I trust my CPU vendor. I don't trust my CPU vendor because I want to, I trust my CPU vendor because I have no choice. I don't think it's likely that my CPU vendor has designed a CPU that identifies when I'm generating cryptographic keys and biases the RNG output so my keys are significantly weaker than they look, but it's not literally impossible. I generate keys on it anyway, because what choice do I have? At some point I will buy a new laptop because Electron will no longer fit in 32GB of RAM and I will have to make the same affirmation of trust, because the alternative is that I just don't have a computer.

to post comments

A different threat model

Posted Mar 3, 2026 15:50 UTC (Tue) by tux3 (subscriber, #101245) [Link] (6 responses)

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.

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.

Generating Cryptographic Keys, etc.

Posted Mar 3, 2026 17:43 UTC (Tue) by eharris (guest, #144549) [Link]

So...all my (our) encryption/decryption is done air-gapped, and all our keys start off around 20,000 bits long.
Of course the encrypted material goes via the usual channels (Signal, Telegram, WhatsApp etc)....but so what?
The plain text is ALWAYS offline.....and even if the keys get weakened by bad actors....they are still HUGE!
and RANDOM!

Suppose there are weakened keys......it's still MONTHS before the snoops get to break them! Too late!!

Did I mention multiple encryption? No worries...as they say in Australia!

There is another varient of why an update might pose a threat after purchase

Posted Mar 3, 2026 17:44 UTC (Tue) by brunowolff (guest, #71160) [Link] (4 responses)

A government might require the manufacturer to target your IP address with a hostile update to avoid doing a black bag update to your machine. You'd have to be a pretty high value target for this to happen.

There is another varient of why an update might pose a threat after purchase

Posted Mar 3, 2026 17:54 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

If we're talking about an otherwise free OS, they'd need to compel the manufacturer (to modify and sign the update) and also whatever third party channel is used to distribute that (either a distro or the LVFS). There's various ways we could mitigate this (additional parties hosting hashes of each update, remote attestation of the service so we can verify we're communicating with something running the published source code, that kind of thing) if it feels like a sufficient therat.

There is another varient of why an update might pose a threat after purchase

Posted Mar 3, 2026 17:54 UTC (Tue) by eharris (guest, #144549) [Link]

Did I mention "offline"? How does "the government" get at my (our) offline stuff?

There is another varient of why an update might pose a threat after purchase

Posted Mar 3, 2026 18:48 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

You'd have to be a pretty high value target for this to happen.

It depends on how easy it is to do and how easy to hide. If it's easy enough both ways, an abusive government could just do it to everyone. They might not extract any data right away, but having the capability whenever they want it without any need for additional steps before they start spying would be handy. Depending on what capabilities they have to automatically analyze the data, they might very well want to spy on everyone all the time just in case.

There is another varient of why an update might pose a threat after purchase

Posted Mar 5, 2026 17:57 UTC (Thu) by Nahor (subscriber, #51583) [Link]

> You'd have to be a pretty high value target for this to happen.

Define "high value"? Because if you have a vindictive leader *cough**cough*, pretty much anybody can become "high value" for pretty much any reason. Or if you have a corrupt police force *cough**cough*, the backdoor can be used to plant evidence on an otherwise low-value/innocent target (scapegoat), or to spy on an ex-.

And, "value" changes overtime. Read about communism in the USA before vs after the WWII and subsequent McCarthyism. Being a communist wasn't something to be ashamed of before WWII and the USSR. Then came McCarthy, the Cold War, and the communist witch hunts.

Also, "value" implies a "cost". The lower the cost, the lower the value needs to be for a target to become "valuable".

Basically, "nothing-to-hide" is a fallacy: https://en.wikipedia.org/wiki/Nothing_to_hide_argument

And for that matter, you may not be the target specifically, but your computer might (e.g. for DDoS purpose)

TLDR; YES, you're unlikely to ever become a target. But NO, you don't need to be "high value" to become one; anybody can become one, at any time, for any reason.

Things could change in the future

Posted Mar 3, 2026 17:53 UTC (Tue) by brunowolff (guest, #71160) [Link]

Right now computer manufacturers aren't that concerned about what you do with your computer, but if that changes, things could become more like it is for printers. There have already been printer updates that were marked as security fixes that were in fact used to prevent people from using third party ink for their printers. For computers, this could make sense to enforce parts pairing or similar, where it wasn't originally present.

Raptor Computing

Posted Mar 3, 2026 18:18 UTC (Tue) by linuxrocks123 (subscriber, #34648) [Link] (2 responses)

There are always these guys: https://www.raptorcs.com/

Expensive and getting outdated, but no blobs.

Raptor Computing

Posted Mar 3, 2026 18:54 UTC (Tue) by brunowolff (guest, #71160) [Link] (1 responses)

Unfortunately things have slowed there. I bought a Blackbird to support this effort and am hoping they are able to get some new products out in the future.

Bunnie Huang has also been doing some work in this space. There is betrusted (https://betrusted.io/) for having a personal device to do secure stuff on. He has also done work with nondestructive imaging to validate chips. But so far this is for much less powerful devices than typical consumer CPUs.

Raptor Computing

Posted Mar 10, 2026 13:05 UTC (Tue) by brunowolff (guest, #71160) [Link]

Bunnie posted an update describing his baochip's status.
https://www.bunniestudios.com/blog/2026/baochip-1x-a-most...

Not just security

Posted Mar 4, 2026 1:21 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> It contains bugs. These bugs are sometimes very bad. [...] code running on SSDs that made it possible to bypass encryption secrets. The SSD vendors released updates that fixed these issues.

This post focuses too much on security. What about the recent Intel (and to a lesser extent AMD) firmware updates which attempt to prevent the CPU from degrading over time? Or the firmware updates I've seen a couple of years ago from several laptop OEMs which tuned the battery charging algorithm to preserve its useful life?

Question of machine

Posted Mar 4, 2026 4:57 UTC (Wed) by mirabilos (subscriber, #84359) [Link] (10 responses)

You *could* run openssl genrsa on that Pentium Ⅰ you have somewhere in storage still, then transfer the key over.

Question of machine

Posted Mar 4, 2026 10:34 UTC (Wed) by dottedmag (subscriber, #18590) [Link] (9 responses)

I wonder if anyone can generate secure ed25519 keys without any computer. A dice might have a slight bias...

Question of machine

Posted Mar 4, 2026 12:16 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (8 responses)

There's the method to get 50/50 from an arbitrarily weighted coin[1]. Not sure if there's a feasible method for a weighted d6 though.

[1] Flip the coin twice. If the results are the same, discard the result. Otherwise, take the first flip's result.

Question of machine

Posted Mar 4, 2026 12:45 UTC (Wed) by johill (subscriber, #25196) [Link]

I think you can do a straight-forward extension of that scheme with any dN (coin being basically d2) by doing N throws in each round, rejecting rounds that aren't all different, and then taking the result of the first throw. This works for N for the same reason it works for 2.

However, the chances of rejecting end up really big, so I'd think in practice you're better of making a d2 out of the d6 (say odd/even, etc.) and retrieving one bit per round.

Question of machine

Posted Mar 4, 2026 13:40 UTC (Wed) by gspr (subscriber, #91542) [Link] (1 responses)

A non-degenerate coin (so any normal coin will do) combined with von Neumann extraction (the method you describe) will only take a few hundred flips to give you a private key suitable for x25119 like the parent asked for. Since that's a pretty rare thing for a person to generate, coin flipping will do just fine. The bigger problem is the shared secret of the symmetric crypto that follows, though – you'd be hard pressed to flip coins every time you want to set up a TLS connection, even though the key used for x25119 was securely generated in this way. There's where you might worry that your CPU is tricking you.

Question of machine

Posted Mar 4, 2026 13:41 UTC (Wed) by gspr (subscriber, #91542) [Link]

> Since that's a pretty rare thing for a person to generate, coin flipping will do just fine

I meant to say "since that's a thing a person generates pretty rarely, …".

Question of machine

Posted Mar 4, 2026 18:04 UTC (Wed) by welinder (guest, #4699) [Link] (4 responses)

Yeah, but what if the coin flip/dice rolls aren't independent? Some kind of moving internal part.

(I'll need to update my tinfoil hat too.)

Question of machine

Posted Mar 4, 2026 20:48 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

I believe you need to take that up with the folks trying to sell you their Super Secure Coin™ instead of just grabbing one off the street or from under a couch cushion.

Question of machine

Posted Mar 4, 2026 22:08 UTC (Wed) by himi (subscriber, #340) [Link] (1 responses)

Making your own dice isn't that difficult, and if you're using a method that can account for weighting (intentional or otherwise) then they don't even have to be perfect. And if you /can/ make a near-perfect die you even get to treat it as a more reliable source of randomness, meaning you don't have to discard lots of rolls in order to meet your random number quality requirements.

Question of machine

Posted Mar 5, 2026 0:08 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

A die may be a more reliable source of randomness than a coin. The gambling industry depends on dice rolls being as unpredictable as possible, so they have put a lot of effort into engineering truly random dice. They also have detailed procedures for how the dice have to be rolled, how frequently they should be replaced, etc. to ensure they stay acceptably random even when people are trying to cheat. I don't think anyone has put a comparable amount of energy into ensuring coin flips are truly random. There's a reason scientists talk about "Monte Carlo" methods; before they depended on computers for random numbers for their simulations, they used casino equipment.

Question of machine

Posted Mar 4, 2026 23:32 UTC (Wed) by brunowolff (guest, #71160) [Link]

They probbly aren't completely independent. The rolls / tosses could be affected by the orientation of the item when you pick it up. I expected trying to keep the orientation consistant would probably reduce any dependence significanty. There would still be bias, but that is already being corrected.

The last time I looked, precision dice were about $5 a die. You probably don't want casino dice unless you have a craps table or sinilar to roll them on. Precision dice have rounded corners, which is better for rolling in small areas.