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

Memory Safe Context Switching

fil-c.org

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Memory Safe Context Switching

#21

Post by pizlonator »

gruntled-worker wrote: post #20
pizlonator wrote: post #12

Earlier quoted context omitted.

What misuse are you imagining that isn’t a memory safety problem? You might find that Fil-C prevents those too. It’s pretty strict. You can only use longjmp to pop stack like an exception would

Resource leaks, crossing non-exception-safe library/system code, CPU-specific quirks like accidentally unrestored FP/vector/control state, etc. Granted it's always been highly system-specific stuff, but that's the worst kind.

Gotcha, that’s a good list.

It’s true that Fil-C doesn’t try to protect you from those bugs. I just don’t think of those as the worst things that can happen when you misuse these APIs.

Re: Memory Safe Context Switching

#22

Post by pizlonator »

anitil wrote: post #7
lstodd wrote: post #4

longjmp, setjmp, setcontext, getcontext, makecontext, and swapcontext and whatever have no bearing on safety, memory or otherwise. What you have to deal with is what is represented by sigaction(2) and only and much later then by what you use to drive the context switch, be it io, or preemptive.

The article mentions that you typically have to longjmp within the same function as setjump (or a descendant function) otherwise your stack gets cleared and you longjmp to a garbage stack. I believe this counts as memory safety? Though I don't quite understand your comment about sigaction, so maybe there's some context I'm missing. Edit: The extra context- https://usenix.org/legacy/publications/library/proceedings/u.…

You don’t have to be in the same function as the setkom; you just have to be in a frame that’s deeper in the stack, or the same frame

The point about memory safety is really this: if I allowed you to longjmp but did not guard it adequately then you could escape the Fil-C capability model, and then all of Fil-C’s bets would be off. I can’t have that ;-)

Re: Memory Safe Context Switching

#23

Post by quotemstr »

matheusmoreira wrote: post #9

This is an article I wish I could have read many months ago. > Hence, the most basic safety issue with setjmp is that if we call it and then return from the function that had called it, the context saved by setjmp is not valid to longjmp to. > longjmp is only safe if it's called at a time when the stack frame used by setjmp could not have possibly been overwritten, since that is the only way to guarantee that the reg…

> What ruins this for C is the existence of pointers. Stacks aren't freely relocatable since pointers into the stack could exist.

I sometimes wonder what computing would be like if the 80286 hadn't sucked, if segmentation had won over flat address spaces, and if we'd been able to do relocation pain-free by changing a segment base register in one spot instead of rewriting linear pointers everywhere. We could have done paging within segments.

Oh well.

Re: Memory Safe Context Switching

#24

Post by toast0 »

> longjmp panics unless it is called from a stack frame that is an ancestor of a stack frame that considers the zjmp_buf to be valid.

Maybe I have things backwards, but I think you mean descendent and not ancestor here?

If a() calls b(), I wouldn't think the stack frame while running b is the ancestor of a.

Re: Memory Safe Context Switching

#25

Post by dzaima »

quotemstr wrote: post #23
matheusmoreira wrote: post #9

This is an article I wish I could have read many months ago. > Hence, the most basic safety issue with setjmp is that if we call it and then return from the function that had called it, the context saved by setjmp is not valid to longjmp to. > longjmp is only safe if it's called at a time when the stack frame used by setjmp could not have possibly been overwritten, since that is the only way to guarantee that the reg…

> What ruins this for C is the existence of pointers. Stacks aren't freely relocatable since pointers into the stack could exist. I sometimes wonder what computing would be like if the 80286 hadn't sucked, if segmentation had won over flat address spaces, and if we'd been able to do relocation pain-free by changing a segment base register in one spot instead of rewriting linear pointers everywhere. We could have done…

That'd only help for one object per address space. Main thing needing relocation - shared libraries - needs arbitrarily-many segment bases.

And when you're not a library, relocation is just a mild probabalistic security improvement (...that'd be massively-more bypassable than it already is if the program was littered full of gadgets of "read register as unrelocated offset and use it with its correct base" instructions).

Re: Memory Safe Context Switching

#27

Post by dcuthbertson »

toast0 wrote: post #24

> longjmp panics unless it is called from a stack frame that is an ancestor of a stack frame that considers the zjmp_buf to be valid. Maybe I have things backwards, but I think you mean descendent and not ancestor here? If a() calls b(), I wouldn't think the stack frame while running b is the ancestor of a.

> If a() calls b(), I wouldn't think the stack frame while running b is the ancestor of a.

I think of b as the child/descendant of a because a creates the running instance of b, and that makes a the parent/ancestor of b.

Re: Memory Safe Context Switching

#28

Post by infogulch »

Couldn't we just permanently solve the stack copying issue by always using a per-stack base pointer + offset for all stack objects? Copy stack -> update base pointer -> done. Trying to access a stack object on a different thread? That's retarded don't do that allocate it on the heap instead.

Re: Memory Safe Context Switching

#29

Post by pizlonator »

toast0 wrote: post #24

> longjmp panics unless it is called from a stack frame that is an ancestor of a stack frame that considers the zjmp_buf to be valid. Maybe I have things backwards, but I think you mean descendent and not ancestor here? If a() calls b(), I wouldn't think the stack frame while running b is the ancestor of a.

I meant descendant. Fixed.

Re: Memory Safe Context Switching

#30

Post by matheusmoreira »

infogulch wrote: post #28

Couldn't we just permanently solve the stack copying issue by always using a per-stack base pointer + offset for all stack objects? Copy stack -> update base pointer -> done. Trying to access a stack object on a different thread? That's retarded don't do that allocate it on the heap instead.

Could be done, but it probably wouldn't work with existing C binary interfaces.
Post reply on HN