5 ms·

A "firmware update" hardware switch is challenging to implement. A "read only" switch means you have to separate your firmware and your configuration into two s

A "firmware update" hardware switch is challenging to implement. A "read only" switch means you have to separate your firmware and your configuration into two separate storage devices. Hardware switches are easier for microphones and cameras, because you literally cut the power for a device.

Scoundreller 5y ago
Challenging, but almost always possible. Most flash chips have a write-enable line that you can put a switch on. Usually have to cut a trace but often can avoid soldering right to the legs by following traces. Was a common thing to do to receivers (“Integrated Receiver Decoders”) back in the paytv days. Thankfully they had firmware on a parallel eeprom and config stuff on a smaller serial eeprom (that could handle 1m writes instead of 1k writes). Receivers could have a lot of wires especially after they implemented some lock-detection that had to be countered with some 74ac logic that could disrupt the 2nd step of starting a write job. Should be doable for something like a router or cable modem, but maybe not on something like these WD drives. Like a mod chip without having to worry about the vendor trying to counter you. Of course you’re still screwed if something is only non-persistent but at least any issues are resolved with a simple reboot.
ComputerGuru 5y ago
> A "firmware update" hardware switch is challenging to implement. No, it’s not. The actual low-level chip on the flash has a separate pin that must be connected to ground to enable writes.
- bjt2n3904 5y ago
  I'll tell you what! You make an embedded Linux device with a read only partition based on a hardware switch. You figure out all the bugs that are caused by software not being able to write temporary files to disk. You figure out how to do configuration management on a separate system with something more complicated than a ten line YAML file. Want to change your password? That's /etc/shadow -- did you some how rig that up to be writeable, while the rest of /etc was not? Also, since I presume your management decided to not let the users have root, because of course they did... You'll need to resort to software tricks to make sure the user can't change the root password. Oh, and remember. No software read only tricks. Hardware switch. Please let me know when you finish, I'll help audit your system. Last edit: To all the reply guys, yes. I know it's possible. My statement is it isn't easy, and there are many challenges. (Especially compared with the simplicity of a power cut switch to a webcam.) I can make you a microcontroller with a firmware update switch that blinks a light. By the time you scale that up to a full fledged embedded Linux system with a board designed in house, with weird hardware that is keeping you back on Linux 3.16 because nobody knows how to port your drivers, with cryptographically signed updates, fault tolerant firmware slots, and a nasty stack of software developed by web devs that can't fathom why they can't write to disk, that has to interoperate with legacy hardware and systems, that has a management bureaucracy that can't understand why it's taking so long to implement the new media server plugin, and devices in the field aren't getting automatic updates... No. No it's not easy. Part way through, management will kill the project, you'll end up with a switch that's read in software, and eventually wind up on the front of HN as someone who did security wrong. But by all means, take your "easy" idea to WD and tell them you'll have it working on their devices by Q1 2022.
  - ComputerGuru 5y ago
    I’ve already done it, and it’s not that hard. Others have done more. It’s the best way to avoid SD card or flash write wear. My production devices default to read-only mode and must have a dip switch toggled before any changes persist beyond the shadow ram-resident overlay that resets at power cycle. (Aside: As for my idea of a configuration system, I’ve developed entire [incremental!] build systems that take a kernel source tree and configuration files and generate fully boot-ready images with drivers, packages, and even GUI support down to specifying the themes and customizing panel layouts, and more via a fully declarative syntax. The images have been booted on commodity hardware not under our control spanning some twenty-plus years of technology on more than a 100k machines. This is HN: not everyone is merely an armchair expert in whatever the topic of discussion is for today. It can be beneficial to assume expertise is out there and seek it rather than deny things are possible.)
  - philips 5y ago
    You can use an overlay filesystem to do this or do like CoreOS or ChromeOS and have a read only root with necessary symlinks to a writable directory. Systemd also has helpers for this.
  - EvanAnderson 5y ago
    I thought that was a solved problem w/ "unionfs" or such. Lots of Linux-based devices boot from read-only media.
  - NavinF 5y ago
    Have you ever used a Linux LiveCD? Or booted a machine off the network? The latter is a very common way to operate servers. In both cases you can write to the filesystem just fine. The writes just stay in RAM and don't get committed to disk. There are cons to this approach, but you've listed none that apply in the real world
    - bjt2n3904 5y ago
      I've built a BusyBox image that TFTPs over to do the initial firmware flash, all ramdisk based. I've got physically write protected ICs on my boards. I almost rigged up my board to do write once NOR flash for U-boot. I know read only systems can be built, and everything else can be tmpfs. (And infact, I've built them.) People seem to be thinking I'm saying this is impossible. I'm not, I never did. I'm sorry I'm frustrated, but it's difficult to respond to things you didn't say. I'm saying, compared to a power cut switch for a webcam (which, I seem to remember even Apple screwed up accidently), a write protect switch is more challenging. A power cut switch is mostly challenging mechanically. How do I get the dang thing on the case? But otherwise, that's the only consideration. For a truly hardware based write protect switch that disables write capabilities at the silicon level, you have to adapt your image, your software, your hardware, and many of your procedures for the bring up process. Is that challenging? For some people in this thread, I suppose not. But compared with a power cut? Orders of magnitude more challenging. Especially when you are bringing this to a massive codebase that hasn't had this as a design consideration.
- cesarb 5y ago
  Often, the same chip is used for more than just firmware. For instance, for UEFI firmware AFAIK it's common to have the UEFI variables stored on the same flash chip; not being able to write to these variables will break more than just firmware update.
  - ComputerGuru 5y ago
    Yeah, it’s a bit more nuanced in practice. Most chips now have the ability to specify ranges that are locked or unlocked which then have different requirements for what it takes to write to them, and treat the /W line differently depending on that configuration. But they’re also 20c parts, so using two chips isn’t crazy (many use multiple either as backup or for the different components anyway).
  - mananaysiempre 5y ago
    I don’t know how PC hardware does it, but microcontrollers typically have separate “flash” (large, less write cycles, requires complex rituals to write, executable) for programs and “EEPROM” (small, more write cycles, requires little if any preparation to write, often non-executable) for configuration and (very lightweight) logging. Prohibiting writes to the former but not the latter shouldn’t be particularly difficult, although I’ve yet to see a chip that would actually do it.
    - ComputerGuru 5y ago
      This is actually why bios chips fail so often in personal computers.
      - jmrm 5y ago
        Is this true? I have repaired a lot of computers since I were young and non of them had hardware BIOS related problems.
        ComputerGuru 5y ago
        I’ve had three laptops fail in the last five years due to a flash rom chip getting corrupted after saving changes in the BIOS one time too many. Enterprise warranty covered an HP and a Dell service rep to come on site and swap out the motherboard+cpu+gpu combo twice, I swapped out the rom myself the third time. I’ve also had to do it on a desktop Gigabyte motherboard circa 2009 after a successful BIOS update left the flash rom unstable.
edoceo 5y ago
Challenging? I think you mean fun.
LeifCarrotson 5y ago
The firmware and configuration are already split into several devices. These machines have Arm Cortex A9 and similar processors that go through several stages to start up: First, some internal boot ROM, likely with fuses burned in for the particular IO configuration, reads a bootloader (likely Das U-boot) from external flash memory. That first-stage bootloader initializes the parallel/SPI NAND/NOR flash interface and DRAM controllers, and then launches the second-stage bootloader. The second-stage bootloader uses those memory controllers to read the firmware image out of memory into RAM, then executes it. If you want to update the firmware - more precisely, to change the location or signature of the image that should be loaded by the second-stage bootloader - it would be trivial to add a check for a GPIO switch to allow or deny changes.

Scoundreller 5y ago

Challenging, but almost always possible. Most flash chips have a write-enable line that you can put a switch on. Usually have to cut a trace but often can avoid soldering right to the legs by following traces. Was a common thing to do to receivers (“Integrated Receiver Decoders”) back in the paytv days. Thankfully they had firmware on a parallel eeprom and config stuff on a smaller serial eeprom (that could handle 1m writes instead of 1k writes). Receivers could have a lot of wires especially after they implemented some lock-detection that had to be countered with some 74ac logic that could disrupt the 2nd step of starting a write job. Should be doable for something like a router or cable modem, but maybe not on something like these WD drives. Like a mod chip without having to worry about the vendor trying to counter you. Of course you’re still screwed if something is only non-persistent but at least any issues are resolved with a simple reboot.

ComputerGuru 5y ago

> A "firmware update" hardware switch is challenging to implement. No, it’s not. The actual low-level chip on the flash has a separate pin that must be connected to ground to enable writes.

bjt2n3904 5y ago
I'll tell you what! You make an embedded Linux device with a read only partition based on a hardware switch. You figure out all the bugs that are caused by software not being able to write temporary files to disk. You figure out how to do configuration management on a separate system with something more complicated than a ten line YAML file. Want to change your password? That's /etc/shadow -- did you some how rig that up to be writeable, while the rest of /etc was not? Also, since I presume your management decided to not let the users have root, because of course they did... You'll need to resort to software tricks to make sure the user can't change the root password. Oh, and remember. No software read only tricks. Hardware switch. Please let me know when you finish, I'll help audit your system. Last edit: To all the reply guys, yes. I know it's possible. My statement is it isn't easy, and there are many challenges. (Especially compared with the simplicity of a power cut switch to a webcam.) I can make you a microcontroller with a firmware update switch that blinks a light. By the time you scale that up to a full fledged embedded Linux system with a board designed in house, with weird hardware that is keeping you back on Linux 3.16 because nobody knows how to port your drivers, with cryptographically signed updates, fault tolerant firmware slots, and a nasty stack of software developed by web devs that can't fathom why they can't write to disk, that has to interoperate with legacy hardware and systems, that has a management bureaucracy that can't understand why it's taking so long to implement the new media server plugin, and devices in the field aren't getting automatic updates... No. No it's not easy. Part way through, management will kill the project, you'll end up with a switch that's read in software, and eventually wind up on the front of HN as someone who did security wrong. But by all means, take your "easy" idea to WD and tell them you'll have it working on their devices by Q1 2022.
- ComputerGuru 5y ago
  I’ve already done it, and it’s not that hard. Others have done more. It’s the best way to avoid SD card or flash write wear. My production devices default to read-only mode and must have a dip switch toggled before any changes persist beyond the shadow ram-resident overlay that resets at power cycle. (Aside: As for my idea of a configuration system, I’ve developed entire [incremental!] build systems that take a kernel source tree and configuration files and generate fully boot-ready images with drivers, packages, and even GUI support down to specifying the themes and customizing panel layouts, and more via a fully declarative syntax. The images have been booted on commodity hardware not under our control spanning some twenty-plus years of technology on more than a 100k machines. This is HN: not everyone is merely an armchair expert in whatever the topic of discussion is for today. It can be beneficial to assume expertise is out there and seek it rather than deny things are possible.)
- philips 5y ago
  You can use an overlay filesystem to do this or do like CoreOS or ChromeOS and have a read only root with necessary symlinks to a writable directory. Systemd also has helpers for this.
- EvanAnderson 5y ago
  I thought that was a solved problem w/ "unionfs" or such. Lots of Linux-based devices boot from read-only media.
- NavinF 5y ago
  Have you ever used a Linux LiveCD? Or booted a machine off the network? The latter is a very common way to operate servers. In both cases you can write to the filesystem just fine. The writes just stay in RAM and don't get committed to disk. There are cons to this approach, but you've listed none that apply in the real world
  - bjt2n3904 5y ago
    I've built a BusyBox image that TFTPs over to do the initial firmware flash, all ramdisk based. I've got physically write protected ICs on my boards. I almost rigged up my board to do write once NOR flash for U-boot. I know read only systems can be built, and everything else can be tmpfs. (And infact, I've built them.) People seem to be thinking I'm saying this is impossible. I'm not, I never did. I'm sorry I'm frustrated, but it's difficult to respond to things you didn't say. I'm saying, compared to a power cut switch for a webcam (which, I seem to remember even Apple screwed up accidently), a write protect switch is more challenging. A power cut switch is mostly challenging mechanically. How do I get the dang thing on the case? But otherwise, that's the only consideration. For a truly hardware based write protect switch that disables write capabilities at the silicon level, you have to adapt your image, your software, your hardware, and many of your procedures for the bring up process. Is that challenging? For some people in this thread, I suppose not. But compared with a power cut? Orders of magnitude more challenging. Especially when you are bringing this to a massive codebase that hasn't had this as a design consideration.
cesarb 5y ago
Often, the same chip is used for more than just firmware. For instance, for UEFI firmware AFAIK it's common to have the UEFI variables stored on the same flash chip; not being able to write to these variables will break more than just firmware update.
- ComputerGuru 5y ago
  Yeah, it’s a bit more nuanced in practice. Most chips now have the ability to specify ranges that are locked or unlocked which then have different requirements for what it takes to write to them, and treat the /W line differently depending on that configuration. But they’re also 20c parts, so using two chips isn’t crazy (many use multiple either as backup or for the different components anyway).
- mananaysiempre 5y ago
  I don’t know how PC hardware does it, but microcontrollers typically have separate “flash” (large, less write cycles, requires complex rituals to write, executable) for programs and “EEPROM” (small, more write cycles, requires little if any preparation to write, often non-executable) for configuration and (very lightweight) logging. Prohibiting writes to the former but not the latter shouldn’t be particularly difficult, although I’ve yet to see a chip that would actually do it.
  - ComputerGuru 5y ago
    This is actually why bios chips fail so often in personal computers.
    - jmrm 5y ago
      Is this true? I have repaired a lot of computers since I were young and non of them had hardware BIOS related problems.
      - ComputerGuru 5y ago
        I’ve had three laptops fail in the last five years due to a flash rom chip getting corrupted after saving changes in the BIOS one time too many. Enterprise warranty covered an HP and a Dell service rep to come on site and swap out the motherboard+cpu+gpu combo twice, I swapped out the rom myself the third time. I’ve also had to do it on a desktop Gigabyte motherboard circa 2009 after a successful BIOS update left the flash rom unstable.

edoceo 5y ago

Challenging? I think you mean fun.

LeifCarrotson 5y ago

The firmware and configuration are already split into several devices. These machines have Arm Cortex A9 and similar processors that go through several stages to start up: First, some internal boot ROM, likely with fuses burned in for the particular IO configuration, reads a bootloader (likely Das U-boot) from external flash memory. That first-stage bootloader initializes the parallel/SPI NAND/NOR flash interface and DRAM controllers, and then launches the second-stage bootloader. The second-stage bootloader uses those memory controllers to read the firmware image out of memory into RAM, then executes it. If you want to update the firmware - more precisely, to change the location or signature of the image that should be loaded by the second-stage bootloader - it would be trivial to add a check for a GPIO switch to allow or deny changes.