4 ms·

This is the most common misconception of our work. Please read the paper. WALI doesn't have to be exposed directly to programs, but can be used to implement a m

by titzer 3y ago

This is the most common misconception of our work. Please read the paper. WALI doesn't have to be exposed directly to programs, but can be used to implement a more restrictive sandbox as a Wasm module a layer above. For example, WASI can be implemented as a Wasm module and then other Wasm modules can only use the WASI module. Then any bugs or vulnerabilities in the WASI implementation are not engine-level exploits, but are sandboxed as any other Wasm module. This is a layering and security win across the board and does nothing to reduce the possibilities for more restrictive environments and APIs built on top. We're fans of WASI and see it as a the future of portable APIs. But it's a distant future, and WALI actually helps get us there and get more adoption for WASI by making it possible to implement WASI independent of the engine.

creshal 3y ago
You're speedrunning repeating every mistake Sun made with JVM sandboxing, congratulations.
- omnicognate 3y ago
  Can you expand on that? As written it's just a jeer.
- deleted 3y ago
  [deleted]
- titzer 3y ago
  This is a super unhelpful comment, but I'll respond. I worked on several JVM projects going back almost 20 years. No, we aren't. One principal sin the JVM made is that the JDK initially had no modular structure, and everything it needed to do natively was done in the JVM with native methods, because it had to be; the JVM was the only system with the privileges to do syscalls. As a result, the JDK was only really complete on about 2 VMs. With WALI, syscalls and all logic to implement higher-level APIs moves up, out of the engine. Engines can be complete and run an entire stack with no special support. If you could resist the urge for snarky, dismissive comments we could have a more productive discussion.
deleted 3y ago
[deleted]
mikewarot 3y ago
>Please read the paper. I quoted your paper. I'll take you at your word. I'd be quite happy to have a native Linux WASM / WASI host that's easy to configure and verify the configuration of. It should be as easy as picking a $5 bill from a wallet, to use in a transaction. You can see what you're doing... and examine it after it's out of your wallet, to double check. If you can see exactly what the command line you give it will hand out to the WASM code, and verify it for someone else's command line (before you actually run it)... that would be awesome. WALI xxx - to actually run it WALI --showcaps xxx - to get an output of the files, folders, network addresses, etc. it would allow access to, as a text list If WALI gets exposed directly to the WASM code, then the benefits of WASM are lost, in my opinion.

by titzer 3y ago

creshal 3y ago

You're speedrunning repeating every mistake Sun made with JVM sandboxing, congratulations.

omnicognate 3y ago
Can you expand on that? As written it's just a jeer.
deleted 3y ago
[deleted]
titzer 3y ago
This is a super unhelpful comment, but I'll respond. I worked on several JVM projects going back almost 20 years. No, we aren't. One principal sin the JVM made is that the JDK initially had no modular structure, and everything it needed to do natively was done in the JVM with native methods, because it had to be; the JVM was the only system with the privileges to do syscalls. As a result, the JDK was only really complete on about 2 VMs. With WALI, syscalls and all logic to implement higher-level APIs moves up, out of the engine. Engines can be complete and run an entire stack with no special support. If you could resist the urge for snarky, dismissive comments we could have a more productive discussion.

deleted 3y ago

[deleted]

mikewarot 3y ago

>Please read the paper. I quoted your paper. I'll take you at your word. I'd be quite happy to have a native Linux WASM / WASI host that's easy to configure and verify the configuration of. It should be as easy as picking a $5 bill from a wallet, to use in a transaction. You can see what you're doing... and examine it after it's out of your wallet, to double check. If you can see exactly what the command line you give it will hand out to the WASM code, and verify it for someone else's command line (before you actually run it)... that would be awesome. WALI xxx - to actually run it WALI --showcaps xxx - to get an output of the files, folders, network addresses, etc. it would allow access to, as a text list If WALI gets exposed directly to the WASM code, then the benefits of WASM are lost, in my opinion.