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

WebAssembly: Docker Without Containers

wasmlabs.dev

Post reply on HN
Print view View original

171–180 of 313 posts

Re: WebAssembly: Docker Without Containers

#171

Post by ptx »

nine_k wrote: post #102
ClumsyPilot wrote: post #77

Earlier quoted context omitted.

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies . It's more like Flatpak or AppI…

> Docker's value proposition is emphatically not security [...] It's the ability to deploy [...] gnarly and imperfect software

This sounds like a recipe for disaster to me and is why I haven't gotten into Docker.

If the software being deployed is too complicated to build and install without Docker, but Docker doesn't provide secure isolation, how can you be sure that this "gnarly and imperfect" mess of a system is secure?

Re: WebAssembly: Docker Without Containers

#172

Post by circuit10 »

kllrnohj wrote: post #157
paulgb wrote: post #154

Earlier quoted context omitted.

I think you could share an address space by using the same SharedArrayBuffer to back the linear memory of both? I could be wrong here, I haven’t done it, but I thought this was the reason for supporting atomics in the first place. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

That only shares one allocation (like shared memory does in regular multi-process scenarios), but you still can't share the address space or even any object heaps at all. Like it's not possible to allocate javascript objects out of a SharedArrayBuffer such that you could pretend you had a shared address space by sticking everything in that. As in, SharedArrayBuffer is equivalent to shm_open. Which means it's not even…

WASM stores everything in an array buffer, it doesn't use JavaScript objects because it's not JavaScript (though there are starting to be features that allow it to interoperate with JS objects). If it didn't store everything in a big memory array then it wouldn't really work because C assumes that

And no, WASM doesn't support memory protection

Re: WebAssembly: Docker Without Containers

#173

Post by jjtheblunt »

batmansmk wrote: post #30
pulse7 wrote: post #9

Earlier quoted context omitted.

If this statement is true, there is no need for Docker, because JVM+JAR existed in 2008! Docker can do more than WASM or JVM+JAR: it can run non-WASM and non-JVM apps like PostgreSQL, etc...

You can compile any C / C++ app down to wasm. In fact that’s the raison d’être of the technology: to provide a portable safe way to run binaries. Here is a link to Postgres in wasm for instance: https://supabase.com/blog/postgres-wasm . The way it works is that instead of outputting assembly for a given architecture in the backend compiler, it outputs wasm instructions that are designed to map all architectures, not…

how does pthread_create compile down?

Re: WebAssembly: Docker Without Containers

#174

Post by monocasa »

kllrnohj wrote: post #157
paulgb wrote: post #154

Earlier quoted context omitted.

I think you could share an address space by using the same SharedArrayBuffer to back the linear memory of both? I could be wrong here, I haven’t done it, but I thought this was the reason for supporting atomics in the first place. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

That only shares one allocation (like shared memory does in regular multi-process scenarios), but you still can't share the address space or even any object heaps at all. Like it's not possible to allocate javascript objects out of a SharedArrayBuffer such that you could pretend you had a shared address space by sticking everything in that. As in, SharedArrayBuffer is equivalent to shm_open. Which means it's not even…

But shared array buffer is the underlying primitive generally for webassembly accessible memory.

Re: WebAssembly: Docker Without Containers

#175

Post by azakai »

kllrnohj wrote: post #147
afavour wrote: post #145

Earlier quoted context omitted.

The web has SharedArrayBuffer. It’s just difficult to work with.

Creating a shared memory allocation between 2 processes doesn't convert them to threads. The heaps are still distinct.

The JavaScript heaps are distinct, that's true, but there is a single shared wasm heap which is used from multiple threads. That is enough to implement the pthreads API.

Applications like Photoshop and Google Earth use ptheads on the Web so their compiled C++ is multithreaded, very similar to how it would run natively, and with similar responsiveness and throughput speedups. Though there are some limitations too, see

https://emscripten.org/docs/porting/pthreads.html

Re: WebAssembly: Docker Without Containers

#176

Post by xvector »

ptx wrote: post #171
nine_k wrote: post #102

Earlier quoted context omitted.

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies . It's more like Flatpak or AppI…

> Docker's value proposition is emphatically not security [...] It's the ability to deploy [...] gnarly and imperfect software This sounds like a recipe for disaster to me and is why I haven't gotten into Docker. If the software being deployed is too complicated to build and install without Docker, but Docker doesn't provide secure isolation, how can you be sure that this "gnarly and imperfect" mess of a system is se…

Docker isn’t billed as a security solution but that doesn’t mean that it doesn’t come with some good defaults. You get some namespace/cgroup/seccomp/etc defaults OOTB which is still probably an improvement over what the organization currently has.

Re: WebAssembly: Docker Without Containers

#177

Post by azakai »

jjtheblunt wrote: post #173
batmansmk wrote: post #30

Earlier quoted context omitted.

You can compile any C / C++ app down to wasm. In fact that’s the raison d’être of the technology: to provide a portable safe way to run binaries. Here is a link to Postgres in wasm for instance: https://supabase.com/blog/postgres-wasm . The way it works is that instead of outputting assembly for a given architecture in the backend compiler, it outputs wasm instructions that are designed to map all architectures, not…

how does pthread_create compile down?

In Emscripten that uses a pthread implementation layer built on top of Web Workers + a shared wasm Memory. Basically memory is shared, and you have atomic instructions, and each thread of execution gets its own Web Worker.

That has some limitations, but for the most part it works just like you would expect pthreads to.

Re: WebAssembly: Docker Without Containers

#178

Post by solomatov »

nine_k wrote: post #162
solomatov wrote: post #137

Earlier quoted context omitted.

> It's also like 2x as slow, Do you have links to recent benchmarks? My understanding is that there were investment in bridging the gap recently.

I looked at stuff like https://programming-language-benchmarks.vercel.app/wasm-vs-r... (Comparisons with small input sizes are not informative; look at larger runs.)

Thanks a lot. The difference is huge unfortunately :(

Re: WebAssembly: Docker Without Containers

#180

Post by solomatov »

jeroenhd wrote: post #117

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

@nine_k shared this https://programming-language-benchmarks.vercel.app/wasm-vs-r... in the comment tree. The results are pretty bad. You could lose 2x or more in cpu perf. There're cases where wasm is pretty close to native though.
Post reply on HN