[dead]
Linear Address Spaces: Unsafe at any speed (2022)
41–50 of 183 posts
Re: Linear Address Spaces: Unsafe at any speed (2022)
#42> 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…
[dead]
Re: Linear Address Spaces: Unsafe at any speed (2022)
#43Re: Linear Address Spaces: Unsafe at any speed (2022)
#44What a clueless post. Even ignoring their massive overstatement of the difficulty and hardware complexity of hardware mapping tables, they appear to not even understand the problems solved by mapping tables. Okay, let us say you have a physical object store. How are the actual contents of those objects stored? Are they stored in individual, isolated memory blocks? What if I want to make a 4 GB array? Do I need to hav…
> What a clueless post. Even ignoring their massive overstatement of the difficulty and hardware complexity of hardware mapping tables, they appear to not even understand the problems solved by mapping tables. From the article: > And before you tell me this is impossible: The computer is in the next room, built with 74xx-TTL (transistor-transistor logic) chips in the late 1980s. It worked back then, and it still work…
I did not say it was impossible. I said that mapping tables solve a lot of problems. There are very good reasons, as I explicitly outlined, for why they are a good solution to these classes of problems and why object stores fall down when trying to scale them up to parity with modern designs for general purpose computing.
People tried a lot of dead-ends in the past before we knew better. You need a direct analysis of the use case, problems, and solutions to actually support a point that a alternative technology is better rather just pointing at old examples.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#45> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented?
Because the attempts at segmented or object-oriented address spaces failed miserably.
> Linear virtual addresses were made to be backwards-compatible with tiny computers with linear physical addresses but without virtual memory.
That is false. In the Intel World, we first had the iAPX 432, which was an object-capability design. To say it failed miserably is overselling its success by a good margin.
The 8086 was sort-of segmented to get 20 bit addresses out of a 16 bit machine and a stop-gap and a huge success. The 80286 did things "properly" again and went all-in on the segments when going to virtual memory...and sucked. Best I remember, it was used almost exclusively as a faster 8086, with the 80286 modes used to page memory in and out and with the "reset and recover" hack to then get back to real mode for real work.
The 80386 introduced the flat address space and paged virtual memory not because of backwards-compatibility, but because it could and it was clearly The Right Thing™.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#46CHERI 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.
Interesting, what causes the speedup?
Re: Linear Address Spaces: Unsafe at any speed (2022)
#47Earlier quoted context omitted.
I mean, if the stacks grew upwards, that alone would nip 90% of buffer overflow attacks in the bud. Moving the return address from the activation frame into a separate stack would help as well, but I understand that having an activation frame to be a single piece of data (a current continuation's closure, essentially) can be quite convenient.
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…
Is there anything stopping us from doing this today on modern hardware? Why do we grow the stack down?
Re: Linear Address Spaces: Unsafe at any speed (2022)
#48So 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.
And that address is going to be contained in a linear address space (possibly with some holes).
Re: Linear Address Spaces: Unsafe at any speed (2022)
#49What a clueless post. Even ignoring their massive overstatement of the difficulty and hardware complexity of hardware mapping tables, they appear to not even understand the problems solved by mapping tables. Okay, let us say you have a physical object store. How are the actual contents of those objects stored? Are they stored in individual, isolated memory blocks? What if I want to make a 4 GB array? Do I need to hav…
> What a clueless post [...a lot of OS memory handling details...]. And there we have it.
Considering who wrote the post, I would bet the author is aware of what you've described here.
Re: Linear Address Spaces: Unsafe at any speed (2022)
#50What a clueless post. Even ignoring their massive overstatement of the difficulty and hardware complexity of hardware mapping tables, they appear to not even understand the problems solved by mapping tables. Okay, let us say you have a physical object store. How are the actual contents of those objects stored? Are they stored in individual, isolated memory blocks? What if I want to make a 4 GB array? Do I need to hav…
> What a clueless post. Even ignoring their massive overstatement of the difficulty and hardware complexity of hardware mapping tables, they appear to not even understand the problems solved by mapping tables. From the article: > And before you tell me this is impossible: The computer is in the next room, built with 74xx-TTL (transistor-transistor logic) chips in the late 1980s. It worked back then, and it still work…
A lot has changed since the 1980s. RAM access is much higher latency (in cycles), we have tons more RAM, and programs use more of it.
Maybe it is still possible but "we did it in the 80s so we can do it now" doesn't work.
Vypercore were trying to make RISC-V CPUs with object-based memory. They went out of business several months ago. I don't have the inside scoop, but I expect the biggest issue is that they were trying to sell it as a performance improvement (hardware based memory allocation), which it probably was... but also they would have been starting from a slower base anyway. "38% faster than linear memory" doesn't sound so great when your chip is half as fast as the competition to start with.
It also didn't protect objects on the stack (afaik) unlike CHERI. But on the other hand it's way simpler than CHERI conceptually, and I think it handled temporal safety more elegantly.
Personally I think Rust combined with memory tagging is going to be the sweet spot. CHERI if you really need ultra-maximum security, but I think the number of people that would pay for that is likely small.