> How would you have designed this feature Make fuses eraseable. But only upon asserting some hardware key. So one with physical access can force-erase fuses, BUT only if hardware key toggled.
On hardware level implementation can be like this: fuses are often just some FLASH- or EEPROM-like memory, which just lacks ERASE procedure, so once WRITE occured, you can't write new values again, because to do it flash have to be erased and there is no ERASE. Sometimes OTP memory can be programmed more than once, if bits only change in WRITE direction, but not in reverse ERASE direction. Yet, hardware can be designed in way it prevents further partial WRITEs if desired.
My idea is: ERASE can be here. Flash/EEPROM/etc memory requires "high voltage" to erase or program data (internally generated, but power supply input pin can be separate). This could be put on separate pin. Button press would energize this pin. In this case, witout button press you can't neither program, nor re-program FUSES. At manufacture you have to assert Vpp to write fuse. At re-program you have to do the same. And hardware itself should be unable to do it under program control. Only pysical button press should activate it. If Vpp voltage is physically missing, erase or write just not going to work for purely physical reassons. So even if software executes erase/write sequences, it just not going to work due to lack of programming voltage. Write fails and there is nothing software can do about it.
I can also admit Google's approach: they have read-only SPI ROM with "base" code, and then code here can be configured to allow or disallow unsigned boot, subject to some procedures. Software can't overwrite SPI ROM: its #WP pin is tied to ground, so it happens to be READONLY. And if one really wants to reflash this part, SPI prommer can replace SPI readonly "base". Then you'll have new readonly base running YOUR code. Replacing it in software would not work. And it's actualy most reliable way to have trusted code base: if trusted code base is readonly, nobody can change it. And requirement of physical action ensures this action can't happen in unnoticeable manner most of time. OTOH we do not know if OEM or Intel or whoever has shared their private key and can't check this.
Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
On FUSES, READONLY and how to design this feature in REPLACEABLE ways.
Date: 2015-12-13 03:08 pm (UTC)Make fuses eraseable. But only upon asserting some hardware key. So one with physical access can force-erase fuses, BUT only if hardware key toggled.
On hardware level implementation can be like this: fuses are often just some FLASH- or EEPROM-like memory, which just lacks ERASE procedure, so once WRITE occured, you can't write new values again, because to do it flash have to be erased and there is no ERASE. Sometimes OTP memory can be programmed more than once, if bits only change in WRITE direction, but not in reverse ERASE direction. Yet, hardware can be designed in way it prevents further partial WRITEs if desired.
My idea is: ERASE can be here. Flash/EEPROM/etc memory requires "high voltage" to erase or program data (internally generated, but power supply input pin can be separate). This could be put on separate pin. Button press would energize this pin. In this case, witout button press you can't neither program, nor re-program FUSES. At manufacture you have to assert Vpp to write fuse. At re-program you have to do the same. And hardware itself should be unable to do it under program control. Only pysical button press should activate it. If Vpp voltage is physically missing, erase or write just not going to work for purely physical reassons. So even if software executes erase/write sequences, it just not going to work due to lack of programming voltage. Write fails and there is nothing software can do about it.
I can also admit Google's approach: they have read-only SPI ROM with "base" code, and then code here can be configured to allow or disallow unsigned boot, subject to some procedures. Software can't overwrite SPI ROM: its #WP pin is tied to ground, so it happens to be READONLY. And if one really wants to reflash this part, SPI prommer can replace SPI readonly "base". Then you'll have new readonly base running YOUR code. Replacing it in software would not work. And it's actualy most reliable way to have trusted code base: if trusted code base is readonly, nobody can change it. And requirement of physical action ensures this action can't happen in unnoticeable manner most of time. OTOH we do not know if OEM or Intel or whoever has shared their private key and can't check this.