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

WASM will replace containers

creston.blog

Post reply on HN
Print view View original

291–300 of 371 posts

Re: WASM will replace containers

#291

Post by pjmlp »

afiori wrote: post #282
pjmlp wrote: post #193

Earlier quoted context omitted.

DLLs already run everywhere since CLR became cross platform. Really this is walking an already trailed path, multiple times, we can even notice the parts grass no longer grows, how much it has been walked through. https://en.m.wikipedia.org/wiki/UNCOL

The "universal compile target" facet of wasm is much less focal than the "universally embeddable" one. The sandboxing is the keystone holding up the entire wasm ecosystem, without it no one would be interested in it same as nobody would run javacript in browsers without a sandbox (we used to, it was called flash, we no longer do). I am curious why you focus so much on "universal runtime/compile-target do fail" rather…

Because WASM sandbox only works, to the extent hackers have not bothered attacking existing implementations to the same level as they did to Java applets, which is anyway one implementation among many since 1958 UNCOL idea.

Additionally, it is a kind of worthless sandbox, given that the way it is designed it doesn't protect against memory corruption, so it is still possible to devise attacks, that will trigger execution flows leading to internal memory corruption, possibly changing the behaviour of an WASM module.

> Nevertheless, other classes of bugs are not obviated by the semantics of WebAssembly. Although attackers cannot perform direct code injection attacks, it is possible to hijack the control flow of a module using code reuse attacks against indirect calls. However, conventional return-oriented programming (ROP) attacks using short sequences of instructions (“gadgets”) are not possible in WebAssembly, because control-flow integrity ensures that call targets are valid functions declared at load time. Likewise, race conditions, such as time of check to time of use (TOCTOU) vulnerabilities, are possible in WebAssembly, since no execution or scheduling guarantees are provided beyond in-order execution and post-MVP atomic memory primitives :unicorn:. Similarly, side channel attacks can occur, such as timing attacks against modules. In the future, additional protections may be provided by runtimes or the toolchain, such as code diversification or memory randomization (similar to address space layout randomization (ASLR)), or bounded pointers (“fat” pointers).

--> https://webassembly.org/docs/security/

Finally, WASM is only as secure as its implementations, whatever the bytecode promises only matters if the runtimes aren't exploitable themselves.

Re: WASM will replace containers

#292

Post by afiori »

Capricorn2481 wrote: post #73
resonious wrote: post #23

Earlier quoted context omitted.

This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.

I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?

I think that looking at it in terms of Embeddability is more useful compared to portability.

In the sense that compiling C to any language is easily done without too many problems, what wasm allow is to have a secure and performant interface with that language.

For example IIRC one of the first inclusions of wasm was to sandbox many of the various codecs that had regular security vulnerabilities, in this Wasm is neither the first nor the only approach, but with a combination of hype and simplicity it is having good success.

as in https://arxiv.org/abs/1912.02285

Re: WASM will replace containers

#293

Post by afiori »

resonious wrote: post #23
not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.

The idea with wasi containers is that you could spin up a container with only the interfaces it needs.

Re: WASM will replace containers

#294

Post by thesz »

This is a post about shiny new thing author loves.

And author loves shiny new things [1]: "...use 10% of your time writing code (or telling AI to write code)..."

[1] https://creston.blog/stop-writing-code/

What about old, not shiny things?

For example, SQL is Turing complete and expresses simulation of data flow paradigm [2]. It is effectively executable on current massively parallel hardware and even scales horizontally, enabling safe transactional "microservices." Why should we embrace WASM, but not SQL?

[2] https://en.wikipedia.org/wiki/Dataflow_architecture

Re: WASM will replace containers

#295

Post by afiori »

lmm wrote: post #250
not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

Java write once run anywhere is fine. Java people don't generally bother with containers because there's no point, the JVM already solves the same problem.

Portability and sandboxing are two very different properties.

Re: WASM will replace containers

#296

Post by afiori »

bzzzt wrote: post #252
lmm wrote: post #250

Earlier quoted context omitted.

Java write once run anywhere is fine. Java people don't generally bother with containers because there's no point, the JVM already solves the same problem.

Almost all modern Java frameworks specifically target Docker containers in the cloud.

To be fair it is in part due to containers being a really nice way to deploy languages with fat-runtimes.

Re: WASM will replace containers

#297

Post by octopoc »

catmanjan wrote: post #55
octopoc wrote: post #47

Earlier quoted context omitted.

Blazor is stable and extremely easy to use. It’s just a little slow to load, although there are ways to mitigate that.

Blazor is a great developer experience but when you put it side by side with the other technology solutions (react, angular, anything really) its so slow that you will quickly be told to use something else...

It depends on the application. And gp was talking about stability and ease of use, not speed.

Re: WASM will replace containers

#298

Post by guappa »

not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

I don't think it was killed by security, since nobody cares about security. At most companies care about pretending to do security.

Re: WASM will replace containers

#299

Post by guappa »

josephg wrote: post #95
not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…

> It should be pretty easy to do the same thing in userland with a wasm runtime.

Not easy and certainly not fast.

Re: WASM will replace containers

#300

Post by SEJeff »

tecleandor wrote: post #251
SEJeff wrote: post #184

Earlier quoted context omitted.

docker and lxd are competing projects. Docker does not use lxd to launch containers. lxd was written by the lead dev (at canonical) of lxc which was not as polished as docker but sort of kind of did the same thing (ran better chroots) They both use Linux kernel features such as control groups and namespaces. When put together this is referred to as a container but the kernel has zero concept of “a container”.

Docker started using an LXC driver to run workloads, but it was deprecated 10 years ago. No LXC remaining there :P

Cool but lxd is still a competitor to docker. I’ve read the move code for some work reasons. No lxc, as you said :)
Post reply on HN