CloudABI
John Cowan
(14 Oct 2020 17:31 UTC)
|
Re: CloudABI
Arthur A. Gleckler
(14 Oct 2020 18:29 UTC)
|
CloudABI and its successor, WebAssembly WASI
Lassi Kortela
(15 Oct 2020 19:00 UTC)
|
Re: CloudABI and its successor, WebAssembly WASI
John Cowan
(16 Oct 2020 14:25 UTC)
|
Re: CloudABI and its successor, WebAssembly WASI Lassi Kortela (17 Oct 2020 09:12 UTC)
|
Re: CloudABI and its successor, WebAssembly WASI
John Cowan
(17 Oct 2020 15:53 UTC)
|
Re: CloudABI and its successor, WebAssembly WASI
Lassi Kortela
(17 Oct 2020 16:16 UTC)
|
Re: CloudABI and its successor, WebAssembly WASI
John Cowan
(17 Oct 2020 22:35 UTC)
|
Re: CloudABI and its successor, WebAssembly WASI
Lassi Kortela
(17 Oct 2020 23:26 UTC)
|
Re: CloudABI and its successor, WebAssembly WASI Lassi Kortela 17 Oct 2020 09:12 UTC
>> John, do you have a particular Scheme interface in mind? > If we converted the function calls to procedures, the > structs to record types, and the constants to constants, we'd have a > capability-security Scheme API for Posix systems. Then we could strip > down cloudlibc to remove the things that aren't relevant to CloudABI, > and then interface it to a Scheme using the Scheme's FFI. I believe sandboxing POSIX is only viable with support from the kernel so we should wait for that. OpenBSD's pledge() could probably be leveraged today to implement most of CloudABI with strict enforcement from the kernel. That would be an interesting project if anyone has the spare cycles to do it. Mini-Scheme and TinyScheme are easy to hack for purposes like this. Without kernel support, things look bleak for sandboxing of any kind. The JVM has had more holes than swiss cheese, for example. The kernel is the ultimate arbiter of virtual addressing and file system traversal so it has a real shot at enforcing boundaries; mimicking all that stuff in a virtual machine is very dodgy.