Item — HN Reader

Hi. A lot of interesting and intelligent comments, but I think that on the whole, we've over-complicated the issue.

To explain what I mean, consider a Commodore 64, Apple IIe, or Atari 800, Ti99 4a, or Radio Shack Color Computer, or most home computers from the early 1980's.

None of these computers, NONE OF THEM, had any form of persistent memory (Flash, EEPROM, battery-backed CMOS, CPU persistent memory, etc.) such that when you unplugged the computer and plugged it back in, something, even so much as a single bit was changed.

In other words, you unplug, and you start over with the exact same initial STATE as you did the first day when you unpacked the box.

That is, software, legitimate or malware, CANNOT change the initial power-up state of the computer. CANNOT.

That is STATELESS HARDWARE.

Note that I did not include x86 PC's in my list, because they typically have battery backed up CMOS, and onboard FLASH in newer models. Those things (and places for writeable Firmware) STORE STATE, thus they change the INITIAL power-up state of the computer.

Once a computer can store state between power offs, then you could be dealing with a different machine than you were when it first came out of the box.

When that happens, now you need all kinds of crazy security asserts that whatever is in there is safe. As opposed to simply powering off, and starting fresh, knowing that you are.

2 comments

None of those 80's computers had power-on networks either, which is the most interesting part of the proposal, IMO. Persistent storage isn't the only way to affect the initial power-on state of today's computers.

It would also help to call this whole idea "fixed boot state" or something similar, since "stateless" is misleading even to developers, and not super accurate, which may be part of the reason you're sensing complication.

It is fun to consider how to guarantee that a computer has a fixed boot state. Not all that difficult if you can break down all the components.

The more interesting question to me is whether that truly improves security, once you start working on networks, and whether it could be made usable for the general population, rather than so inconvenient that nobody can adopt it. Is it only something the most extreme high security secret lab air-gapped environment will ever tolerate?

>The more interesting question to me is whether that truly improves security, once you start working on networks, and whether it could be made usable for the general population, rather than so inconvenient that nobody can adopt it. Is it only something the most extreme high security secret lab air-gapped environment will ever tolerate?

Networking a machine that cannot get security updates sounds like a bad idea. It's pristine boot state is bound to get infected seconds after going online.

Exactly!

All of those machines had persistent memory in the form of cassette or floppy

That is correct. Storage by definition is persistent memory. But, BUT, the storage is in a format which is easily auditable to the end-user or virus-checker program. You can reformat/reinstall and start over. Show me how that's possible with undocumented storage (e.g., EEPROM, CMOS, FLASH, microcode updates, on-CPU storage, etc.) Once you've got undocumented persistent writable memory holes, neither end-user nor virus-checker can audit them. You're basically at the mercy of the code written by the vendor, or whoever figures out how to shove unwanted stuff there. Also, you can write protect your cassettes and floppies, and be fairly certain that your wishes will be respected. Can you do that with undocumented persistent memory locations in your Chipset/Motherboard/CPU/PC? Do you even KNOW about undocumented persistent memory locations in your Chipset/Motherboard/CPU/PC? And... are you sure? How sure? You see how far the rabbit hole goes?

That's basically what is proposed in this paper except with a USB stick or SD card instead.

Other than the Apple IIe floppy (I think, it has been a bit), cassette or floppy did not boot with the machine and had to be loaded.