Let's also abandon disk storage's linear block addressing and go back to CHS addressing
Linear Address Spaces: Unsafe at any speed (2022)
161–170 of 183 posts
Re: Linear Address Spaces: Unsafe at any speed (2022)
#162Author here. This is one of those things, where 99.999% of all IT people have never even heard or imagined that things can be different than "how we have always done it." (Obligatory Douglas Adams quote goes here.) This makes a certain kind of people, self-secure in their own knowledge, burst out words like "clueless", "fail miserably" etc. based on insufficient depth of actual knowledge. To them I can only say: Stud…
What a impressively arrogant double-down.
You once again present no technical argument for your extraordinary claims and position, let alone the extraordinary evidence required. You present no technical analysis of known problems or limitations with historical or conceptual designs. You present no solutions, workarounds, or even argue those problems are no longer relevant.
You fail to even fallaciously argue that past success indicates future success. You jump straight to past failure indicates future success.
You just assert, without evidence, that old, flawed, failed, outcompeted technology is the future and anybody who uses facts and evidence to disagree is a arrogant, ignorant inferior to your staggering intellect. Bravo.
Word to the wise, if you let off on the self-aggrandizing arrogance and had a little epistemological humility when proposing we should revisit old ideas instead of implying people who disagree are troglodytes then you would not come across as clueless.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#163Earlier quoted context omitted.
The PL/I stack growing up rather than down reduced potential impact of stack overflows in Multics (and PL/I already had better memory safety, with bounded strings, etc.) TFA's author would probably have appreciated the segmented memory architecture as well. There is no reason why the C/C++ stack can't grow up rather than down. On paged hardware, both the stack and heap could (and probably should) grow up. "C's stack…
> There is no reason why the C/C++ stack can't grow up rather than down. Historical accident. Imagine if PDP-7/PDP-11 easily allowed for the following memory layout: FFFF +---------------+ | text | X +---------------+ | rodata | R +---------------+ | data + bss | RW +---------------+ | heap | | || | RW | \/ | +---------------+ | empty space | unmapped +---------------+ | /\ | | || | RW | stack | 0000 +---------------…
Nice diagram. I might put read-only pages on both sides of 0 though to mitigate null pointer effects.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#164CHERI is undeniably on the rise. Adapting existing code generally only requires rewriting less than 1% of the codebase. It offers speedups for existing as well as new languages (designed with the hardware in mind). I expect to see it everywhere in about a decade.
There's a big 0->1 jump required for it to actually be used by 99% of consumers -- x86 and ARM have to both make a pretty fundamental shift. Do you see that happening? I don't, really.
I see this happening on ARM world, that is why ARM is working alongside CHERI folks,
https://www.arm.com/architecture/cpu/morello
x86, well Intel has already messed up hardware memory tagging multiple times.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#165Earlier quoted context omitted.
But that wouldn't protect against out-of boundary access (which is the whole point of segments), would it?
thats enforced by the VM hardware - we just shuffle the PTEs around to match the appropriate segment view
As long as it's a linear address space, adding/subtracting a large enough value to a pointer (array, stack) could still cross into another "segment".
Re: Linear Address Spaces: Unsafe at any speed (2022)
#166Earlier quoted context omitted.
> The fence principle always applies “don’t tear down a fence till you understand why it was built” Don't rename Chesterton's Fence until you understand why it was named that.
Was not aware the fence had a name. Learned it in Russian without the name. TIL, thank you.
Well, it is possible Chesterton got it from an earlier source that the Russian version also derives from! Who knows?
Re: Linear Address Spaces: Unsafe at any speed (2022)
#167Earlier quoted context omitted.
Or you run everything with a compacting GC.
Well, unless you are ok with excluding software written in many common programming languages from your platform, that's not really an option. It may be ok for embedded systems, but those recently have been evolving on the opposite direction.
Sure, but we're talking about a hypothetical architecture without memory mappings but with pages and permissions. Software compatibility was already tossed in the trash can at that point.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#168Earlier quoted context omitted.
This feels like a pointless form of pendantry. Okay, so we went from linear address spaces to partioned/disaggregated linear address spaces. This is hardly the victory you claim it is, because page sizes are increasing and thus the minimum addressable block of memory keeps increasing. Within a page everything is linear as usual. The reason why linear address spaces are everywhere has to do with the fact that they are…
We have a linear address space where we can map physical RAM and memory-mapped devices dynamically. Every core, at any given time, may have its own view of it. The current approach uses pretty coarse granularity, separating execution at the process level. The separation could be more granular. The problem is the granularity of trust within the system. Were the MMU much faster, and TLB much larger (say, 128MiB of dedi…
It has very little to do with trust and a lot to do with the realities of hardware implementation. Every interconnect has a minimum linear transfer granularity that properly utilizes its hardware links, dictated primarily by its physical link width and minimum efficient burst length. The larger this minimum granularity, the faster and more efficient moving data becomes. However, below this granularity, bandwidth and energy efficiency crater. Hence, reducing access granularity below this limit has disastrous consequences.
In fact, virtual memory is already a limiting factor to increasing minimum transfer size, as pages must be an efficient unit of exchange. Traditional 4 KiB pages are already smaller than what would be a good minimum transfer size; this is exactly why hardware designers push for larger pages (with Apple silicon forgoing 4 KiB page support entirely).
I cannot help but feel that many of these discussions are led astray by the misconceptions of people with an insufficient understanding of modern computer architecture.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#169Earlier quoted context omitted.
thats enforced by the VM hardware - we just shuffle the PTEs around to match the appropriate segment view
As long as it's a linear address space, adding/subtracting a large enough value to a pointer (array, stack) could still cross into another "segment".
but those wouldn't be mapped unless you have crossed a call gate that enabled them. the kernel call gate implementation changes the VM map (region visibility) accordingly
Re: Linear Address Spaces: Unsafe at any speed (2022)
#170> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented? What a weird question, conflating one thing with the other. I’m working on a object capability system, and trying hard to see if I can make it work using a linear address space so I don’t have to waste two or three pages per “process” [1][2] I really don’t see how objects have anything…
Have you looked at the Apple Newton memory architecture? http://waltersmith.us/newton/HICSS-92.pdf
Thanks, will do