gvisor - google user-space kernel in go

[Geraldo Netto]

Dear Friends,

A while ago, Google has released gVisor [1]:
"gVisor is a user-space 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. The
runsc runtime integrates with Docker and Kubernetes, making it simple
to run sandboxed containers.

gVisor takes a distinct approach to container sandboxing and makes a
different set of technical trade-offs compared to existing sandbox
technologies, thus providing new tools and ideas for the container
security landscape.

gVisor intercepts all system calls made by the application, and does
the necessary work to service them. Importantly, gVisor does not
simply redirect application system calls through to the host kernel.
Instead, gVisor implements most kernel primitives (signals, file
systems, futexes, pipes, mm, etc.) and has complete system call
handlers built on top of these primitives.

Since gVisor is itself a user-space application, it will make some
host system calls to support its operation, but much like a VMM, it
will not allow the application to directly control the system calls it
makes."

Maybe, it might be interesting to write down a comparison of OSv and gVisor
and possibly, bring some ideas from them
eg: check which syscalls are implemented (I suppose they have done
some study to define which syscalls are more important) [2]

[1] https://github.com/google/gvisor
[2] https://github.com/google/gvisor/tree/master/pkg/abi/linux


Kind Regards,

Geraldo Netto
Sapere Aude => Non dvcor, dvco
http://exdev.sf.net/

[Waldek Kozaczuk]

Couple of days ago I attended a presentation by one of the Google engineers at QCon Ny. It did not give that much more insights then official docs but here are couple of bullet points worth pointing:

• 150 ms startup time (not sure from from point) and 15MB of memory usage
• implements 211 Linux syscalls
• listed number of apps working on which suggests not all apps are going to work on gVisor
• claim to run unmodified Linux executable like OSv does
• gVisor is not simple passthrough but rather implements and emulates the syscalls its own way
• written in Golang which has garbage collection (which may have some performance implications -> my takeaway)
• made of 2 components: sentry that emulates syscalls and implements network access and gofer for file access 
• gVisor is not for "syscall heavy applications" (mentions syscall handling has some overhead)

[Qixuan Wu]

• claim to run unmodified Linux executable like OSv does

gVisor can run the C application without recompiling, but application only can run on OSv with recompiling. 

在 2018年7月2日星期一 UTC+8上午2:38:48，Waldek Kozaczuk写道：

[Pekka Enberg]

On Wed, Sep 19, 2018 at 4:18 AM, Qixuan Wu <wuqi...@gmail.com> wrote:

• claim to run unmodified Linux executable like OSv does

gVisor can run the C application without recompiling, but application only can run on OSv with recompiling. 

OSv is quite capable of running unmodified Linux executables, as long as they use the subset of Linux ABI OSv actually supports (IOW, no fork(), for example).

- Pekka

[Qixuan Wu]

在 2018年9月19日星期三 UTC+8下午9:25:15，Pekka Enberg写道：

But application need to be recompiled on OSv, it's better to support to be without recompiling. 

Thanks & Regards

Qixuan

[Pekka Enberg]

No, OSv does _not_ require applications to be recompiled. What makes you think it does?

OSv implements a subset of the Linux system call ABI and has a built-in ELF loader and linker. This allows OSv to run *unmodified* Linux binaries. Of course, if your application uses parts of the Linux ABI that are not supported, such as fork, they will not run very long. But OSv is capable of running unmodified Linux binaries for applications that restrict themselves to the subset of the ABI that OSv supports.

- Pekka

[Nadav Har'El]

On Thu, Sep 20, 2018 at 10:06 AM, Pekka Enberg <pen...@scylladb.com> wrote:

On Thu, Sep 20, 2018 at 9:29 AM, Qixuan Wu <wuqi...@gmail.com> wrote:

在 2018年9月19日星期三 UTC+8下午9:25:15，Pekka Enberg写道：

On Wed, Sep 19, 2018 at 4:18 AM, Qixuan Wu <wuqi...@gmail.com> wrote:

• claim to run unmodified Linux executable like OSv does

gVisor can run the C application without recompiling, but application only can run on OSv with recompiling. 

OSv is quite capable of running unmodified Linux executables, as long as they use the subset of Linux ABI OSv actually supports (IOW, no fork(), for example).

But application need to be recompiled on OSv, it's better to support to be without recompiling. 

No, OSv does _not_ require applications to be recompiled. What makes you think it does?

OSv implements a subset of the Linux system call ABI and has a built-in ELF loader and linker. This allows OSv to run *unmodified* Linux binaries.

I think Qixuan may be referring to the fact that OSv today can only run position-independent executables (shared objects and PIE), and nor "regular" position-dependent executables,

which causes us in many applications in apps/ to modify the Makefile to add "-shared", "-pie", or something like that, requiring recompilation.

However, Qixuan, the interesting thing to note that an application that already has been compiled as shared object or PIE, can often run on OSv completely unmodified.

Shared objects are particularly common in case of runtime environments, such as Java or Python, where even on Linux, the majority of the code is a shared object, which we can copy as-is into OSv without any recompilation, and there is just a 20-line front-end executable which, perhaps, needs to be recompiled (this is exactly our situation with Java and Python).

Shared objects are also common, of course, as shared libraries. So even if you do need to recompile part of your code, you most certainly don't need to recompile the dozen shared libraries your code needs and you can just copy as-is into the OSv image, which saves a huge amount of porting work.

PIE instead of classic position-dependent executables are becoming popular on some Linux distributions because of their security benefits, so if you find one, you can try running it on OSv unmodified. Note, however, that there are some open bugs which may prevent them from working correctly: https://github.com/cloudius-systems/osv/issues/689, https://github.com/cloudius-systems/osv/issues/352

Finally, there is no real reason why OSv shouldn't be able to run *one* position-dependent Linux executable. It will just need some more coding. There's an open issue about it:

https://github.com/cloudius-systems/osv/issues/190

 

Of course, if your application uses parts of the Linux ABI that are not supported, such as fork, they will not run very long. But OSv is capable of running unmodified Linux binaries for applications that restrict themselves to the subset of the ABI that OSv supports.

- Pekka

--
You received this message because you are subscribed to the Google Groups "OSv Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pekka Enberg]

Hi Nadav,

On Thu, Sep 20, 2018 at 11:03 AM, Nadav Har'El <n...@scylladb.com> wrote:

I think Qixuan may be referring to the fact that OSv today can only run position-independent executables (shared objects and PIE), and nor "regular" position-dependent executables,

which causes us in many applications in apps/ to modify the Makefile to add "-shared", "-pie", or something like that, requiring recompilation.

Right, makes sense. But I think the point still stands, there's no actual requirement of *compilation*, just making sure the executable is position-independent.

- Pekka 

[Qixuan Wu]

在 2018年9月20日星期四 UTC+8下午4:03:45，Nadav Har'El写道：

On Thu, Sep 20, 2018 at 10:06 AM, Pekka Enberg <pen...@scylladb.com> wrote:

On Thu, Sep 20, 2018 at 9:29 AM, Qixuan Wu <wuqi...@gmail.com> wrote:

在 2018年9月19日星期三 UTC+8下午9:25:15，Pekka Enberg写道：

On Wed, Sep 19, 2018 at 4:18 AM, Qixuan Wu <wuqi...@gmail.com> wrote:

• claim to run unmodified Linux executable like OSv does

gVisor can run the C application without recompiling, but application only can run on OSv with recompiling. 

OSv is quite capable of running unmodified Linux executables, as long as they use the subset of Linux ABI OSv actually supports (IOW, no fork(), for example).

But application need to be recompiled on OSv, it's better to support to be without recompiling. 

No, OSv does _not_ require applications to be recompiled. What makes you think it does?

OSv implements a subset of the Linux system call ABI and has a built-in ELF loader and linker. This allows OSv to run *unmodified* Linux binaries.

I think Qixuan may be referring to the fact that OSv today can only run position-independent executables (shared objects and PIE), and nor "regular" position-dependent executables,

which causes us in many applications in apps/ to modify the Makefile to add "-shared", "-pie", or something like that, requiring recompilation.

However, Qixuan, the interesting thing to note that an application that already has been compiled as shared object or PIE, can often run on OSv completely unmodified.

Shared objects are particularly common in case of runtime environments, such as Java or Python, where even on Linux, the majority of the code is a shared object, which we can copy as-is into OSv without any recompilation, and there is just a 20-line front-end executable which, perhaps, needs to be recompiled (this is exactly our situation with Java and Python).

Shared objects are also common, of course, as shared libraries. So even if you do need to recompile part of your code, you most certainly don't need to recompile the dozen shared libraries your code needs and you can just copy as-is into the OSv image, which saves a huge amount of porting work.

PIE instead of classic position-dependent executables are becoming popular on some Linux distributions because of their security benefits, so if you find one, you can try running it on OSv unmodified. Note, however, that there are some open bugs which may prevent them from working correctly: https://github.com/cloudius-systems/osv/issues/689, https://github.com/cloudius-systems/osv/issues/352

Finally, there is no real reason why OSv shouldn't be able to run *one* position-dependent Linux executable. It will just need some more coding. There's an open issue about it:

https://github.com/cloudius-systems/osv/issues/190

 

Yes, correct, what I mean is that classic position-dependent executables need to be recompiled as https://github.com/cloudius-systems/osv/issues/190 said.