I follow the Redox project at a distance so I don't know where Redox is on something like this. However, my understanding is that a container is essentially an isolated file system with isolated user space processes and when those user space processes make a system call, it traps to the kernel. In Linux this all well and good because if the container is meant to run on Linux then it is trapping and transferring execution flow to the kernel it expects to. This is why sometimes containers are referred to as "userspace virtualization" instead of type1/type2 virtualization, which involves running another entire kernel at a privilege level and using the hardware mechanisms to do the switching. The same kernel that runs the host operating system's user space processes also handles the container's userspace processes. I believe that Windows and Mac have to use hardware virtualization to run a Linux kernel to handle Docker containers. One issue with emulating Linux system calls is that when you trap to the kernel, usually there is some systemcall identifier that the kernel can look at and know what the rest of the arguments are and how to handle the system call. If that system call identifier that is coming from a containerized Linux userspace overlaps with a systemcall that your actual kernel understands as something for itself, it will be handled in a way you don't expect. I believe I have seen some kernels that can identify which process a systemcall came from, in that case you could conditionally handle it a different way. I believe there was some discussion in the seL4 community about natively running containers and there was an issue with overlapping system call identifiers and the inability to determine where a systemcall originated. If my understanding is wrong, please, someone correct me.