Can this be fixed by removing the efuse or having a custom firmware?
By the way, AMD also uses fuse blowing if you e.g. overclock some of their CPUs to mark them as warranty voided. They give you a warning in the BIOS and if you resume a fuse inside the CPU gets blown that will permanently indicate that the CPU has been used for overclocking (and thus remove the warranty)
Bullshit. There will be hackers in the future who can do it in their garage. Just... not anytime soon.
> By the way, AMD also uses fuse blowing if you e.g. overclock some of their CPUs to mark them as warranty voided. They give you a warning in the BIOS and if you resume a fuse inside the CPU gets blown that will permanently indicate that the CPU has been used for overclocking (and thus remove the warranty)
Emphasis on "some." You can buy plenty of CPUs from them made for overclocking.
I'll take your bet on this. Silicon designers aren't unaware of this potential vulnerability, and if you want to prevent eFuses from being un-blown, you can design for that. I would place money on there not being any commercially viable way to restore an eFuse in a 4090 die at any point in the future. You can probably do it, but it would require millions of dollars in FIB and SEM equipment and likely would destroy the chip for any useful purpose.
Usually the only useful reason to attempt to recover/read/unblown fuses is to read out private keys built into chips.
The price tag and size of these things are what I'm talking about. SOME day it will get much cheaper and smaller. A 4090 will be useless at that point, but I still play with 8086s and vacuum tubes, so...
No point in betting though. We'll both be dead by then.
There's been a few different stories like this lately:
https://interestingengineering.com/videos/guy-builds-integra...
People said the same thing you're saying now about computers. You're just being silly and forgetting history.
You’re trivializing the challenge of modifying something that is on the order of 50nm wide and specifically designed to not be able to be tampered with.
I wouldn't dismiss this so aggressively.
Frequently (more frequently than not), efuses are simply used as configuration fields checked by firmware. If that firmware can be modified, the value of the efuse can be ignored. It's substantially easier to implement a fused feature as a bit in a big bitfield of "chicken bits" in one-time programmable memory than to try to physically fuse off an entire power or clock domain, which would border on physically irreversible (this is done sometimes, but only where strictly necessary and not often).
Granted, it's Nvidia, and they've been featured in devices that were notoriously hackable, but also, it's not 2018 anymore.
Needless to say, people should understand when they buy an Nvidia card, they should fully expect to use Nvidia firmware, with whatever that entails.
EDIT: I'd really like to remember the name of this device. It was the same era as Blackberry releasing... the Storm? Some resistitive-touch device with a physically clickable screen. Motorola Storm? I really wish I could recall. (sub-edit: I think the Storm was the Blackberry device. So something else...)
I think there might have been one or two OMX devices in this era with locked bootloaders that weren't bypassed due to a lack of research, but I actually find this example a bit amusing: early Qualcomm Motorola Android phones were touted as "unhackable" due to their use of fuses (Qualcomm even went on a marketing pitch calling them "Q-Fuses"), but were extremely quickly unlocked using trivial TrustZone supervisor vulnerabilities (iirc, there was an SMC that literally had a write-what-where primitive in it).
Professionally I usually see OTP referred to as "fuses," "OTP," "straps," or "chicken bits," with the specific word "eFuse" reserved for the current-limiting device. But in popular media the trend seems the opposite.