This is historically the kind of thing that people think is very cool and important, but has turned out to not matter at all. "Languages matter" must be the biggest enduring fallacy of computer programming. It has an obvious corollary in believing processor architectures are important.
The Bytecode Alliance: Building a secure, composable future for WebAssembly
81–90 of 265 posts
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#82I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions. Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes. Today, if you want to be extens…
So, like, Java?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#83Earlier quoted context omitted.
no ability to exfiltrate data As we've learned with things like rowhammer and Spectre, this is a very high bar. How does this initiative plan to deal with side-channel attacks?
This is discussed in the blog post; see the discussion of "time protection".
If you're just reading hn comments:
"There is unfortunately one less straightforward way that attackers can access another module’s memory—side-channel attacks like Spectre. OS processes attempt to provide something called time protection, and this helps protect against these attacks. Unfortunately, CPUs and OSes don’t offer finer-than-process granularity time protection features."
"[snip] Making a shift to nanoprocesses here would take careful analysis."
"But there are lots of situations where timing protection isn’t needed, or where people aren’t using processes at all right now. These are good candidates for nanoprocesses."
"Plus, as CPUs evolve to provide cheaper time protection features, WebAssembly nanoprocesses will be in a good position to quickly take advantage of these features, at which point you won’t need to use OS processes for this."
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#84I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions. Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes. Today, if you want to be extens…
So, like, Java?
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#85One of my next projects is to create a Tcl package for webassembly that will let other extension authors compile their packages targeting WebAssembly and be able to use those compiled binaries on any platform.
That sounds great! I'd love to hear more about that. Are you looking to support extension of Tcl with WebAssembly, or using Tcl inside WebAssembly? I think wasmtime would likely be a good fit for your use case; you could either use the wasmtime C API, or use Rust to bind to Tcl and to the wasmtime-api Rust crate. I've found it quite easy to embed wasmtime and run a simple WebAssembly module. See https://github.com/by…
This is going to be a Tcl extension named "webassembly" that then allows you to load other Tcl extensions that are compiled to WebAssembly.
Right now Tcl loads binary extensions using the "load" command, this will load a shared object (.so, .dylib, .shlib, .dll, .a, whatever your OS supports for runtime loading) and call _Init.
My plan is to create a new command named "webassembly::load" that will open a WebAssembly module and provide ... some way ... to call _Init as well as some way for the extension to make calls back the ~200 Tcl API functions and some selected other APIs per platform (Solaris, AIX, FreeBSD, Linux, Windows, macOS, HP-UX, etc).
Additionally, a mechanism (probably in the form of an SDK) for Tcl Extension maintainers to compile their extension targeting being loaded by "webassembly::load" with the APIs mentioned above being available. Most Tcl extensions right now are written in C or C++.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#86I'm one of the folks working with the Alliance, and I'm incredibly excited about WebAssembly outside the browser. Happy to answer questions. Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data. Imagine supporting a safe plugin API that isn't just for C and languages that FFI to C, but works natively with safe datatypes. Today, if you want to be extens…
So, like, Java?
> Imagine extensions for applications or databases, written in any language you want, with no ability to exfiltrate data
How does Java preclude plugins exfiltrating data?
Downvoters: I’m not trying to be sacrilegious; I genuinely don’t know the answer.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#87Real worried when I see phrases like "secure by default" that this will involve some sort of security certificate or formal verification process which a government or other malicious actor can use as a weapon against its enemies. Is the security limited to sandboxing of the code itself or is there some sort of verification process involved?
The security here is based on sandboxing code and providing limited capabilities. If you're embedding wasm, you choose what capabilities to give the sandbox. For instance, if a game wants to support mods via wasm, it could give the mods APIs to the game world but not to the network or filesystem. A database plugin might have access to interpret a database object handed to it but not exfiltrate data over the network.…
It's not like what you propose hasn't been tried before. The main practical issue that I don't see this post address, is the combinatorial explosion that stems from fine-grained sandboxing of any complex application. There are bound to be executable paths through the state space that both pass initial muster and can be used by an attacker to craft a sandbox bypass.
In other words, finegrained sandboxing does not solve the problem. It may be an improvement on the current -dismal- state of affairs as far as ecosystems like pypi or NPM are concerned, but I don't see how it addresses the main issues in any sort of practical, real-world environment.
Something that definitely works is that which security-conscious orgs/teams/persons currently do: ownership and curation.
Ownership implies minimization of 3rd party dependencies.
Curation implies strict quality (incl security) reviews and relentless culling of code that fails them.
The distributed engineering model that you advocate for where code is being pulled-in from hundreds of disparate sources outside of one's control is _fundamentally broken_.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#88In my opinion this is a fascinating approach, and it may end up transforming our industry. But the main question I've had is how big the overhead is, specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. Compared to regular static or even dynamic linking, that may be a noticeable slowdown.
> specifically since modules don't share their wasm Memory. That means data will be constantly copied between them. We're working on that. We want to make it possible for modules to share memory in a controlled way, without giving access to their entire address space.
Shared memory can certainly do this. Even separate processes can use shared memory to communicate lock free using atomics.
Other than that, I wonder if nested page tables that are normally used for virtualization can be used to separate address spaces within a process.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#89Earlier quoted context omitted.
That sounds great! I'd love to hear more about that. Are you looking to support extension of Tcl with WebAssembly, or using Tcl inside WebAssembly? I think wasmtime would likely be a good fit for your use case; you could either use the wasmtime C API, or use Rust to bind to Tcl and to the wasmtime-api Rust crate. I've found it quite easy to embed wasmtime and run a simple WebAssembly module. See https://github.com/by…
This is going to be a Tcl extension named "webassembly" that then allows you to load other Tcl extensions that are compiled to WebAssembly. Right now Tcl loads binary extensions using the "load" command, this will load a shared object (.so, .dylib, .shlib, .dll, .a, whatever your OS supports for runtime loading) and call _Init. My plan is to create a new command named "webassembly::load" that will open a WebAssembly…
Makes perfect sense. I look forward to seeing your work when it's ready! Please feel free to ask if there's anything we can do to help, or if you run into any areas where the APIs could be easier to use.
You may find the witx project (https://github.com/WebAssembly/WASI/tree/master/tools/witx) useful when writing the bindings from WebAssembly to the Tcl APIs.
Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly
#90Real worried when I see phrases like "secure by default" that this will involve some sort of security certificate or formal verification process which a government or other malicious actor can use as a weapon against its enemies. Is the security limited to sandboxing of the code itself or is there some sort of verification process involved?
The security here is based on sandboxing code and providing limited capabilities. If you're embedding wasm, you choose what capabilities to give the sandbox. For instance, if a game wants to support mods via wasm, it could give the mods APIs to the game world but not to the network or filesystem. A database plugin might have access to interpret a database object handed to it but not exfiltrate data over the network.…
> For instance, if a game wants to support mods via wasm, it could give the mods APIs to the game world but not to the network or filesystem.
This is, IMO, pretty huge. I'm building a game right now that supports clientside NodeJS mods, and figuring out sandboxing has been a huge pain. Similarly, I've been trying to figure out how to sandbox some of our dependencies at work and in personal projects.
I want to be able to let someone mod my games in any language, and distribute them however they want, while still providing guarantees to my users that the worst a mod can possibly do is maybe freeze your computer or something.
So much of the problems the OP describes ring true to me; it's a very exciting project.