By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), July 29, 2022 11:20 am
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on July 29, 2022 10:43 am wrote:
>
> And in addition to this you have stuff where an individual server loses power because a power supply fails
> (and yes that happens with N+1 supplies, I've seen that many times) or because the system crashes.
Side note: "the system crashes" is a real issue, and having IO that just works as memory can be really really scary in that situation.
Bugs happen. You have wild pointers. You don't want a random wild pointer access to trash your data on disk by mistake.
Sometimes it's an advantage to have an IO path that requires a bit of setup. Think of it not as a security thing, but as a "protect against accidents" thing. Disk corruption can still happen (due to both hardware and software problems), but it's still a barrier.
And yes, people did special "you can write protect this region of memory and have to use a special mapping when you actually write to it", but that kind of shows how in many situations you really want memory to memory, and disk to be disk. The two are not the same.
That, btw, is true of any non-volatile memory situation in general.
You simply don't want a situation where all your memory is your long-term image. The whole "if you lose power, you reboot and just continue" thing is mindless blathering. Exactly because it makes a fundamental mistake in assuming that everything is always perfect and bug-free.
In many situations, you not only want most of your memory to be "scratch RAM", you absolutely require it. Security and tampering is one reason for it.
So even if we ever end up in a situation where your CPU caches are simply huge, and all "memory" outside the caches is nonvolatile and could be used as a long-term disk, you would absolutely require some of it to be encrypted with a one-time key so that you can literally treat it as being ephemeral, and know that when you power the machine down (intentionally or unintentionally), you're not leaving random stuff around.
Non-volatility tends to be sold as this unquestionably good feature. But as pretty much everything in engineering, there's another side to it.
Linus
>
> And in addition to this you have stuff where an individual server loses power because a power supply fails
> (and yes that happens with N+1 supplies, I've seen that many times) or because the system crashes.
Side note: "the system crashes" is a real issue, and having IO that just works as memory can be really really scary in that situation.
Bugs happen. You have wild pointers. You don't want a random wild pointer access to trash your data on disk by mistake.
Sometimes it's an advantage to have an IO path that requires a bit of setup. Think of it not as a security thing, but as a "protect against accidents" thing. Disk corruption can still happen (due to both hardware and software problems), but it's still a barrier.
And yes, people did special "you can write protect this region of memory and have to use a special mapping when you actually write to it", but that kind of shows how in many situations you really want memory to memory, and disk to be disk. The two are not the same.
That, btw, is true of any non-volatile memory situation in general.
You simply don't want a situation where all your memory is your long-term image. The whole "if you lose power, you reboot and just continue" thing is mindless blathering. Exactly because it makes a fundamental mistake in assuming that everything is always perfect and bug-free.
In many situations, you not only want most of your memory to be "scratch RAM", you absolutely require it. Security and tampering is one reason for it.
So even if we ever end up in a situation where your CPU caches are simply huge, and all "memory" outside the caches is nonvolatile and could be used as a long-term disk, you would absolutely require some of it to be encrypted with a one-time key so that you can literally treat it as being ephemeral, and know that when you power the machine down (intentionally or unintentionally), you're not leaving random stuff around.
Non-volatility tends to be sold as this unquestionably good feature. But as pretty much everything in engineering, there's another side to it.
Linus
Topic | Posted By | Date |
---|---|---|
RIP Optane/XPoint | Wes Felter | 2022/07/28 07:53 PM |
RIP Optane/XPoint | Rayla | 2022/07/28 08:28 PM |
RIP Optane/XPoint | Doug S | 2022/07/28 09:00 PM |
RIP Optane/XPoint | NoSpammer | 2022/07/29 01:50 AM |
NVDIMM-N | Eric L | 2022/07/29 03:36 AM |
RIP Optane/XPoint | Michael S | 2022/07/29 04:02 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:40 AM |
RIP Optane/XPoint | Doug S | 2022/07/29 10:43 AM |
RIP Optane/XPoint | Linus Torvalds | 2022/07/29 11:20 AM |
RIP Optane/XPoint | David Hess | 2022/07/29 08:59 PM |
RIP Optane/XPoint | David Hess | 2022/07/30 03:44 PM |
RIP Optane/XPoint | Doug S | 2022/07/30 10:43 PM |
RIP Optane/XPoint | rwessel | 2022/07/31 05:33 AM |
RIP Optane/XPoint | Konrad Schwarz | 2022/08/02 08:06 AM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:24 PM |
RIP Optane/XPoint | David Hess | 2022/08/02 10:26 PM |
RIP Optane/XPoint | Adrian | 2022/08/03 01:19 AM |
RIP Optane/XPoint | anonymou5 | 2022/07/29 12:50 PM |
RIP Optane/XPoint | Gionatan Danti | 2022/07/29 09:09 AM |
RIP Optane/XPoint | Mark Roulo | 2022/07/29 10:02 AM |
RIP Optane/XPoint | dmcq | 2022/07/30 03:42 AM |
RIP Optane/XPoint | anon3 | 2022/07/31 10:19 PM |
RIP Optane/XPoint | anon2 | 2022/07/31 10:55 PM |
RIP Optane/XPoint | Doug S | 2022/08/01 08:37 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 01:33 PM |
RIP Optane/XPoint | NoSpammer | 2022/08/02 03:50 AM |
RIP Optane/XPoint | Doug S | 2022/08/02 09:24 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/02 10:34 AM |
RIP Optane/XPoint | --- | 2022/08/02 10:39 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 03:48 AM |
RIP Optane/XPoint | Michael S | 2022/08/03 06:04 AM |
RIP Optane/XPoint | David Hess | 2022/08/03 08:56 AM |
RIP Optane/XPoint | Adrian | 2022/08/01 02:15 AM |
RIP Optane/XPoint | Gionatan Danti | 2022/08/01 06:07 AM |
Losses vs not profitable enough | Mark Roulo | 2022/08/01 10:15 AM |
Losses vs not profitable enough | dmcq | 2022/08/01 11:50 AM |
Losses vs not profitable enough | Gionatan Danti | 2022/08/01 12:34 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 02:47 PM |
RIP Optane/XPoint | Anon | 2022/08/01 03:09 PM |
RIP Optane/XPoint | Michael S | 2022/08/01 03:32 PM |
RIP Optane/XPoint | Groo | 2022/08/01 12:28 PM |
RIP Optane/XPoint | anon3 | 2022/08/01 10:33 PM |
RIP Optane/XPoint | Groo | 2022/08/03 11:15 AM |
RIP Optane/XPoint | --- | 2022/08/03 03:05 PM |
Latency | David Kanter | 2022/07/29 06:35 PM |
Operating system and driver overhead | Eric L | 2022/07/29 03:44 AM |
Operating system and driver overhead | Linus Torvalds | 2022/07/29 10:45 AM |
altrernatives? | Michael S | 2022/07/29 05:17 AM |
altrernatives? | Rayla | 2022/07/29 06:49 AM |