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

51–60 of 183 posts

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

#51

Post by Veserv »

josephg wrote: post #47
musicale wrote: post #19

Earlier quoted context omitted.

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?

x86-64 call instruction decrements the stack pointer to push the return address. x86-64 push instructions decrement the stack pointer. The push instructions are easy to work around because most compilers already just push the entire stack frame at once and then do offset accesses, but the call instruction would be kind of annoying.

ARM does not suffer from that problem due to the usage of link registers and generic pre/post-modify. RISC-V is probably also safe, but I have not looked specifically.

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

#52

Post by Veserv »

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.

And they addressed exactly none of the relevant points, instead supporting their arguments by waving in the general direction of outcompeted designs and speculative designs.

CHERI is neat, but, as far as I am aware, still suffers from serious unsolved problems with respect to temporal safety and reclamation. Last I looked (which was probably after 2022 when this post was made), the proposed solutions were hardware garbage collectors which are almost a non-starter. Could that be solved or performant enough? Maybe. Is a memory allocation strategy that can not free objects a currently viable solution for general computing to the degree you argue people not adopting it are whiners? No.

I see no reason to accept a fallacious argument from authority in lieu of actual arguments. And for that matter, I literally do kernel development on a commercial operating system and have personally authored the entirety of memory management and hardware MMU code for multiple architectures. I am a actual authority on this topic.

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

#53

Post by tliltocatl »

userbinator wrote: post #33

More advocacy propaganda for corporate authoritarianism under the guise of "safety". Locked-down systems like he describes fortunately died out long ago, but they are making a vicious comeback and will take over unless we fight it as much as we can.

Whatever a system is locked down is not a technology issue, it's about who have the key. You wouldn't be using MS-DOS today. Having more controls over what the applications are up to would be beneficial for the user. The modern multitasking systems have their origin in the time-sharing systems (which are exactly the locked-down ones) where security was "protect the admin's authority, protect users from each other" and hence "what application does is by definition authorized by the user that started the application". Then we started adding some "protect user data from the programs" safeguards but on desktop it always was an afterthought and on mobile the new security model is "protect the platform vendor authority from the user". Sadly a new API designed around "protect programs from each other, enforce users authority" never materialized.

But all of this is about IO. What OP is talking about is memory model and the changes they propose is not about "don't let the unauthorized ones do things" but rather "make it harder for a confused deputy do things". This one is pretty uncontroversial in its intent, though I personally don't really agree with the approach.

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

#54

Post by tliltocatl »

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

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…

But that wouldn't protect against out-of boundary access (which is the whole point of segments), would it?

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

#55

Post by LukeShu »

ch_123 wrote: post #31
Joker_vD wrote: post #12

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

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

Linux on PA-RISC also has an upward-growing stack (AFAIK, it's the only architecture Linux has ever had an upward-growing stack on; it's certainly the only currently-supported one).

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

#56

Post by altairprime »

Veserv wrote: post #52
senko wrote: post #49

Earlier quoted context omitted.

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

And they addressed exactly none of the relevant points, instead supporting their arguments by waving in the general direction of outcompeted designs and speculative designs. CHERI is neat, but, as far as I am aware, still suffers from serious unsolved problems with respect to temporal safety and reclamation. Last I looked (which was probably after 2022 when this post was made), the proposed solutions were hardware ga…

> And they addressed exactly none of the relevant points

Clarification: They addressed exactly none of the points you declare as relevant. You identify as an expert in the field and come across as plausibly such, so certainly I’ll still give your opinion on what’s relevant some weight.

Perhaps the author was constrained by a print publication page size limit of, say, one? Or six? That used to be a thing in the past, where people would publish opinions in industry magazines and there was a length cap set by the editor that forced cutting out the usual academic-rigor levels of detail in order to convey a mindset very briefly. What would make a lovely fifty or hundred page paper in today’s uncapped page size world, would have to be stripped of so much detail — of so much proof — in order to fit into any restrictions at all, that it would be impossible to address all possible or even probable argument in a single sitting.

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

#57

Post by turtletontine »

loeg wrote: post #39
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.

Tbh I can imagine this catching on if one of the big cloud providers endorses it. Including hardware support in a future version of AWS Graviton, or Azure cloud with a bunch of foundational software already developed to work with it. If one of those hyper scalers puts in the work, it could get to the point where you can launch a simple container running Postgres or whatever, with the full stack adapted to work with CHERI.

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

#59

Post by yjftsjthsd-h »

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.

I am forever sad that x32 didn't take off. Lower memory use, great performance. Ah well.
Post reply on HN