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

31–40 of 183 posts

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

#31

Post by ch_123 »

Joker_vD wrote: post #12
btdmaster wrote: post #3

I think you could argue there is already some effort to do type safety at the ISA register level, with e.g. shadow stack or control flow integrity. Isn't that very similar to this, except targeting program state rather than external memory?

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.

HP-UX on PA-RISC had an upward-growing stack. In practice, various exploits were developed which adapted to the changed direction of the stack.

One source from a few mins of searching: https://phrack.org/issues/58/11

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

#32

Post by dmytroi »

armv8/VMSAv8-64 has huge table support with optional contiguous bit allowing mapping up to 16GB at a time [0] [1]. Which will result in (almost) no address translations on any practical amount of memory available today.

Likely the issue is between most user systems not configuring huge tables and developers not keen on using things they can't test locally. Though huge tables are prominent in single-app servers and game consoles spaces.

- [0] https://docs.kernel.org/arch/arm64/hugetlbpage.html - [1] https://developer.arm.com/documentation/ddi0487/latest (section D8.7.1 at the time of writing)

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

#34

Post by nine_k »

formerly_proven wrote: post #22
convolvatron wrote: post #15

Earlier quoted context omitted.

its entirely possible to implement segments on top of paging. what you need to do is add the kernel abstractions for implementing call gates that change segment visibility, and write some infrastructure to manage unions-of-a-bunch-of-little-regions. I haven't implemented this myself, but a friend did on a project we were working on together and as a mechanism it works perfectly well. getting userspace to do the right…

"Please give me a segmented memory model on top of paged memory" - words which have never been uttered

There is a subtle difference between "give me an option" and "thrust on me a requirement".

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

#35

Post by minraws »

This like saying generic systems are bad because you and a hacker both can make sane assumptions about it, thus even if more performant/usable it's also more vulnerable hence shouldn't be used.

I don't understand this.

I have seen bad takes but this one takes the cake. Brilliant start to 2026...

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

#36

Post by amelius »

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

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

#37

Post by api »

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

> something faster How true is this, really? When does the OS kernel take up more than a percent or so of a machine's resources nowadays? I think the problem is that there is so little juice there to squeeze that it's not worth the huge effort.

The problem isn’t direct overhead. The problem is shit APIs like blocking I/O that we constantly have to work around via heroic extensions like io_uring, an inefficient threading model that forces every app to roll its own scheduler (async etc.), lack of OS level support for advanced memory management which would be faster than doing it in user space, etc.

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

#39

Post by loeg »

indolering wrote: post #11

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

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

#40

Post by loeg »

amelius wrote: post #36
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. 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…

Do you think a 1980s computer has no drawbacks compared to 2020 vintage CPUs? It "works..." very slowly and with extremely high power draw. A 1980s design does not in any way prove that the model is viable compared to the state of the art today.
Post reply on HN