The idea is t run a binary in userspace called 'starnix' that will work as a glue between the linux syscalls and the fuchsia kernel.
This is possible given they designed it in a micro-kernel like fashion, where things are more modular and a lot more can be done straight from the userspace without going for the expensive 0 ring barrier.
From the docs:
> Rather than running Linux binaries in a virtual machine, `starnix` creates a
_Linux runtime_ natively in Fuchsia. Specifically, Linux program can be wrapped
with a _component manifest_ that identifies `starnix` as the _runner_ for that
component. Rather than using the _ELF Runner_ directly, the binary for the
Linux program is given to `starnix` to run.
> In order to execute a given Linux binary, `starnix` manually creates a
`zx::process` with an initial memory layout that matches the Linux ABI. For
example, `starnix` populates `argv` and `environ` for the program as data
on the stack of the initial thread (along with the `aux` vector) rather than
as a message on the bootstrap channel, as this data is populated in the Fuchsia
System ABI.
More or less. As far as i know gVisor work with a host process that serves as a proxy for the os syscall and the child process dispatch the calls to the parent process through IPC which in turn execute it.
This is basically also how Chrome works, except that it serves otjer api's.
On Fuchsia, apparently the OS attach a binary which is a program on its own, to the binary that is executing and that in its "manifest" tell it will need a linux syscall proxy, which is this starnix that get stitched to the executable doing all calls in the same process.
On Fuchsia case this will end to be much more efficient because there will be no IPC communication involved just jumps on the code sector.
This is possible given they designed it in a micro-kernel like fashion, where things are more modular and a lot more can be done straight from the userspace without going for the expensive 0 ring barrier.
From the docs:
> Rather than running Linux binaries in a virtual machine, `starnix` creates a _Linux runtime_ natively in Fuchsia. Specifically, Linux program can be wrapped with a _component manifest_ that identifies `starnix` as the _runner_ for that component. Rather than using the _ELF Runner_ directly, the binary for the Linux program is given to `starnix` to run.
> In order to execute a given Linux binary, `starnix` manually creates a `zx::process` with an initial memory layout that matches the Linux ABI. For example, `starnix` populates `argv` and `environ` for the program as data on the stack of the initial thread (along with the `aux` vector) rather than as a message on the bootstrap channel, as this data is populated in the Fuchsia System ABI.