Support CLONE_FS and CLONE_FILES with fork() semantics

[asahilina]

Needed by Discord, part of the Chromium sandbox code. The warning still triggers because Chromium asks for CLONE_VM on x86_64, but that can be safely ignored (CLONE_FS is the one that matters).

I'm not sure if this is exactly the right semantics, but it seems like an improvement at least?

With this and a hack to allow the FEXServer connection to fail (which happens because the sandbox puts the process in a new netns so the UNIX socket doesn't work, not sure what to do about that...), Discord gets as far as the main window and then crashes (without these changes it dies very early).

[neobrain]

What's the difference between fork and clone3 as used here? Are they equivalent as long as these new flags aren't set?

[asahilina]

What's the difference between fork and clone3 as used here? Are they equivalent as long as these new flags aren't set?

I think so but I haven't found an exact reference for what clone3() inputs are strictly identical to fork(), so this is just what I gather from skimming the manpage...

[Sonicadvance1]

Needs code formatted.

[asahilina]

Should be fixed I think!

[Sonicadvance1]

What's the difference between fork and clone3 as used here? Are they equivalent as long as these new flags aren't set?

Clone/clone3 supports everything that fork and vfork can do, just in a more configurable syscall. There's a good chance that for FEX to properly implement vfork, that we will need to use clone, so we can pivot the host stack at the point of calling even.