Full libc in sandboxes with syscalls proxied by the system object

[davidchisnall]

Once #22 has split the syscall layer out of libc, we should have a replacement syscall layer that proxies out to the system object. Ideally, the kernel would permit a subset of system calls directly (ideally the same ones as capsicum, but that would depend on some mechanism for delegating file descriptors so that should wait for a second cut).

[davidchisnall]

27 is related to this, though the two parts (syscalls proxied to system object, fast path for in-sandbox use) are largely orthogonal.

[brooksdavis]

Thinking aloud about the best way to do this while waiting for builds.

Due to the fact that Unix declares syscalls in a vast array of random headers, I think that in the short term we'll want a libcheri_syscalls library we can link into sandbox objects that calls the actual system object methods. I think we can easily generate those methods from syscalls.master with some special handling of varidac functions.

[davidchisnall]

That sounds sensible, though #156 is also closely related, as we'll likely want to have different system call policies for different sandboxes and so need them to use different system objects.

[davidchisnall]

We're not currently using this in the eval (though it would be nice to), but other JNI sandboxing techniques use it so we probably need it to claim to support a superset of their functionality.

[brooksdavis]

We can now link libcheri_syscalls with a libc_cheri linked sandbox and proxy nearly all system calls (the exception being abort2(), sys_exit(), and some sctp syscalls. I'll take a stab at switching to a real libc in the coming week.

cc: @kgudka

[brooksdavis]

Actually shoehorning libc into a sandbox is going to require more work in the form of ripping out jemalloc again or writing a fancier mmap() shim that lets us run a native jemalloc (with a few more tweaks) in a sandbox. Given that the current set of allowed system calls is clearly too much, I'm going to take a look at #156 and think on this a bit more before jumping in.

[davidchisnall]

With the current model, I think it would be fine to have jemalloc initially allocated a heap region and not be allowed to grow it - later (post-paper-deadline) we're going to want to add support for enumerating all of the regions of memory owned by a sandbox, but initially I think that it's fine to expect malloc to return NULL if the user tries to allocate more memory than libcheri allocated for the sandbox heap.

[brooksdavis]

Given current compartmentalization directions I don't see this happening any time soon.

[davidchisnall]

Please can we keep this open? We will need either this or some equivalent for some of our planned Morello work.

[rwatson]

Please can we keep this open? We will need either this or some equivalent for some of our planned Morello work.

I think what we might want to do is create a new issue (or working document) talking about the requirements for linker-based compartmentalisation and system access. It think we are pretty close to starting on the rtld bits of that story (@arichardson), on top of which we’ll want to rest one or more compartmentalisation models. It’s not yet clear that the current libcheri will be a starting point for that, so much as a repository of ideas and perhaps a bit of code if need be.