[9fans] gVisor - user space kernel in Go

[9fans] gVisor - user space kernel in Go

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 127 bytes --]

Just saw this today; might be of interest to some 9fans. Apache open source
from Google:

https://github.com/google/gvisor

[-- Attachment #2: Type: text/html, Size: 250 bytes --]

Re: [9fans] gVisor - user space kernel in Go

[yy]

Maybe one of the most interesting aspects is that it includes a
9P2000.L implementation:

https://github.com/google/gvisor/tree/master/pkg/p9

On 2 May 2018 at 21:19, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> Just saw this today; might be of interest to some 9fans. Apache open source
> from Google:
>
> https://github.com/google/gvisor
>
>



--
- yiyus || JGL .

Re: [9fans] gVisor - user space kernel in Go

[hiro]

agreed. perhaps there are more gems :)

Re: [9fans] gVisor - user space kernel in Go

[Aram Hăvărneanu]

Looks pretty portable, the only Linux-specific things seem to be
non-essential sandboxing stuff, e.g. seccomp, and the only
Unix-specific dependency is on ptrace. Should not be too hard to make
it into linuxemu on Plan 9.

-- 
Aram Hăvărneanu

Re: [9fans] gVisor - user space kernel in Go

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

Thanks!  I was hoping to get confirmation of this.  I had a similar thought
based on my layman's understanding of it.


On Thu, May 3, 2018 at 10:55 AM Aram Hăvărneanu <aram.h@mgk.ro> wrote:

> Looks pretty portable, the only Linux-specific things seem to be
> non-essential sandboxing stuff, e.g. seccomp, and the only
> Unix-specific dependency is on ptrace. Should not be too hard to make
> it into linuxemu on Plan 9.
>
> --
> Aram Hăvărneanu
>
>

[-- Attachment #2: Type: text/html, Size: 735 bytes --]

Re: [9fans] gVisor - user space kernel in Go

[Bakul Shah]

On Wed, 02 May 2018 19:19:43 -0000 Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> 
> Just saw this today; might be of interest to some 9fans. Apache open source
> from Google:
> 
> https://github.com/google/gvisor

Unix emulation on microkernels looks a bit like this.

Quick comparison:

jails   each jail has its own kernel context.  The host kernel
	needs support for this. Apps run unchanged.

	containers & zones are variations on this.

VMs	a proxy emulates a processor and assorted IO devices.
	very fast if the host and guest instruction sets are
	very similar. The host doesn't know about emulation
	or care. Apps run unchanged.

gvisor  a proxy emulates an OS API by intercepting all
	syscalls.  Very few host facilities are needed.
	Apps may have to be linked with the right library.

In a capabilities based system you don't need most of this and
can still achieve better security and isolation.  What a
process can access is constrained by the capabilities it holds
or can gain via calls on existing caps. API interception as
with gvisor can be done naturally: a process would be given
proxy caps to start with.

plan9 more or less used file descriptors in this fashion.  It
also provided better higher level composition by attempting to
cast many things as files/dirs/filesystems.  Even here I think
a cap system can be used to build better &/or more convenient
abstractions.