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…
All of those machines had persistent memory in the form of cassette or floppy
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.
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…
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…
>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.
sounds horrifying can you point to any resources on a few things: (o) examples of these kinds of malware, either code or writeups (i) ways of detecting these kinds of malware (ii) ways of removing these kinds of malware (iii) ways of preventing these kinds of malware from getting installed
it looks like all of your links are basically only addressing my initial list item
the first link is about modifying a system's c compiler which the op's tails live usb is infact a solution to
the second is about altering firmware on harddrives, which is an engrossing writeup, thank you, but does fall short of suggesting ways to identify and remedy such an invasion
your third one is about intel's ME which i figured i'd see someone link to
unfortunately, the really interesting listed elements in my original post are the preventative and resolutive elements
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…
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?
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…
>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…
Not clear from your comment what definition of "stateless" you mean, but it is clear from the HN title.
The author actually has to clarify what they meant in the paper, as RAM carries state as well. > state-carrying (persistence-carrying) So what would be more accurate, I think, is "Persistence considered harmful". https://en.wikipedia.org/wiki/State_(computer_science)#Progr...
Well CPUs and GPUs carry state too; I don't think anything practical is completely stateless so it's a fair description.
It's frustrating that the author is using the word "stateless" because it usually means something different in the context of computer-related topics. Maybe the title of the paper should have been something like "A proposal for an ephemeral-storage laptop" or something along those lines.
The meaning of the title was not obvious to me either. Stateless in programming means pure functional, so the first thing I imagined from the title is some sort of new pure functional CPU. This laptop also has a state, the post-boot state is just fixed and repeatable. And, of course, the underlying technology is not different, it makes use of a lot of state, so using the word “stateless” here is certainly not the cle…
Functional is a programming language paradigm. That's too high a level to think at when you are talking CPU's and hardware.
There's no linguistic or semantic sugar on this level. Think assembly and lower. Remember, programming langyages, paradigms, and compilers are for you. Not the computer. It's all just 0's and 1's to it.
I actually would like a stateless computer. A pure functional laptop. It could store state on the cloud as a series of changesets, and each boot would be a "checkout" of the top state. Then as you compute, you make to make new changesets.
Functional has nothing to do with how a computer actually works. It's a semantic convention employed by programming languages to assist programmers by offering an alternative way to mentally model what the computer is doing. Don't conflate that.