3 ms·

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 sof

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.
ikiris 5y ago
Dude, this is basic overlay filesystem stuff / just look at every live image ever.

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.

ikiris 5y ago

Dude, this is basic overlay filesystem stuff / just look at every live image ever.