Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bytecode Alliance: Building a secure, composable future for WebAssembly

hacks.mozilla.org

Post reply on HN
Print view View original

151–160 of 265 posts

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#151

Post by AgentME »

pjmlp wrote: post #130
AgentME wrote: post #108

Earlier quoted context omitted.

The cross-language interoperability of WebAssembly seems practically like a happy side-effect of its design; I don't think it would look much differently at present if it had originally been built to target only C (in a sandboxable way). Most of the article still applies even if you ignore other language support. The first priority for WebAssembly seems to be making things strongly sandboxed.

Actually it fails to properly sandbox C derived languages versus what hardware memory tagging like SPARC ADI and ARM are capable of, because it doesn't do bounds checks inside linear memory blocks.

WebAssembly strongly sandboxes the module from affecting the world outside of it, not from affecting itself. Isn't that the usual use of the word sandbox? The sandbox imposes a boundary between the inside and outside, but it doesn't directly change how things work on the inside.

It might be nice to have features for enforcing memory bounds within a module, but I wouldn't call those sandboxing, or call the lack of those features a deficit of the sandbox.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#153

Post by tschneidereit »

danielearwicker wrote: post #149
tschneidereit wrote: post #139

Earlier quoted context omitted.

What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't requ…

That future possibiilty reminds me of https://en.wikipedia.org/wiki/Singularity_(operating_system) - where process/address-space isolation was replaced with fine-grained static verification of high-level code (presumably not the first experiment in this area).

Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#154

Post by lambda »

tschneidereit wrote: post #139
lambda wrote: post #125

Earlier quoted context omitted.

Reading through this, this sounds like mostly a capability based architecture, with process isolation replaced with a statically typed bytecode in which you can verify that each module can only use capabilities passed to it. I was wondering why the focus on copying memory between the processes. It should be possible to make capabilities which represent a pointer and a length (and maybe an access mode), which could be…

What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't requ…

What would allow other languages to represent unforgeable pointers as a first class concept and not C/C++/Rust?

Forging a pointer is UB in all of these languages as far as I know.

It seems like you should be able to have opaque types that represent these unforgeable pointers which you can't do arithmetic on or cast to raw pointers, but can access values in type safe ways, or provide a view to a byte slice which does bounds check on access.

Is there a good place for discussion of this design? I seem to be having this conversation with you and Josh both here and on Reddit, and it seems like a lot of the discussion is spread out in a lot of places.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#155

Post by tschneidereit »

jedisct1 wrote: post #148
tschneidereit wrote: post #62

Earlier quoted context omitted.

To expand on this, capabilities allow us to go further than pledge(2): it enables selective forwarding of capabilities to other nanoprocesses, such as only forwarding a handle to a single file out of a directory, or a read-only handle from a read-write one, etc...

Capabilities are also more complicated. I fear that at the end of the day, capabilities will have the same fate as other sandboxing mechanisms: nobody will use them. And, just so that their application works and avoid support burden, developers will tell people to use a setup that enables access to everything. pledge(2) and unveil(2) learned from the past and are way simpler. I really wish WebAssembly had adopted sim…

Agreed, and there are a lot of UX questions to sort out. Many security concepts took many attempts to figure out in full (or to the extent that they have been figured out :))

One important aspect here is that this doesn't just target whole apps. It also targets developers using dependencies: while it's desirable to restrict an application's capabilities, there's a lot of value in developers only giving packages they depend on very limited sets of capabilities. And that seems much more tractable, given that kitchen-sink packages aren't what most people want to use anyway.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#156

Post by saagarjha »

tschneidereit wrote: post #139
lambda wrote: post #125

Earlier quoted context omitted.

Reading through this, this sounds like mostly a capability based architecture, with process isolation replaced with a statically typed bytecode in which you can verify that each module can only use capabilities passed to it. I was wondering why the focus on copying memory between the processes. It should be possible to make capabilities which represent a pointer and a length (and maybe an access mode), which could be…

What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't requ…

> For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether.

The semantics of these languages aren’t incompatible with unforgeable references, though: it generally works in practice, but it’s technically undefined to create pointers out of thin air. Why can’t we take advantage of the standard here to disallow illegally created references? (Which, as I understand it, many other vendors are already beginning to do with e.g. pointer authentication and memory tagging.)

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#157

Post by lambda »

tschneidereit wrote: post #153
danielearwicker wrote: post #149

Earlier quoted context omitted.

That future possibiilty reminds me of https://en.wikipedia.org/wiki/Singularity_(operating_system) - where process/address-space isolation was replaced with fine-grained static verification of high-level code (presumably not the first experiment in this area).

Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)

Yes, one of the answers I want to give any time someone asks "why will WASM succeed when the JVM didn't" is that there is 25 years more experience and research to draw upon.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#158

Post by saagarjha »

est31 wrote: post #44
beefhash wrote: post #34

Earlier quoted context omitted.

> The existence of an LLVM WebAssembly backend helps. So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm? Incidentally, would you consider wasm as a destination language for virtual machines for obfuscation ? I.e. is it reasonable enough to implement it all in about a week? Plus I fear like the decompilation/disassembly tooling might be there too soon for it to b…

LLVM IR is an unstable format, changes a lot and only has one implementation.So it's not well suited for a standard. Google actually did use it for PNaCl but fortunately Mozilla prevailed when wasm was created. "Do what LLVM does" is not a valid strategy. On a related note, I'm glad that Firefox doesn't support the "Do what sqlite does" WebSQL api either, but Chrome (sadly) does.

Plus it’s not really portable.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#159

Post by saagarjha »

beefhash wrote: post #69
jandem wrote: post #45

Earlier quoted context omitted.

> So why aren't people just shipping straight up LLVM intermediate language VMs and instead go through wasm? This is answered in the WebAssembly FAQ: https://webassembly.org/docs/faq/#why-not-just-use-llvm-bitc...

Thanks. That one's on me doing incomplete research. Still leaves open the question as VM for obfuscation (RE tooling, ease of implementation from scratch) though.

Do you have a typo in your second line? I can’t figure out what your question is.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#160

Post by saagarjha »

pjmlp wrote: post #111
gridlockd wrote: post #98

Earlier quoted context omitted.

How would you enforce bounds checking while supporting unsafe languages?

That is exactly the point, don't advertise WebAssembly as safe bytecode, if unsafe languages are part of the picture without any kind of control. Secondly, nor ISO C or ISO C++ forbid implementations that do bounds checking by default. In fact that is what most modern compilers do by default in debug mode. Finally look at memory tagging in Solaris SPARC ADI, Apple iOS or the upcoming ARM extensions support on Android…

> In fact that is what most modern compilers do by default in debug mode.

Assuming that “debug mode” is -g or equivalent, then I have not seen a modern compiler that does this.

Post reply on HN