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

351–360 of 371 posts

Re: WASM will replace containers

#351

Post by titzer »

yencabulator wrote: post #350
titzer wrote: post #348

Earlier quoted context omitted.

A thin kernel interface isn't a reimplementation of a kernel. The WALI implementation in WAMR is ~2000 lines of C, most of which is just pass-through system calls.

Okay, so you mean forwarding the syscalls, not implementing them, and thus throwing away the wasm sandbox.

It does not throw away the Wasm sandbox. Sandboxing means two things: memory sandboxing and system sandboxing. It retains the former. For the latter you can apply the same kinds of sandboxing policies as native processes and achieve the same effect, or even do it more efficiently in-process by the engine, and do interposition and whitelist/blacklisting more robustly than, e.g. seccomp.

Re: WASM will replace containers

#352

Post by yencabulator »

okeuro49 wrote: post #229
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,…

> That's what killed the Java write-once, run-anywhere promise. I write Java software on Intel and deploy to an arm device. The promise seems to work for me.

That's run-on-the-other-device-I-manage, not run-anywhere. Run-anywhere was used in the meaning of run-by-untrusting-parties, like javascript on the web.

Re: WASM will replace containers

#353

Post by yencabulator »

dathinab wrote: post #239
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,…

> That's what killed the Java It's a similar but quite different solution. Java - was designed with a lot of tight system integration foremost, sand boxing being secondary - a ton of the sandbox enforcement where checks run in the same VM/code as the code they where supposed to sandbox, like you Java byte code decided if Java byte code should be able to access file IO etc. - Java Applets are, at lest for somewhat mor…

> Java

> - was designed with a lot of tight system integration foremost, sand boxing being secondary

> Java sandboxing was a lot about desktop application

I think this is a false history. Java was designed for interactive television. As in cable television set top boxes receiving apps broadcast over the cable and executing them.

Re: WASM will replace containers

#354

Post by yencabulator »

udev4096 wrote: post #218
p12tic wrote: post #170

Earlier quoted context omitted.

Container security boundary can be much stronger if one wants. One can use something like https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a…

gVisor is solid but it comes with a perf hit. Plus, it does not work on every image

FWIW the performance loss got a lot better in ~2023 when the open source gVisor switched away from ptrace. (Google had an internal non-published faster variant from the start.)

Re: WASM will replace containers

#355

Post by mixmastamyk »

pjmlp wrote: post #342
mixmastamyk wrote: post #319

Earlier quoted context omitted.

All these work well on our devices, old and new. Y2K wants its talking points back.

Not on mine, including an Asus netbook bought with a Linux distribution pre-installed, which no longer matters as it finally died last year.

Netbook from the 2010s? Possibly it had rare hardware, hard to know.

More commonly you have to wait six months for good/full support of new hardware.

Re: WASM will replace containers

#356

Post by yencabulator »

andrew_rfc wrote: post #162
konaraddi wrote: post #140

Earlier quoted context omitted.

Cloudflare, Fastly, and Amex use WASM in their FaaS implementations

Cloudflare actually uses workerd which is a V8 isolate (which does support WASM with a lot of caveats.)

And you can tell it's really always Javascript with the ability to call into WASM. WASM on Cloudflare Workers is clearly a second class citizen.

Re: WASM will replace containers

#357

Post by yencabulator »

titzer wrote: post #351
yencabulator wrote: post #350

Earlier quoted context omitted.

Okay, so you mean forwarding the syscalls, not implementing them, and thus throwing away the wasm sandbox.

It does not throw away the Wasm sandbox. Sandboxing means two things: memory sandboxing and system sandboxing. It retains the former. For the latter you can apply the same kinds of sandboxing policies as native processes and achieve the same effect, or even do it more efficiently in-process by the engine, and do interposition and whitelist/blacklisting more robustly than, e.g. seccomp.

Alright, selectively forwarding the syscalls, now you're approaching the problem again where you need to reimplement parts of Linux to understand the state machine of what fd 432 means at any given point in time etc; basically you're implementing the ideas of gVisor in a slightly different shape, without being able to run preexisting binaries. Doesn't seem like a useful combination of features, to me.

Re: WASM will replace containers

#358

Post by yencabulator »

sebstefan wrote: post #281
stackskipton wrote: post #83

As PlatformOps (formerly DevOps (formerly SRE (formerly Ops))), either this was hilarious satire or ChatGPT Ketamine trip. I'm not sure. > In the year 2030, no one will remember Kubernetes. So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/202…

WASM is powering Cloudflare workers in pretty much the fashion the guy describes and it does solve the problem of big latencies for cold starts with Lambda stuff Instead of spinning up a container on-demand you spin up what is essentially a chrome tab in your V8 instance. Startup time is nil In terms of solutions looking for a problem, that one seems to have fixed at least one problem for at least one person It's pre…

> Startup time is nil

This is obviously not true when the application itself can take arbitrary amount of time to initialize.

The overhead of WASM startup is small. But Firecracker is also very quick to start the virtualization; a lean compiled app in Firecracker would start quicker than a bloaty interpreted app in WASM. Both approaches can also freeze a pre-initialized application, and even clone those.

Reality is most "serverless" stuff is slow to start because the application itself is slow to start. WASM isn't going to change that, Enterprises are going to Enterprise. The hype field is just very strong.

Re: WASM will replace containers

#359

Post by yencabulator »

LeFantome wrote: post #99

WASM does not run on real hardware. At best, WASM can be considered a virtual machine (in the way that the JVM and the .NET CLR are virtual machines). I guess we can call that a "runtime". Containers package applications that run directly on real hardware (well, directly on a real kernel that is running on real hardware). There is no runtime. I am talking OCI containers here (Docker and Kubernetes). At least they can…

> WASM does not run on real hardware.

Here's a compiler from WASM to native code, it can run AoT also not just JIT:

https://cranelift.dev/

Re: WASM will replace containers

#360

Post by titzer »

yencabulator wrote: post #357
titzer wrote: post #351

Earlier quoted context omitted.

It does not throw away the Wasm sandbox. Sandboxing means two things: memory sandboxing and system sandboxing. It retains the former. For the latter you can apply the same kinds of sandboxing policies as native processes and achieve the same effect, or even do it more efficiently in-process by the engine, and do interposition and whitelist/blacklisting more robustly than, e.g. seccomp.

Alright, selectively forwarding the syscalls, now you're approaching the problem again where you need to reimplement parts of Linux to understand the state machine of what fd 432 means at any given point in time etc; basically you're implementing the ideas of gVisor in a slightly different shape, without being able to run preexisting binaries. Doesn't seem like a useful combination of features, to me.

> you need to reimplement parts of Linux

Again, no. The security policies we have in mind can be implemented above the WALI call layer and supplied as an interposition library as a Wasm module. So you can have custom policies that run on any engine, such as implementing the WASI security model as a library. As it is now, all of WASI has to be implemented within the Wasm engine because the engine is the only entity with authority to do so. That's problematic in that engines have N different incompatible, incomplete and buggy implementations of WASI, and those bugs can be memory safety violations that own the entire process.

Thin kernel interfaces separate the engine evolution problem from the system interface evolution problem and make the entire software stack more robust by providing isolation for higher-level interfaces.

Post reply on HN