Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linear Address Spaces: Unsafe at any speed (2022)

queue.acm.org

Post reply on HN
Print view View original

61–70 of 183 posts

Re: Linear Address Spaces: Unsafe at any speed (2022)

#61

Post by themafia »

> Why do we even have linear physical and virtual addresses in the first place, when pretty much everything today is object-oriented?

Maybe it's because even though x86-64 is a 64-bit instruction set, all the CALL and JMP instructions still only support relative 8-bit or 32-bit offsets.

> Translating from linear virtual addresses to linear physical addresses is slow and complicated, because 64-bit can address a lot of memory.

Sure but spend some time thinking about how GOT and PLT aren't great solutions and can easily introduce their own set of security complications due to the above limitations.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#62

Post by Veserv »

codedokode wrote: post #60

What about an architecture, where there are pages and access permissions, but no translation (virtual address is always equal to physical)? fork() would become impossible, but Windows is fine without it anyway.

You are describing a memory protection unit (MPU). Those are common in low-resource contexts that are too simple to afford a full memory management unit (MMU). The problem with scaling that up, especially in general-purpose environments with dynamic process creation, is fragmentation of the shared address space.

You need a contiguous chunk for whatever object you are allocating. Other allocations fragment the address space, so there might be adequate space in total, but no individual contiguous chunk is large enough. You need to move around the backing storage, but then that makes your linear addresses non-stable. You solve that by adding a indirection layer mapping your "address", which is really a key/ID, to the backing storage. At that point you are basically back to a MMU.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#63

Post by themafia »

api wrote: post #10

An 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 u…

> That includes the discipline to be ruthless about exterminating complexity and saying no. That’s institutionally hard.

You need to make a product that out-performs your competitors. If their chip is faster then your work will be ignored regardless of how pure you managed to keep it.

> We may be past the window where rethinking architectural choices is possible.

I think your presumption that our architectures are extremely sub-optimal is wrong. They're exceptionally optimized. Just spend some time thinking about branch prediction and register renaming. It's a steep cliff for any new entrant. You not only have to produce something novel and worthwhile but you have to incorporate decades of deep knowledge into the core of your product, and you have to do all of that without introducing any hardware bugs.

You stand on the shoulders of giants and complain about the style of their footwear.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#64

Post by int_19h »

api wrote: post #10

An 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 u…

The thing about AI though is that it has indirect effects down the line. E.g. as prevalence of AI-generated code increases, I would argue that we'll need more guardrails both in development (to ground the model) and at runtime (to ensure that when it still fails, the outcome is not catastrophic).

Re: Linear Address Spaces: Unsafe at any speed (2022)

#65

Post by inkyoto »

mpweiher wrote: post #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…

> Because the attempts at segmented or object-oriented address spaces failed miserably.

> 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.

I would further posit that segmented and object-oriented address spaces have failed and will continue to fail for as long as we have a separation into two distinct classes of storage: ephemeral (DRAM) and persistent storage / backing store (disks, flash storage, etc.) as opposed to having a single, unified concept of nearly infinite (at least logically if not physically), always-on just memory where everything is – essentially – an object.

Intel's Optane has given us a brief glimpse into what such a future could look like but, alas, that particular version of the future has not panned out.

Linear address space makes perfect sense for size-constrained DRAM, and makes little to no sense for the backing store where a file system is instead entrusted with implementing an object-like address space (files, directories are the objects, and the file system is the address space).

Once a new, successful memory technology emerges, we might see a resurgence of the segmented or object-oriented address space models, but until then, it will remain a pipe dream.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#66

Post by josefx »

layer8 wrote: post #58
IsTom wrote: post #25

> the data bus is 128 bits wide: 64-bit for the data and 64-bit for data's type That seems a bit wasteful if you're not using a lot of object types.

64-bit pointers tend to be a bit wasteful as well.

Especially on a system from the 80s, did they plan to address every bit of memory available on the planet?

Re: Linear Address Spaces: Unsafe at any speed (2022)

#67

Post by inkyoto »

nine_k wrote: post #9
tliltocatl wrote: post #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 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…

> But we don't have a linear address space, unless you're working with a tiny MCU.

We actually do, albeit for a brief duration of time – upon a cold start of the system when the MCU is inactive yet, no address translation is performed, and the entire memory space is treated as a single linear, contiguous block (even if there are physical holes in it).

When a system is powered on, the CPU runs in the privileged mode to allow an operating system kernel to set up the MCU and activate it, which takes place early on in the boot sequence. But until then, virtual memory is not available.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#68

Post by loeg »

inkyoto wrote: post #67
nine_k wrote: post #9

Earlier quoted context omitted.

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…

> But we don't have a linear address space, unless you're working with a tiny MCU. We actually do, albeit for a brief duration of time – upon a cold start of the system when the MCU is inactive yet, no address translation is performed, and the entire memory space is treated as a single linear, contiguous block (even if there are physical holes in it). When a system is powered on, the CPU runs in the privileged mode t…

Those holes can be arbitrarily large, though, especially in weirder environments (e.g., memory-mapped optane and similar). Linear address space implies some degree of contiguity, I think.

Re: Linear Address Spaces: Unsafe at any speed (2022)

#70

Post by loeg »

senko wrote: post #49
Veserv wrote: post #27

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. 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.

PHK is far from infallible.
Post reply on HN