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

361–370 of 371 posts

Re: WASM will replace containers

#361

Post by yencabulator »

titzer wrote: post #360
yencabulator wrote: post #357

Earlier quoted context omitted.

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 wi…

To filter out syscalls for complex policies, you need to understand the semantics of prior syscalls. For example, you need to keep track of what the dirfs in an unlinkat call refers to. And to keep track of FDs you need to reimplement fcntl. And so on.

This is why gVisor contains a reimplementation of parts of Linux.

Re: WASM will replace containers

#362

Post by titzer »

yencabulator wrote: post #361
titzer wrote: post #360

Earlier quoted context omitted.

> 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 wi…

To filter out syscalls for complex policies, you need to understand the semantics of prior syscalls. For example, you need to keep track of what the dirfs in an unlinkat call refers to. And to keep track of FDs you need to reimplement fcntl. And so on. This is why gVisor contains a reimplementation of parts of Linux.

Yes, but the engine doesn't need to do this, you can do this on your own time as a library. As there are literally dozens of Wasm engines now, thin kernel interfaces are a stable interface that they can all implement in exactly the same way[1] (simple safety checks + pass through) and then higher-level, more safe, and in some way better policies and APIs can be implemented as Wasm modules on top.

[1] This makes the interface per-kernel, not per-kernel x per-engine. It's also not per-kernel x per-kernel; engines would not be required to emulate one kernel on another kernel.

Re: WASM will replace containers

#363

Post by yencabulator »

titzer wrote: post #362
yencabulator wrote: post #361

Earlier quoted context omitted.

To filter out syscalls for complex policies, you need to understand the semantics of prior syscalls. For example, you need to keep track of what the dirfs in an unlinkat call refers to. And to keep track of FDs you need to reimplement fcntl. And so on. This is why gVisor contains a reimplementation of parts of Linux.

Yes, but the engine doesn't need to do this, you can do this on your own time as a library. As there are literally dozens of Wasm engines now, thin kernel interfaces are a stable interface that they can all implement in exactly the same way[1] (simple safety checks + pass through) and then higher-level, more safe, and in some way better policies and APIs can be implemented as Wasm modules on top. [1] This makes the i…

Oh yes, let's delegate the hardest part back to the caller! Surely nothing will go wrong.

Try writing a seccomp policy for filesystem access (that isn't just 100% yes/no). That's how hard this thing will also be to use.

Re: WASM will replace containers

#364

Post by milesrout »

pjmlp wrote: post #343
milesrout wrote: post #334

Earlier quoted context omitted.

Never experienced this myself, and I have used discrete and integrated graphics cards from a variety of manufacturers. Meanwhile on Windows I am not exaggerating when I say that every computer I have owned and every peripheral device I have ever used has had serious issues. Wireless headphones randomly disconnect, microphones require frequent unplug-replug cycles, rebooting is often required, reinstalling is common.…

Because on Windows, it is the OEMs that provide the support, while on Linux (sadly) even after 30 years, it is mostly reverse engineered unless we are talking about OEM custom distros with their own blobs, like Android, ChromeOS and WebOS.

That does not explain the phenomenon I referred to.

Re: WASM will replace containers

#365

Post by Melatonic »

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…

Micro VMs are the future in my opinion. Best of all worlds

Re: WASM will replace containers

#366

Post by titzer »

yencabulator wrote: post #363
titzer wrote: post #362

Earlier quoted context omitted.

Yes, but the engine doesn't need to do this, you can do this on your own time as a library. As there are literally dozens of Wasm engines now, thin kernel interfaces are a stable interface that they can all implement in exactly the same way[1] (simple safety checks + pass through) and then higher-level, more safe, and in some way better policies and APIs can be implemented as Wasm modules on top. [1] This makes the i…

Oh yes, let's delegate the hardest part back to the caller! Surely nothing will go wrong. Try writing a seccomp policy for filesystem access (that isn't just 100% yes/no). That's how hard this thing will also be to use.

> let's delegate the hardest part back to the caller!

Obviously, an expert would write the security policies and make them reusable as libraries. Incidentally, that is what WASI is--it's not only a new security model, but a new API that requires rewrites of applications to fit with the new capability design.

> Try writing a seccomp policy for filesystem access

Try implementing an entire new system API (like WASI) in every engine! You have that problem and a whole lot more.

For comparison, implementing WASI preview1 is 6000 lines of C code in libuvwasi--and that's not even complete. Other engines have their own, less complete and broken, buggy versions of WASI p1. And WASI p2 completely upends all of that and needs to be redone all over again in every engine.

Obviously, WASI p1 and p2 should be implemented in an engine-independent way and linked in. Which is exactly the game plan of thin kernel interfaces. In that sense, at the very least thin kernel interfaces is a layering tool for the engine/system API split that enhances security and evolvability of both. Nothing requires the engine to expose the kernel interface, so if you want a WASI only engine then only expose WALI to WASI and call it a day.

Re: WASM will replace containers

#367

Post by afiori »

pjmlp wrote: post #341
afiori wrote: post #316

Earlier quoted context omitted.

Yep, once something failed nothing with any similarity to it will ever go anywhere

gRPC has gone to places, the question is if the thing with similarity to it has actually learned the lessons from the past, or is the same thing repacked for a new generation.

If the category you are considering includes both Wasm and gRPC then it might be too wide to say anything about.

Re: WASM will replace containers

#368

Post by dathinab »

yencabulator wrote: post #353
dathinab wrote: post #239

Earlier quoted context omitted.

> 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.

Javas focus has shifted multiple times through history and at least starting with it becoming generally available hasn't really been a single purpose thing, so I don't think this is really making any difference in the argument.

But I could have formulated some thing better:

> sand boxing being secondary

sand boxing for _security_ being secondary, for compatibility it was primary (e.g. like flatpack) and even if it wasn't what was seen as acceptable security for the 90th isn't anywhere close to it for today in most cases

Also "tight system integration" was in context of "highly sandboxes" things, which isn't necessary quite the same. E.g. in context of "highly sandboxes" things rusts standard library and support for C-API libraries is tightly system integrated. But if you speaking in a context of e.g. windows you need to add the official bindings to the various MS specific system libraries to count as "tightly integrated" and even then you could argue it's not quite there due to not having first class COM support.

Anyway I think the most important takeaway form Java sandbox security is "never run the code enforcing your sandbox as part of the inside of your sandbox" because a huge amount of security issues can be traced back to that (followed by the way Java applets have been embedded in the browser wrt. "privileged" applets being really really bad designed in a ton of ways).

Re: WASM will replace containers

#369

Post by int_19h »

milesrout wrote: post #334
int_19h wrote: post #324

Earlier quoted context omitted.

As things are, all browser developers - including Firefox! - disable hardware acceleration on most video cards in their browsers on Linux because it is "too unstable". The result is a 20% difference in battery life between Linux and Windows if you mostly do browsing.

Never experienced this myself, and I have used discrete and integrated graphics cards from a variety of manufacturers. Meanwhile on Windows I am not exaggerating when I say that every computer I have owned and every peripheral device I have ever used has had serious issues. Wireless headphones randomly disconnect, microphones require frequent unplug-replug cycles, rebooting is often required, reinstalling is common.…

As noted above, I have experienced it myself on a freshly bought laptop (Thinkpad T14e AMD) that is specifically touted as Linux-friendly. I was genuinely curious as to how the battery life varies between Linux and Windows, and so I did a simple test that just did automated Reddit browsing, and left it running. When I saw the results, the disparity was so unexpectedly large that I went to investigate and found out about the hardware accelerated rendering being disabled by default on Linux in both Chrome and Firefox, and why.

Then, of course, I was also curious whether their reasoning was grounded, so I manually enabled acceleration and re-run the test - and found out that both Chrome and Firefox will inevitably crash in 2-3 hours of active browsing with it enabled, so they disable it for a reason.

As far as "maybe Linux isn't the problem" - you're broadly correct that it's really an issue of hardware quality and/or lack of good first party drivers. But from the end user perspective, if you can't reliably use Linux with popular off-the-shelf hardware, it's not really "ready for the desktop", regardless of where the blame lies. I've been a Linux user for 25 years now, with about a decade of using it as a primary desktop OS, and this exact excuse has been around for as long as I remember (I've used it myself plenty of times way back!). And yet, here we are.

Post reply on HN