3 ms·

> By compiling to wasm we sandbox the code, preventing it from accessing anything on the outside. Operating systems are in a sad state, as virtual address spac

> By compiling to wasm we sandbox the code, preventing it from accessing anything on the outside. Operating systems are in a sad state, as virtual address spaces already offer exactly that in hardware at full speed. It's only through the operating system APIs that processes gain the ability to affect anything outside of the process. Current operating systems weren't made with untrusted code in mind, but have so much inertia that new operating systems repairing old misfeatures can never succeed. All code is already written based on the bad Operating System APIs like for writing files. This project just handwaves the actual problem away: > the sandboxed code can’t do anything but pure computation, unless you give it a function to call to do things like read from a file, tell the time, etc.

sanxiyn 6y ago
CloudABI is an attempt to solve this the right way: http://cloudabi.org/ http://cloudabi.org/
darksaints 6y ago
100% agreement. With a kernel design like SeL4 there is no need for crazy sandboxing environments. It prevents you from accessing external resources by default. And it is probably as close as we can feasibly get to an operating system that is impossible to maliciously root.
titzer 6y ago
> as virtual address spaces already offer exactly that in hardware at full speed Operating system processors are pretty heavyweight, and there are lots of situations where smaller granularity protection domains are useful. I'd also quibble with "at full speed." There is a metric shitton of complexity to implement virtual memory, with multi-level TLBs, an extremely careful dance with the operating system currently, IPIs for TLB shootdown, etc. The dynamic cost of the TLB is something that is measurable, and of course, completely depends on your application behavior, kernel, availability of huge pages, etc. The reality is that we don't really have a control group for hardware without virtual memory because the only such chips are for small embedded (niche) systems, and everything else runs on kernels designed to offer virtual memory to software expecting virtual memory.
james412 6y ago
> Operating systems are in a sad state, as virtual address spaces already offer exactly that in hardware at full speed Ever since reading about Microsoft Singularity all that time ago, I reached the opposite conclusion: software is in such a sad state that it must rely on hardware to provide isolation. From this perspective, WasmBoxC and many projects like it are IMO a huge step in a desirable direction. The main lesson from Singularity for me (aside from requirements for memory safety) was that cross-component safety can be achieved by formalizing the protocols those components use to communicate. Sing# had a dedicated type to capture the state machine for every cross-component transaction, with strongly typed inputs and outputs. This problem is not unique to software isolation -- it is the basis for a huge variety of security problems everywhere across the ecosystem, not least network services Wouldn't it be a wonderful world if we knew our application was fully safe when exposed to a network for the same reason we know it is fully safe to run in the same address space as another untrusted application? That is that path Singularity took us along
- pjmlp 6y ago
  Example of such sad state of affairs, Android 11 is adding support for hardware memory tagging, as static analysis alone is not enough to tame the C and C++ components. https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... iOS, Solaris on SPARC are on this path as well. Regarding Singularity, we are slowly moving away from C on non pure UNIX clones, but still it will take generations.

sanxiyn 6y ago

CloudABI is an attempt to solve this the right way: http://cloudabi.org/ http://cloudabi.org/

darksaints 6y ago

100% agreement. With a kernel design like SeL4 there is no need for crazy sandboxing environments. It prevents you from accessing external resources by default. And it is probably as close as we can feasibly get to an operating system that is impossible to maliciously root.

titzer 6y ago

> as virtual address spaces already offer exactly that in hardware at full speed Operating system processors are pretty heavyweight, and there are lots of situations where smaller granularity protection domains are useful. I'd also quibble with "at full speed." There is a metric shitton of complexity to implement virtual memory, with multi-level TLBs, an extremely careful dance with the operating system currently, IPIs for TLB shootdown, etc. The dynamic cost of the TLB is something that is measurable, and of course, completely depends on your application behavior, kernel, availability of huge pages, etc. The reality is that we don't really have a control group for hardware without virtual memory because the only such chips are for small embedded (niche) systems, and everything else runs on kernels designed to offer virtual memory to software expecting virtual memory.

james412 6y ago

> Operating systems are in a sad state, as virtual address spaces already offer exactly that in hardware at full speed Ever since reading about Microsoft Singularity all that time ago, I reached the opposite conclusion: software is in such a sad state that it must rely on hardware to provide isolation. From this perspective, WasmBoxC and many projects like it are IMO a huge step in a desirable direction. The main lesson from Singularity for me (aside from requirements for memory safety) was that cross-component safety can be achieved by formalizing the protocols those components use to communicate. Sing# had a dedicated type to capture the state machine for every cross-component transaction, with strongly typed inputs and outputs. This problem is not unique to software isolation -- it is the basis for a huge variety of security problems everywhere across the ecosystem, not least network services Wouldn't it be a wonderful world if we knew our application was fully safe when exposed to a network for the same reason we know it is fully safe to run in the same address space as another untrusted application? That is that path Singularity took us along

pjmlp 6y ago
Example of such sad state of affairs, Android 11 is adding support for hardware memory tagging, as static analysis alone is not enough to tame the C and C++ components. https://source.android.com/devices/tech/debug/tagged-pointers https://source.android.com/devices/tech/debug/tagged-pointer... iOS, Solaris on SPARC are on this path as well. Regarding Singularity, we are slowly moving away from C on non pure UNIX clones, but still it will take generations.