Linear Address Spaces: Unsafe at any speed (2022) • Hacker News Board

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

#171

Post by bakul » Tue, Jan 06, 2026, 6:47 PM UTC

phkamp wrote: post #128

Author 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…

Poul, have you looked at the Mill Architecture? It doesn't provide capabilities but provides "turfs". A turf is a set of [base..limit) regions in a single address space. Threads within a turf can only see what the turf allows them to see. Regions can be shared between turfs if so desired (& how one may communicate large amounts of data). When a thread makes a "portal call" it is in another turf and can only see what is in that turf (+ call args, passed on the "belt"). Not clear if this will go anywhere & might get forgotten but it is an interesting architecture worth exploring.

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

#172

Post by Veserv » Tue, Jan 06, 2026, 7:39 PM UTC

mike_hearn wrote: post #167

marcosdumay wrote: post #149

Earlier quoted context omitted.

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.

The proposal is more generic than that, it is throwing away translation of any kind. If all you do is replace virtual memory to physical memory translation with object ID to physical memory translation then you buy almost nothing in terms of access complexity.

That means there is no indirection between reference and the backing physical store. To change the backing memory you need to change the reference.

As you point out, within a program you can solve fragmentation by using a compacting GC. However, you will still suffer from cross-program fragmentation. You can not move the backing store of those programs without rewriting their references. You can not even page out those programs and reload them into new locations without rewriting all their references. You effectively need a global, shared, cross-program compacting GC to handle fragmentation; a hardware or kernel GC.

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

#173

Post by jjuran » Tue, Jan 06, 2026, 8:52 PM UTC

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.

Implementing fork() without address translation is possible — it's just expensive.

In MacRelix (a POSIX-like environment for classic Mac OS), when a process calls fork(), the system allocates backup memory regions for it and its child. Whenever one of them is switched in after its counterpart was the last of the two to run, the old one's regions are backed up and the new one's regions restored.

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

#174

Post by StillBored » Wed, Jan 07, 2026, 2:52 AM UTC

mpweiher wrote: post #129

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…

> The 80386 introduced the flat address space ... This may be misleading: the 80386 introduced flat address space and paged virtual memory _in the Intel world_, not in general. At the time it was introduced, linear / flat address space was the norm for 32 bit architectures, with examples such as the VAX, the MC68K, the NS32032 and the new RISC processors. The IBM/360 was also (mostly) linear. So with the 80386, Intel…

So with the 80386, Intel finally abandoned their failed approach of segmented address spaces and joined the linear rest of the world. (Of course the 386 is technically still segmented, but let's ignore that).

That seems an odd interpretation of how they extended the 286 protected mode on the 386. The 286 converted the fixed address+64k sized segment registers to 'selectors' in the LDT/GDT which added permissions/etc to a segment descriptor structure which were transparently cached along with the 'base' of the segment in generally invisible portions of the register. The problem with this approach was the same as CHERI/etc that it requires a fat pointer comprising the segment+offset which to this day remains problematic with standard C where certain classes of programmers expect that sizeof (void*) == sizeof (int or long).

Along comes the 386 with adds a further size field (limit) to the segment descriptor which can be either bytes or pages.

And of course it added the ability to back linear addresses with paging, if enabled.

Its entirely possible to run the 386 in an object=segment only mode where each data structure exists in its own segment descriptor and the hardware enforces range checking, and heap compression/etc can happen automatically by simply copying the segment to another linear address and adjusting the base address. By today standards the number of outstanding segment descriptors is limiting, but remember 1985 when a megabyte of RAM was a pretty reasonable amount...

The idea that someone would create a couple descriptors with base=0:limit=4G and set all the segment register to them, in order to assure that int=void * is sorta a known possible misuse of the core architecture. Of course this basically requires paging as the processor then needs to deal with the fact that it likely doesn't actually have 4G of ram, and the permissions model then is enforced at a 4K granularity. Leaving open all the issues C has with buffer overflows, and code + data permissions mixing/etc. Its not a better model, just one easier to reason about initially, but then for actual robust software starts to fall apart for long running processes due to address space fragmentation and a lot of other related problems.

AKA, it wasn't necessarily the best choice, and we have been dealing with the repercussion of lazy OS/systems programmers for the 40 years since.

PS: intel got(gets) a lot of hate from people wanting to rewrite history, by ignoring the release date of many of these architectural advancements. Ex the entire segment register 'fiasco' is a far better solution than the banked memory systems available in most other 8/16 bit machines. The 68000 is fully a year later in time, and makes no real attempt at being backwards compatible with the 6800 unlike the 8086 which is clearly intended to be a replacement for the 8080.

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

#175

Post by mpweiher » Wed, Jan 07, 2026, 10:00 AM UTC

phkamp wrote: post #137

mpweiher wrote: post #134

Earlier quoted context omitted.

It isn't 100% proof that the concept is flawed, but the fact that the for decades most successful CPU manufacturer in the world couldn't make segmentation work in multiple attempts is pretty strong evidence that at least there are, er, "issues" that aren't immediately obvious. I think it is safe to assume that they applied what they learned from their earlier failures to their later failures. Again, we can never be 1…

All the examples you bring up are from an entirely different time in terms of hardware, a time where one of the major technological limitations were how many pins a chip could have and two-layer PCBs. Ideas can be good, but fail because they are premature, relative to the technological means we have to implement them. (Electrical vehicles will probably be the future text-book example of this.) The interesting detail…

> examples from different time

Yes, because (a) you asked a question about how we got here and (b) that question actually has a non-rhetorical historical answer. This is how we got here, and that's when it pretty much happened.

> one of the major technological limitations were how many pins a chip could have and two-layer PCBs

How is that relevant to the question of segmentation vs. linear address space? In your esteemed opinion? The R1000 is also from that erea, the 68451 and 68851 were (almost) contemporaries, and once the MMU was integrated into the CPU, the pins would be exactly the same.

> Ideas can be good, but fail because they are premature

Sure, and it is certainly possible that in the future, segmentation will make a comeback. I never wrote it couldn't. I answered your question about how we got here, which you answered incorrectly in the article.

And yes, the actual story of how we got here does indicate that hardware segmentation is problematic, though it doesn't tell us why. It also strongly hints that hardware segmentation is both superficially attractive and less obviously, but subtly and deeply flawed.

CHERI is an interesting approach and seems workable. I don't see how it's been documented to be worth the cost, as we simply haven't had wide-spread adoption yet. Memory pressure is currently the main performance driver ("computation is what happens in the gaps while the CPU waits for memory"), so doubling pointer sizes is definitely going to be an issue.

It certainly seems possible that CHERI will push us more strongly away from direct pointer usage than 64 bit already did, towards base + index addressing. Maybe a return to object tables for OO systems? And for large data sets, SOAs. Adjacency tables for graphs. Of course those tend to be safe already.

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

#176

Post by mike_hearn » Wed, Jan 07, 2026, 10:33 AM UTC

Veserv wrote: post #172

mike_hearn wrote: post #167

Earlier quoted context omitted.

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.

The proposal is more generic than that, it is throwing away translation of any kind. If all you do is replace virtual memory to physical memory translation with object ID to physical memory translation then you buy almost nothing in terms of access complexity. That means there is no indirection between reference and the backing physical store. To change the backing memory you need to change the reference. As you poin…

Yeah, I think single address space OS like Singularity would be the way to go there.

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

#177

Post by mpweiher » Wed, Jan 07, 2026, 12:52 PM UTC

StillBored wrote: post #174

mpweiher wrote: post #129

Earlier quoted context omitted.

> The 80386 introduced the flat address space ... This may be misleading: the 80386 introduced flat address space and paged virtual memory _in the Intel world_, not in general. At the time it was introduced, linear / flat address space was the norm for 32 bit architectures, with examples such as the VAX, the MC68K, the NS32032 and the new RISC processors. The IBM/360 was also (mostly) linear. So with the 80386, Intel…

So with the 80386, Intel finally abandoned their failed approach of segmented address spaces and joined the linear rest of the world. (Of course the 386 is technically still segmented, but let's ignore that). That seems an odd interpretation of how they extended the 286 protected mode on the 386. The 286 converted the fixed address+64k sized segment registers to 'selectors' in the LDT/GDT which added permissions/etc…

You did see that bit you quoted?

> (Of course the 386 is technically still segmented, but let's ignore that)

Yes, the 80386 was still technically segmented, but the overwhelming majority of operating systems (95%+) effectively abandoned segmentation for memory protection and organization, except for very broad categories such as kernel vs. user space.

Instead, they configured the 80386 registers to provide a large linear address space for user processes (and usually for the kernel as well).

> The idea that someone would create a couple descriptors with base=0:limit=4G and set all the segment register to them, in order to assure that int=void * is sorta a known possible misuse of the core architecture

The thing that you mischaracterize as a "misuse" of the architecture wasn't just some corner case that was remotely "possible", it was what 95% of the industry did.

The 8086 wasn't so much a design as a stopgap hail-mary pass following the fiasco of the iAPX 432. And the VAX existed long before the 8086.

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

#178

Post by StillBored » Wed, Jan 07, 2026, 2:44 PM UTC

mpweiher wrote: post #177

StillBored wrote: post #174

Earlier quoted context omitted.

So with the 80386, Intel finally abandoned their failed approach of segmented address spaces and joined the linear rest of the world. (Of course the 386 is technically still segmented, but let's ignore that). That seems an odd interpretation of how they extended the 286 protected mode on the 386. The 286 converted the fixed address+64k sized segment registers to 'selectors' in the LDT/GDT which added permissions/etc…

You did see that bit you quoted? > (Of course the 386 is technically still segmented, but let's ignore that) Yes, the 80386 was still technically segmented, but the overwhelming majority of operating systems (95%+) effectively abandoned segmentation for memory protection and organization, except for very broad categories such as kernel vs. user space. Instead, they configured the 80386 registers to provide a large li…

I think my point revolves more around what the HW designers were enabling. If they thought that the flat model was the right one, they would have just kept doing what the 286 did, and fixed the segment sizes at 4G.

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

#179

Post by api » Wed, Jan 07, 2026, 2:56 PM UTC

mike_hearn wrote: post #125

api wrote: post #80

Earlier quoted context omitted.

That’s another reason current designs are probably locked in. It’s called being stuck at a local maximum. I’m not saying what we have is bad, just that the benefit of hindsight reveals some things. Computing is tougher than other areas of engineering when it comes to greenfielding due to the extreme interlocking lock-in effects that emerge from things like instruction set and API compatibility. It’s easier to greenfi…

Aviation does have a lot of backwards compatibility problems. It's one reason Boeing kept revving the 737 to make the Max version. The constraints come from things like training, certification, runway length, fuel mixes, radio protocols, regulations...

I still think those are less "hard" and non-negotiable than API and architecture lock-in in computing.

The physical world in general is more analog, more open to gradual and "soft" change. Digital things work or do not work, so any change to the foundation just hard-breaks the universe.

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

#180

Post by mpweiher » Wed, Jan 07, 2026, 3:48 PM UTC

StillBored wrote: post #178

mpweiher wrote: post #177

Earlier quoted context omitted.

You did see that bit you quoted? > (Of course the 386 is technically still segmented, but let's ignore that) Yes, the 80386 was still technically segmented, but the overwhelming majority of operating systems (95%+) effectively abandoned segmentation for memory protection and organization, except for very broad categories such as kernel vs. user space. Instead, they configured the 80386 registers to provide a large li…

I think my point revolves more around what the HW designers were enabling. If they thought that the flat model was the right one, they would have just kept doing what the 286 did, and fixed the segment sizes at 4G.

Yes. The point is that the hardware designers were wrong in thinking that the segmented model was the right one.

The hardware designers kept enabling complex segmented models using complex segment machinery. Operating system designers fixed the segments as soon as the hardware made that possible in order to enable a flat (paged) memory model and never looked back.