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

71–80 of 183 posts

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

#71

Post by inkyoto »

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.

Meet TIMI – the Technology Independent Machine Interface of IBM's i Series (nèe AS/400), which defines pointers as 128-bit values[0], which is a 1980's design.

It has allowed the AS/400 to have a single-level store, which means that «memory» and «disk» live in one conceptual address space.

A pointer can carry more than just an address – object identity, type, authority metadata – AS/400 uses tagged 16-byte pointers to stop arbitrary pointer fabrication, which supports isolation without relying on the usual per-process address-space model in the same way UNIX does.

Such «fat pointer» approach is conceptually close to modern capability systems (for example CHERI’s 128-bit capabilities), which exist for similar [safety] reasons.

[0] 128-bit pointers in the machine interface, not a 128-bit hardware virtual address space though.

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

#72

Post by agumonkey »

inkyoto wrote: post #71
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.

Meet TIMI – the Technology Independent Machine Interface of IBM's i Series (nèe AS/400), which defines pointers as 128-bit values[0], which is a 1980's design. It has allowed the AS/400 to have a single-level store, which means that «memory» and «disk» live in one conceptual address space. A pointer can carry more than just an address – object identity, type, authority metadata – AS/400 uses tagged 16-byte pointers t…

is this still used in IBM hardware ?

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

#73

Post by wyager »

> Like mandatory seat belts, some people argue that there would be no need for CHERI if everyone "just used type-safe languages"[...] I'm not having any of it.

It wish the author would have offered a more detailed refutation than "I'm not having it". I'm pretty sure the claim is right! I'm fairly convinced that we'd be a lot better off moving to ring0-only linear-memory architectures and rely on abstraction-theoretic security ("langsec") rather than fattening up the hardware with random whack-a-mole mitigations. We're gradually moving in that direction anyway without much of a concerted effort.

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

#74

Post by inkyoto »

loeg wrote: post #68
inkyoto wrote: post #67

Earlier quoted context omitted.

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

Indeed. It can get ever weirder in the embedded world where a ROM, an E(E)PROM or a device may get mapped into an arbitrary slice of physical address space, anywhere within its bounds. It has become less common, though.

But devices are still commonly mapped at the top of the physical address space, which is a rather widespread practice.

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

#75

Post by suspended_state »

drob518 wrote: post #48
mikewarot wrote: post #6

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

But that address doesn't have to be visible at the ISA level.

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

#76

Post by inkyoto »

agumonkey wrote: post #72
inkyoto wrote: post #71

Earlier quoted context omitted.

Meet TIMI – the Technology Independent Machine Interface of IBM's i Series (nèe AS/400), which defines pointers as 128-bit values[0], which is a 1980's design. It has allowed the AS/400 to have a single-level store, which means that «memory» and «disk» live in one conceptual address space. A pointer can carry more than just an address – object identity, type, authority metadata – AS/400 uses tagged 16-byte pointers t…

is this still used in IBM hardware ?

It is, although TIMI does not exist in the hardware – it is a virtual architecture that has been implemented multiple times in different hardware (i.e., CPU's – IMPI, IBM RS64, POWER, and only heavens know which CPU IBM uses today).

The software written for this virtual architecture, on the other hand, has not changed and continues to run on modern IBM iSeries systems, even when it originates from 1989 – this is accomplished through static binary translation, or AOT in modern parlance, which recompiles the virtual ISA into the target ISA at startup.

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

#77

Post by LegionMammal978 »

inkyoto wrote: post #65
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 di…

I don't see how any amount of memory technology can overcome the physical realities of locality. The closer you want the data to be to your processor, the less space you'll have to fit it. So there will always be a hierarchy where a smaller amount of data can have less latency, and there will always be an advantage to cramming as much data as you can at the top of the hierarchy.

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

#78

Post by duped »

inkyoto wrote: post #65
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 di…

I shudder to think about the impact of concurrent data structures fsync'ing on every write because the programmer can't reason about whether the data is in memory where a handful of atomic fences/barriers are enough to reason about the correctness of the operations, or on disk where those operations simply do not exist.

Also linear regions make a ton of sense for disk, and not just for performance. WAL-based systems are the cornerstone of many databases and require the ability to reserve linear regions.

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

#79

Post by [deleted] »

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…

[deleted]

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

#80

Post by api »

themafia wrote: post #63
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 ex…

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 greenfield, say, an engine or an aircraft design, since doing so does not break compatibility with everything. If aviation were like computing, coffee mugs from propeller aircraft would fail to hold coffee (or even be mugs) on a jet aircraft.

Post reply on HN