You need a few syscalls: to grow your heap size (brk) or to exit your program (exit). I took a quick look at their code and here are the syscalls and arguments implemented: https://github.com/varnish/tinykvm/blob/master/src/functions...

It’s a bit more than running a program under seccomp strict mode, but conceptually similar, so running anything too complicated likely won't work. You certainly won’t be able to sandbox chromium for taking website snapshots for example.

There's many ways to go about it, but essentially yes, brk and mmap and a few others just to get into main() for some common run-times.

But you can do whatever you want. For example in libriscv I override the global allocator in my guest programs to use a host-managed heap. That way heap usage has native performance in interpreter mode, while also allowing me full control of the heap from the outside. I wrote about this here: https://medium.com/@fwsgonzo/using-c-as-a-scripting-language...

Well, yes, there's a few system calls like `brk()`/`sbrk()`/`getrandom()`, and what not. But you don't get to open any files or sockets or devices.

For the Varnish integration I added permission-based access to local files. Network stuff can be accessed through custom APIs. A simple fetch(url, options)-like system call. Just have a look at the VMOD repository. It's something I'd like to move into TinyKVM when I feel like it.

What do you mean by I/O exactly? Because to me handling HTTP requests definitely requires I/O, no matter how you technically implement it. Does the program start anew with new arguments for each HTTP request, and if so how is that an improvement over I/O syscalls?

Handling HTTP requests can be done entirely via stdin + stdout. But it won't be too useful if you could not even talk to a database.

The VM may (and should) be limited to a small subset of what's available on the host though.

But in order to read from stdin and write to stdout, you must make I/O syscalls.

I mean you don't get to open files, sockets, devices, etc. in the sandboxed program. You get to do just a few minimal things like I/O on stdin/stdout/stderr, use shared memory, maybe allocate memory.

So how do you do I/O on stdin/stdiout/stderr without syscalls?

There's a tiny kernel, and there are syscalls, because after all the executable is -though ELF- a statically linked executable with a statically linked libc, but that mini kernel only handles very few system calls, and does not provide the full generality of Linux. Yes I shouldn't have said "there's no syscalls", just no generic I/O.