Linear Address Spaces: Unsafe at any speed (2022)
queue.acm.org
Linear Address Spaces: Unsafe at any speed (2022)
1–10 of 183 posts
Re: Linear Address Spaces: Unsafe at any speed (2022)
#2> Show me somebody who calls the IBM S/360 a RISC design, and I will show you somebody who works with the s390 instruction set today.
Ahaha so true.
But to answer the post's main question:
> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented?
Because backwards compatibility is more valuable than elegant designs. Because array-crunching performance is more important than safety. Because a fix for a V8 vulnerability can be quickly deployed while a hardware vulnerability fix cannot. Because you can express any object model on top of flat memory, but expressing one object model (or flat memory) in terms of another object model usually costs a lot. Because nobody ever agreed of what the object model should be. But most importantly: because "memory safety" is not worth the costs.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#3I think you could argue there is already some effort to do type safety at the ISA register level, with e.g. shadow stack or control flow integrity. Isn't that very similar to this, except targeting program state rather than external memory?
Re: Linear Address Spaces: Unsafe at any speed (2022)
#4> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented?
But what happens when the in-memory size of objects approaches 2⁶⁴? How to even map such a thing without multi-level page tables?
Re: Linear Address Spaces: Unsafe at any speed (2022)
#5How does object store hardware work? Doesnt it still require a cache?
Any papers on modern object store archiectures (is that the right terminology?)
Re: Linear Address Spaces: Unsafe at any speed (2022)
#6So how do you hook up such a system to actual RAM or EPROMs to allow it to function? Somewhere there has to be an actual address generated.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#7> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? But what happens when the in-memory size of objects approaches 2⁶⁴? How to even map such a thing without multi-level page tables?
Regions, like [0], for example? Multi-level page tables kinda suck.
[0] https://web.archive.org/web/20250321211345/https://www.secur...
Re: Linear Address Spaces: Unsafe at any speed (2022)
#8> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? But what happens when the in-memory size of objects approaches 2⁶⁴? How to even map such a thing without multi-level page tables?
What field do you work in that you’re mapping objects of size 2^{63}? Databases? When I see anything that size it’s a bug.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#9> Show me somebody who calls the IBM S/360 a RISC design, and I will show you somebody who works with the s390 instruction set today. Ahaha so true. But to answer the post's main question: > Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? Because backwards compatibility is more valuable than elegant designs. Because array-crunching pe…
But we don't have a linear address space, unless you're working with a tiny MCU. For last like 30 years we have virtual address space on every mainstream processor, and we can mix and match pages the way we want, insulate processes from one another, add sentinel pages at the ends of large structures to generate a fault, etc. We just structure process heaps as linear memory, but this is not a hard requirement, even on current hardware.
What we lack is the granularity that something like iAPX432 envisioned. Maybe some hardware breakthrough would allow for such granularity cheaply enough (like it allowed for signed pointers, for instance), so that smart compilers and OSes would offer even more protection without the expense of switching to kernel mode too often. I wonder what research exists in this field.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#10An open secret in our field is: the current market leading OSes and (to some extent) system architectures are antiquated and sub-optimal at their foundation due to backward compatibility requirements.
If we started green field today and managed to mitigate second system syndrome, we could design something faster, safer, overall simpler, and easier to program.
Every decent engineer and CS person knows this. But it’s unlikely for two reasons.
One is that doing it while avoiding second system syndrome takes teams with a huge amount of both expertise and discipline. That includes the discipline to be ruthless about exterminating complexity and saying no. That’s institutionally hard.
The second is that there isn’t strong demand. What we have is good enough for what most of the market wants, and right now all the demand for new architecture work is in the GPU/NPU/TPU space for AI. Nobody is interested in messing with the foundation when all the action is there. The CPU in that world is just a job manager for the AI tensor math machine.
Quantum computing will be similar. QC will be controlled by conventional machines, making the latter boring.
We may be past the window where rethinking architectural choices is possible. If you told me we still had Unix in 2000 years I would consider it plausible.