Hacker News Reader

Comment by soneil | Hacker News Reader

The article describes the mechanism as programmable fuses; so there is a near-certain chance these are one-time-programmable and can’t be reset. Ever.

(This is fairly normal in cpus. Picture 8 regular fuses. If you read across them, you’ll get 0xff. Now blow the first four fuses and read again. You’ll get 0xf0. Here’s the catch. You can’t “unblow” them. With real fuses, you’d replace them. If they’re inside the cpu, you replace the cpu.)

Fun trivia. The boot loader signing in the raspberry pi works the same way.

View on HN

> (This is fairly normal in cpus. Picture 8 regular fuses. If you read across them, you’ll get 0xff. Now blow the first four fuses and read again. You’ll get 0xf0. Here’s the catch. You can’t “unblow” them. With real fuses, you’d replace them. If they’re inside the cpu, you replace the cpu.)

this made me think of the pencil trick from the earliest days of socketed athlons. not exactly the same I know.

I’d never heard of the pencil trick before but it’s quite interesting: http://www.ocmelbourne.com/tutorials/PencilTrick/PencilTrick...

The XBox 360 used the same technique for patches to keep you from downgrading the system.

Same for the Nintendo Switch.

Older firmware has exploits, which allow installing Ubuntu, etc. To prevent exploiting, old firmware refuses to boot if the new firmware has ever booted. This is marked by blowing fuses.

Note - there is even a fuse that when blown, prevents other fuses from being blown!

https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-323...

Is there a downside to blowing that anti-blow fuse? Can its state be read?

It’s like an EEPROM that holds major version numbers and debug configurations. If fuse says “major version:20 allow debug: no, allow unsigned: no” and updater is for version 17->18, the user is trying to force a downgrade on a production board. Usually the updater refuses to continue and kernel do the same upon boot. Updater itself is signed and verified so checks are supposed impossible to bypass.

I believe Xbox 360 one was rewritable while Switch one is not. They also require higher voltages than rest of CPU to write. So modders used to modify PCB to block writes or tried to write old values. For Switch they had unrelated nonupdatable boot exploits to bypass signature checks for early batches.

Right, but they weren't asking about those normal fuses, they were asking about the special fuse that disables fuse-blowing.

And the simplest answer is that code could check if the fuses are reading out too early a version and abort. Which you could try to patch around but it won't be easy.

This is what distinguishes a normal iPhone from one that Apple engineers use, as well. If the fuse is blown, as it is in a production device, you can no longer control the boot chain.

Reply on news.ycombinator.com