Introduce a new Redox-specific syscall, SYS_SUPERVISE.

Created by: ticki

Problem: You cannot gain fine-grained control over a child process in Redox. This makes it possible to do things which are clasically covered by ptrace, seccomp, chroot and friends: to run another process in a restricted, traced, and supervised environment, which is useful for various purposes, such as emulation, virtualisation, logging, and debugging.

Solution: Introduce a new system call, SUPERVISE, which allows the parent process to handle the system calls of the child process, by blocking the child process when system calls are received.

Changes introduced by this pull request:

• Introduce a system call, SUPERVISE:

  SUPERVISE takes a PID specifing the process to be supervised. This PID must be a child process of the invoker. If not, EACCES will be returned.

  The process identified by the given PID will be restricted in such a way, that every syscall made will mark the process as blocked and store the syscall until it is handled by the parrent.

  The return value (if successful) is a file descriptor, from which syscalls can be read and written: the syscalls are read in Packet sized packages, containing the respective blocking syscall. If no syscall is blocking (or the last blocking syscall have been handled), 0 bytes will be read to the buffer.

  Writing pointer sized integers to this file handle will set the EAX register of the particular process, after which the process is unblocked and the syscall buffer is emptied. The behavior of writing packages of unexpected size is unspecified.

  Note that a process blocked by a syscall will have its potential sleep cleared (i.e., it will not wake up after the sleep is finished).

  Passing a non-existent PID results in ESRCH.

• Add a flag, CLONE_SUPERVISE, to SYSCLONE. This flag will make the clone enter supervised mode immediately. This means that the process can run in supervised mode, even not being connected to a supervisor yet. In other words, the parent can later on supervise the process and handle the potential blocking syscall.

  This is an important security measure, since otherwise the process would be able to fork it self right after starting, making supervising it impossible.

• Add a spawn_supervised method to Command, which will spawn the command with the CLONE_SUPERVISED flag.

• Slightly refactor the Command internals to allow specifing arbitrary flags to SYS_CLONE.

Drawbacks: Increased complexity and surface area. One might argue that it, on a long-term basis, does the opposite: namely allow us to retain compatibility without introducing extra syscalls into the kernel.

TODOs:

• Security analysis.
• Add a strace tool to extrautils.
• Add a restrict tool to extrautils.
• Create a Linux compatibility layer.
• Allow handling certain non-0x80 interrupts?

There are no known issues otherwise.

State: Ready, though it require future work (see TODO).

Other: sry for the eastereggs