Comment by monocasa
4 years ago
> What stack modifications? Sure, the child can scribble over the stack frame, or worse, the child could do things like return -- but you're the author of the code calling vfork() and you know not to do that
Within a sentence you described the stack modification. 'It's not a footgun, just don't make mistakes' doesn't hold a lot of water with me.
> No, really, what you say about vfork() is lore, and very very wrong.
Like I've said elsewhere in the comments, I've literally had to fix awful bugs, some security related, from how much vfork() is a preloaded foot gun with the safety off. Not everyone who has a bad impression of it is just following the "lore".
> afork()/avfork() is not meant to be as general as clone() but to be more performant than vfork() by not blocking a thread on the parent side.
Ok, but I'm not going to hold it against clone for being a more general solution.
> clone() needs some improvements. It should be possible to create a container additively. See elsewhere in the comments on this post.
I agree with this, but there's practical reasons why this isn't the case, mainly around how asking user space for every little thing is expensive, and large sparse structs to copy into kernel space covering basically everything in struct task sounds like a special kind of security hell I would not want to be a part of.
A flag to clone to create an empty process and something like a bunch of io_uring calls or a box program to hydrate the new task state would be really neat, and has been kicked around a bunch. There's just a ton corner cases that haven't been ironed out.
> 'It's not a footgun, just don't make mistakes.'
fork() -> fork bombs -> fork() is a footgun!
You have to know how to use it. Yes. So what?
> Like I've said elsewhere in the comments, I've literally had to fix awful bugs, some security related, from how much vfork() is a preloaded foot gun with the safety off. Not everyone who has a bad impression of it is just following the "lore".
Links or it didn't happen :)
> fork() -> fork bombs -> fork() is a footgun!
> You have to know how to use it. Yes. So what?
No, you have to own everything that you could call. For one example of many, are you in and out of a library that longjump's? That's really fun.
Basically vfork's sharing of the full on mutable stack between the parent and child is full on bananers.
> Links or it didn't happen :)
You know that some people write proprietary code, even for unixen, right?
> No, you have to own everything that you could call. For one example of many, are you in and out of a library that longjump's? That's really fun.
That is also true of fork().
You're supposed to only use async-signal-safe functions on the child-side of fork().
It is surprisingly easy to do dumb things with fork().
> You know that some people write proprietary code, even for unixen, right?
I was hoping it was in open source code.
5 replies →