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

241–250 of 265 posts

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

#241

Post by wahern »

gatestone wrote: post #220

This is getting complicated. OS process management, threads and lightweight pocesses, green field process control, virtual machines, containers, sandboxing in n browsers with m different technologies, now this WASM stuff..and orchestrating this all across the cloud and the global internet, ending in homes and corporate machine rooms. Enverywhere you have to think: who can load/run a module/process and from where, how…

> Where do you think /proc came from?

UNIX 8th Edition (http://lucasvr.gobolinux.org/etc/Killian84-Procfs-USENIX.pdf) and SRV4 (https://www.usenix.org/sites/default/files/usenix_winter91_f...)

A better analogy would be /dev, but that was already part of Unix from the beginning. Plan 9 is really about per process, user mountable namespaces implemented by 9P-speaking user processes; basically what you said, sans the origin of synthetic file systems and file-like objects.

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

#242

Post by tasogare »

pjmlp wrote: post #50
JoshTriplett wrote: post #15

Earlier quoted context omitted.

The toolchains for building WebAssembly from numerous languages, for one thing. The existence of an LLVM WebAssembly backend helps. (While eventually there were other languages that targeted the JVM, for a long time if you wanted the JVM sandbox you had to write Java.) WebAssembly also provides a fine-grained API surface area; you can run a WebAssembly sandbox with no external functions provided, or just a few. WebAs…

Just like MSIL, Xerox PARC microcoded bytecode, IBM mainframes language environments and plenty of other examples.

Yes the concept, as well as implementations, existed for decades. I think WASM is hype because it comes from the Web/JS community and they have good communication, but technically there is nothing new under the sun.

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

#243

Post by afiori »

ctz wrote: post #78
JoshTriplett wrote: post #2

I'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…

The post mentions: > tiny IoT device But, I've looked at this in the past and concluded wasm was a pretty poor fit for small devices: 1) it only addresses memory in 64KB pages (perhaps more SRAM than you might have) and 2) requires both single and double float support. (1) might be possible to work-around by backing the memory space with smaller page allocations -- at the cost of indirection for every memory access.…

> it only addresses memory in 64KB pages

is this by the standard or implementations?

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

#244

Post by afiori »

devwastaken wrote: post #198
JoshTriplett wrote: post #2

I'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…

This isn't entirely accurate. Exploitations in whatever code is converted to wasm instructions still work inside the wasm memory space. As in, if you write your program in c, python, whatever, and put it in wasm, then have a wasm extension system of some sort - if that c or python is exploitable, then whatever external access that wasm instance has is now useable. And whatever memory is in the memory space can be mod…

The point is that you can more easily and clearly sandbox the wasm plugin. If the python implementation tries to send http requests but the wasm sandbox has no network access you are safer in wasm than in python.

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

#245

Post by afiori »

lambda wrote: post #154
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…

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…

In unsafe rust you can arbitrarily increase the length of a vector/string by modifying the stored length. You do not need to forge the pointer itself to break the pointer's invariant.

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

#246

Post by afiori »

tasogare wrote: post #242
pjmlp wrote: post #50

Earlier quoted context omitted.

Just like MSIL, Xerox PARC microcoded bytecode, IBM mainframes language environments and plenty of other examples.

Yes the concept, as well as implementations, existed for decades. I think WASM is hype because it comes from the Web/JS community and they have good communication, but technically there is nothing new under the sun.

I would say that being a success instead of a failure is something new. The JVM was successful but not for plugins, nor for embedded safety.

Also the fact that many vendors have reached a consensus on both a MVP and an update process to future features looks like a win. If Sun, Microsoft, Apple, and Google had all been on board with the (supposedly free software) JVM the story would have been very different.

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

#247

Post by afiori »

saagarjha wrote: post #158
est31 wrote: post #44

Earlier quoted context omitted.

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.

It is intentionally not portable.

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

#248

Post by afiori »

pjmlp wrote: post #189
connicpu wrote: post #173

Earlier quoted context omitted.

The point of the byte code being safe is that no operations performed by WASM code could cause a memory unsafety bug from the perspective outside the sandbox. If your code violates its own memory rules then it will only mess up the logical state of its VM memory chunk, and probably produce an incorrect result. The same thing can happen in any safe language if you access the wrong indexes in an array because of a logi…

That incorrect results might lead to security exploits, the same way that browsers now get exploited by taking advantage how their VMs work. So hand waving such security issues is rather strange, when it should be the top concern when selling an infrastructure to run code from unknown sources.

> the same way that browsers now get exploited by taking advantage how their VMs work

The difference is if the exploit is run by the browser or the VM. If the VM has a logic error, gives back the wrong result, the browser decides to trust the result and be exploited then it is a browser bug; not a sandbox issue.

The other situation is when a browser spins up a VM to add 2 and 2 but then the VM starts downloading malicious files from the internet.

No kind of safe language can avoid the first class, wasm avoids the second.

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

#249

Post by afiori »

pjmlp wrote: post #222
saagarjha wrote: post #213

Earlier quoted context omitted.

> iOS compilers that make use of hardware memory tagging No iOS devices ship with ARMv8.5, so while I think compilers are implementing this today I am not sure if Xcode ships with this or if it's functional. > So ironically something like Android does have a better sandboxing model as WebAssembly. …you're not understanding what sandboxing means.

Apple has their own CPUs, https://developer.apple.com/documentation/security/preparing... I do understand what sandboxing means, and how WebAssembly advocates keep overselling its security capabilities, by ignoring issues that other bytecode formats have taken a more serious approach, already in the mid-60's.

I believe that wasm is not particularly focused on functional security as much as embeddable security.

Essentially the promise here is that you can download a random wasm from anywhere, run it with little-to-none privileges and be sure nothing bad can happen.

There was an article here many months ago detailing how wasm on the server makes it harder to mitigate attacks due to lack of wasm-inspecting tooling compared to system utilities for processes/native binaries.

But in part that is because the attack model of wasm is "literally executing malicious code".

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

#250

Post by afiori »

pjmlp wrote: post #230
BubRoss wrote: post #225

Earlier quoted context omitted.

Are you saying webasm will crash or that it is insecure? These are two different things and you seem to be conflating them. In your posts you have said that it is insecure but when you talk about specifics it just seems to be about crashing. Then when pressed you avoid any examples.

I keep telling the examples, memory corruption, typical C exploits. Apparently the force is strong with WebAssembly advocacy.

internal memory corruption is different from external memory corruption.
Post reply on HN