> gVisor is an application kernel, written in Go, that implements a substantial portion of the Linux system surface. It includes an Open Container Initiative (OCI) runtime called runsc that provides an isolation boundary between the application and the host kernel.
WSL – both versions – are MS attempting its age-old "embrace & extend" move.
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
I called it a distant relative of the NT POSIX environment and some senior MS bod disagreed and – when I said [[citation needed]] – eventually linked to a bunch of videos and stuff that say that WSL1 is a whole new translation layer and not a kernel personality at all.
Which makes me wonder: why? Do MS not have enough top-flight kernel engineers any more to do an in-kernel version of gvisor? https://github.com/google/gvisor
Others have done it.
Joyent enhanced the old Solaris `lxrun` environment to bring it to 64-bit and kernel 3.x or even 4.x: https://www.slideshare.net/bcantrill/illumos-lx
The FreeBSD Linuxulator does much the same: https://wiki.freebsd.org/Linuxulator
https://www.f-secure.com/en/consulting/foundry/usb-armory
As does Google,
https://github.com/google/gvisor
https://github.com/google/gapid
Naturally if one is talking about specific uses cases like IoT with a couple of KBs, MISRA-C, or UNIX kernels, then yes Go is not a competitor.
Poignantly, the naive approach of 'let's just block read(2) to prevent file access' doesn't work - there's multiple ways to bypass simple read(2) filtering like this. The easiest that come to mind are:
- using readv(2)
- using sendfile(2)
- sym/hardlinks to bypass path checks, and the inherent TOCTOU exploits of further naive checks
Not to mention typical newbie mistakes that this project makes: not following forks, not checking for 32-bit syscalls, etc.
gVisor [1] does this well - instead of filtering, it reimplements the logic for handling Linux syscalls in userspace (eg., is actually responsible for handing out FDs and other handles, presenting the filesystem to the user, etc).