gvisor syscalls list

147 views
Skip to first unread message

Gabriele Minì

unread,
Nov 15, 2020, 10:02:12 AM11/15/20
to gVisor Users [Public]
Hello everyone,
I hope to be in the right place to ask questions.

I'm actually benchmarking the runsc performance by training a M.L model (only by means of CPU). Whats I see is that we have a little overhead with runsc with respect to runc.

I would like to know if it is possible to have the list of all the system calls that are actually handled in user space by Sentry and the ones that are directly executed on the host. It is reasonable to say that this overhead is due to the syscalls handling in user space?

thanks everyone for your help.

Bhasker Hariharan

unread,
Nov 15, 2020, 12:03:05 PM11/15/20
to Gabriele Minì, gVisor Users [Public]


On Sun, Nov 15, 2020, 7:02 AM Gabriele Minì <mini.ga...@gmail.com> wrote:
Hello everyone,
I hope to be in the right place to ask questions.

I'm actually benchmarking the runsc performance by training a M.L model (only by means of CPU). Whats I see is that we have a little overhead with runsc with respect to runc.
Coule you quantify the overhead? Also note I ha e noticed that with ML workloads that they can be pretty memory intensive. In such cases one thing that improved performance as force enabling transparent  huge pages to reduce the memory allocation overheads.

I would like to know if it is possible to have the list of all the system calls that are actually handled in user space by Sentry and the ones that are directly executed on the host. It is reasonable to say that this overhead is due to the syscalls handling in user space?

The syscalls gVisor handles can be seen here. 


GVisor does not pass through any syscalls to the host. All supported syscalls are either handled by the sentry or return ENOSYS if not supported.

-bhasker
thanks everyone for your help.

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/3e6971d9-5f79-45c2-ab29-56097f575305n%40googlegroups.com.

Gabriele Minì

unread,
Nov 15, 2020, 12:16:48 PM11/15/20
to gVisor Users [Public]
Thank you for your reply.

Coule you quantify the overhead? 
The overhead I got is 167 seconds when compared to runc. Actually I'm performing this tests on my laptop just for personal purpose, this can be for sure reduced with suitable hw.

GVisor does not pass through any syscalls to the host.
Sorry to bother you with another question but actually I'm not understanding how your answer relates with this:

"So, of the 350 syscalls in the Linux kernel, the Sentry needs to implement only 237 of them to support containers. At most, the Sentry only needs to call 68 of the host Linux syscalls. In other words, with gVisor, applications get the vast majority (and growing) functionality of Linux containers for only 68 possible syscalls to the Host OS. 350 syscalls to 68 is attack surface reduction."  taken from link.

Thank you for your time!

Ayush Ranjan

unread,
Nov 15, 2020, 1:03:03 PM11/15/20
to Gabriele Minì, gVisor Users [Public]
So, of the 350 syscalls in the Linux kernel, the Sentry needs to implement only 237 of them to support containers. At most, the Sentry only needs to call 68 of the host Linux syscalls. In other words, with gVisor, applications get the vast majority (and growing) functionality of Linux containers for only 68 possible syscalls to the Host OS. 350 syscalls to 68 is attack surface reduction.
Any syscall made by the application is intercepted by the sentry. The sentry tries to process the syscall. If the syscall is not supported, ENOSYS is returned. If it is supported then the sentry has internal mechanisms to handle the system call. In handling the syscall, the sentry might have to make syscalls to the host. The number of these syscalls that the sentry makes to the host is only 68. Please note that the sentry does not "pass through" any syscall made by the application to the host directly (I think this is what Bhasker was talking about). In effect, the host only experiences at most 68 syscalls even though the application would be making more (upto 237 syscalls supported). This reduction is possible because a lot is handled by the sentry.



--
Ayush Ranjan
Software Engineer | Google Cloud

Gabriele Minì

unread,
Nov 15, 2020, 1:09:40 PM11/15/20
to gVisor Users [Public]
Thank you Ayush Ranjan and Bhasker Hariharan. Now it is clear.

Ian Lewis

unread,
Nov 16, 2020, 2:21:54 AM11/16/20
to Gabriele Minì, gVisor Users [Public]
Hi Gabriele,

Just to add to what Ayush and Bhasker said, yes, all syscalls are intercepted and handled by gVisor. gVisor uses some syscalls on the host for the implementation but none are passed through directly.

We don't have any docs on the syscalls used by gVisor on the host. This list is a bit dynamic based on what options you use (host networking enables more syscalls on the host for example).

We do have docs for syscalls supported by the gVisor sentry for applications running inside the sandbox. The docs describe the error messages that the Sentry will return (it may not always be ENOSYS).
These docs are automatically generated from source so they should be up to date.

In terms of performance, overhead in gVisor could be a number of things. Your workload does not sound syscall heavy so I would guess most differences between gVisor and the host might be I/O related (network or file system) or have some other cause. I think we would need a bit more info to know for sure.

Hope that helps!
Ian



--

Ian Lewis | Developer Advocate | ianl...@google.com | +81 (03)4540-2465

Reply all
Reply to author
Forward
0 new messages