WASI: A New Kind of System Interface | Hacker News Reader

WASI: A New Kind of System Interface

infoq.com

99 pointslewisjoe56 comments

Virtualization, then Containers, and now WASM are all stages in completing the implementation of capability based security started long ago with the separation of root and users back in Unix.

While it is reasonable to trust users with their own files, it is unreasonable that the only model of computing offered to those users requires that they then give all of their privileges to every piece of code they run.

It is possible to run code from anywhere without having to trust it, thanks to this new model of computing.

> It is possible to run code from anywhere without having to trust it, thanks to this new model of computing.

Capability security is almost as old as access control lists. That's the only quibble I have with your post.

>Capability security is almost as old as access control lists.

Yes, but it's never been fully implemented. Separating superuser/root from normal users was a good first approximation. However, in the modern era of persistent internet and mobile code, we need to finish the job.

Theoretically, you could start a new process having previously created a new UID and having turned off access to all files in the ACL on the root, but can a user do that? Easily? Can you explain it to someone's mom?

Money in a wallet is capability based, and people have managed that model since the beginning.

I'm fine with ACLs for managing overall access to file structures on a per account basis, they don't work for a per execution instance basis.

> Yes, but it's never been fully implemented. Separating superuser/root from normal users was a good first approximation

It sure has, in at least 6 different operating systems that have actually seen real world use, and 3 programming languages since the mid 70s.

> Can you explain it to someone's mom?

"Don't click the Incredimail links in your email"

Actually, under capability security it should be pretty safe to click links in emails, because all programs that run with least possible privilege.

https://en.wikipedia.org/wiki/Capability-based_security

Aren't UID's namespaced in modern Linux? It should be quite possible.

It's a good thing there aren't any known classes of architectural attacks exploiting the interaction of speculative execution and caches to exfiltrate sensitive data, nor are there classes of attacks which exploit the physical properties of DRAM to evade memory protection.

Yes indeed; running untrusted code blobs on my home computers and cloud servers alike is truly and finally solved by running them in a VM.

Malicious attacks aren't always the vector of concern.

There are many software packages that confine themselves to what is legal. They often want to ingest and upload everything they can about the user. But if they are locked down to a narrow set of user data, they won't risk the liability of attacking the protections themselves.

It's also rather harder to exfiltrate data via rowhammer or meltdown than via, say, unrestricted filesystem access so even if it's technically possible, it will be less prevalent.

I agree that we have big problem with defective CPUs and DRAM in the industry. Those chips and modules shouldn't have made it out the factory door, nor should they have passed quality control at the receiving desk.

We also seem to have the same issue with SSD modules and SYNC commands.

You can't fix broken hardware in software without taking a huge performance it, if it is possible at all.

Yes, we all like to point out corner cases here, don't we?

> all stages in completing the implementation of capability based security started long ago with the separation of root and users back in Unix.

Ahem, such distinction predates Unix, and in fact Unix has a watered down regime compared to Multics, which implemented a multiple ring approach.

In other words, computing existed before Unix.

Burroughs was one of the first computing systems usign bytecode as executable format and capability based security, it is 10 years older than UNIX.

Its security capabilities are one of the reasons why Unisys keeps updating and selling it to customers that want security above everything else.

Virtualization and containers have existed in IBM mainframes for a decade before making their way into UNIX.

The second part of the talk is close to what I want, but they're missing a few parts.

I want to set up a DNS-like system, where I have some pub/private key pair to control which servers you can find me at. My friend Tom sets his up, too.

Then I want to tell the Service Host she's talking about, "Here's my friend Tom's public key. Please look him up in the DNS system, and find out how to reach one of his hosts. Let this new Service X, talk to Tom. Use something like Wire Guard to establish a connection directly from this wasm Service X that I'm running, to a similar wasm service X that Tom is running. We're going to send proto messages (not streams!) back and forth to each other, and you're in charge of connectivity."

Give me that, and the ability to talk to, I dunno, Redis, SQLite, MongoDB, and/or maybe Firebase, and I think people could make some really amazing federated or P2P social apps with a very, very small amount of code.

I picture writing a Front-end UI on Flutter that talks to a Back-end like I describe.

PS maybe someone could make a WASM-first (no Dart) version of Flutter?

This seems like a not that complicated library on top of what fundamentals actually need to be built.

Most of this is feasible today using Opportunistic IPSec. What's missing is the high-level (Redis, SQLite, MongoDB, etc) application interfaces you're hinting at. Opportunistic IPSec operates at the IP layer, below all of that. There are BSD socket API controls for IPSec, but Opportunistic IPSec was mostly intended to be passive except for an application (optionally) requesting or verifying that a data stream is protected.

Unfortunately, Opportunistic IPSec failed miserably at widespread adoption. The same fate is almost certainly waiting for any similar all-encompassing approach. Wireguard doesn't really help as the vast majority of the complexity and pain exists above the level of the basic stream encryption. (Supporting schemes like Opportunistic IPSec is one reason why IPSec permits direct IP-to-IP encryption without tunneling or layering. One of Wireguard's simplifying assumptions was that it would be used to create VPNs and tunnels; TLS had won the day as a solution for direct, end-to-end encryption.)

Thanks for your comment.

I kind of feel like you and I are talking past each other a bit. (And the fact that I don't know any of the technical terminology doesn't help me at all, here.)

I want this Host program she's talking about to be trivial to install for some random end user. And then that user can pick my App from some App Store interface, similar to the Demo in sandstorm.io, and then add Contacts, and then give my App permission to talk to some of their Contacts.

So, the Host program is super sandboxed, and capability-model based...

And I'm also asking for the Contact Management DNS Connectivity system, which I imagine feels roughly like setting up a public/private key pair with PGP, and then feels roughly like setting up a Dynamic DNS.

I don't actually care about specific ports, and how they're actually encrypted, etc. It could connect over WebRTC for all I care. Yes, TLS might work. I hear NAT traversal is a problem to connect peer-to-peer, and I barely know what I'm talking about. I want the Host / DNS / some minimal central servers to take care of that for me.

I feel like the DB interfaces are slightly higher level than the stream level access she was talking about, and would make it slightly easier to do some of the cool stuff I envision. But I feel like providing DB Capabilities is a pretty low bar - it should be relatively easy to do, right?

I'm working on a proof of concept React-ish UI lib powered by WASM. My goal was to make it truly cross platform, for example it should generate ui markups on a headless server as well

You can achieve that using Handshake, which is a blockchain based replacement for DNS + PKI.

Or you could use IPFS with P2PConnect where you can look them up by public key and completely skip DNS.

Maybe it's by design, but my biggest sticking point with WASM is the inability to modify the code at runtime, at least to my knowledge. This makes it a bad target for dynamic languages where the source -> executable mapping isn't wholly known ahead of time, especially Lisps but also any looking to JIT compile things.

Speaking of Lisp and WASM, IchigoLisp [0] is a remarkably faithful implementation of LISP 1.5 in WAT. Extraordinarily impressive, and inspires even more awe for the original system from the 60s.

[0] https://github.com/zick/IchigoLisp

I believe you can call functions through a table, which makes it trivial to switch out functions at runtime.

Well, you can always add a VM inside WASM as a layer of abstraction, and modify its code at runtime.

Is that what things like this [1] are doing?

[1] https://github.com/pyodide/pyodide

It's still possible to JIT Wasm code and run it, though. WebVM does that.

Well, that functionality is not included by default, but you can certainly add it yourself. Add a function to your host system (be it a browser, a CLI interpreter, etc) which accepts a wasm module you dynamically create, instantates it, and gives you acces to some function it exports. I don't think any WASM implementations provide such a function by default, but that can be changed easily and is not an insurmountable limitation of WASM.

I'm 10 minutes in, and thinking "So you want more programs to read from standard input?"

yea, programs that cannot work with stdin better have a very good reason for it.

1994 blog post: "java.lang: A New Kind Of System Interface"

I'm also slightly annoyed nowadays by "A New Kind of X" simply because of Wolfram's self-aggrandizing book A New Kind of Science.

Do we have to make this joke every single time anything WebAssembly comes up. We get it Write Once Run Anywhere was done before.

Yes, because most WebAssembly advocacy knowingly ignores the past to sell their agenda.

It isn't only Java, bytecode as execution format goes all the way back to late 1950's, Gosling quite clearly asserts the work that Java builds upon, contrary to the WebAssembly folks.

https://queue.acm.org/detail.cfm?id=1017013

"Back when I was a grad student at Carnegie Mellon, I had this problem where I needed to have some kind of an architecture-neutral distribution format. We had a bunch of workstations called PERQ machines. The folks who built them were a bunch of hardware guys who didn’t want to do software. The only compiler that they could get for free was UCSD (University of California San Diego) Pascal. So they made the hardware interpret UCSD Pascal p-codes.

My thesis advisor, Raj Reddy, asked me to spend the summer trying to figure out how to get the software from these PERQ machines to run on our VAXs.

I started out writing a little hardware emulator, just to understand the p-codes. Then I realized I could actually write a code-generating program that translated from Pascal p-codes to VAX assembly code.

So I wrote a hardware emulator for the PERQ machine that did hardware emulation by translating, and I spent a bunch of time trying to figure out why it was that the translation actually worked. One of the things that I noticed was that the code that I was getting at was actually better than the code that was coming out of the C compiler. I was quite floored by how well it worked, and I spent a bunch of time thinking about what it was about p-code that actually made it work, versus trying to do this for some other instruction set.

Then fast-forward a bunch of years, when I was trying to do the project that Java came out of. I had to do this architecture-neutral distribution format, and then I just went ka-ching! You know, this p-code translator thing would actually just drop in there."

As another example of hidden agenda, most WebAssembly sales also ignore PNaCL and CrossBridge, only mentioning asmjs as previous art.

I used Java on web and PNaCL quite heavily, but I also love WASM. Mainly WASM is open, those others not so much.

But I don't understand, you make the Java joke because previous attempts aren't recognized enough?

There's plenty of blog posts about transitioning from them, Chromium (the only ones who implemented PNaCL) did one, as did others.

Not only Java, there are a pool of similar ignored technology all the way back to late 1950's.

There are plenty of WebAssembly articles selling it as being the first kind of bytecode to support C like languages.

Many articles for many topics are ignorant or plain wrong.

That doesn't detract from the technology itself, which is great.

Great at reinventing the wheel.

The other wheels weren't round enough.

They were, but the buyer sneered at them.

Idk about you but I remember Java applets being really slow, and the applet sandbox horribly insecure.

Nobody ever claimed it was new. It wasn't new when Java tried it.

And the actual Web-Assembly developers don't ignore that stuff. And even if they did so what? Re-inventing the wheel is common and sometimes something good and new comes out of it.

Ah but they do claim, that is the big different to the Java authors.

Something good like re-inventing EAR files.

Please show me text by actual core developers that claim something is 100% new that isn't. And I'm not talking about some random articles you find with googling.

And btw, not mentioning prior art doesn't count.

So it is only valid if it fits your view of the world, won't bother.

What are you even talking about. I asked you directly to show me evidence of the claims you made, nothing else.

"And I'm not talking about some random articles you find with googling. And btw, not mentioning prior art doesn't count."

Tainted evidences, you ask. Me no bother.

So really you have no evidece at all, you are just generally angry at everybody who is involved with WebAssembly because they don't site your work and that makes you bitter. Got it.

And it's not like Java is in the browser and WebAssembly is trying to reimplement something that's already available. Java got kicked to the curb and for a reason. If it's such a superior solution go ahead and put it back and show all the people working on WebAssembly what a waste of time it is.

Nah, I appreciate the wonderfull work of those WebAssembly people that allowed me to have Java applets, Flash and Silverligh running again in the browser.

https://leaningtech.com/cheerpj/

https://leaningtech.com/cheerpx-for-flash/

https://opensilver.net/

Thanks for making the revenge of plugins a reality.

I was also reminded of Java when it delved into "you don't even know you have a file, it's just a stream". The stream abstraction of course predates Java. But Java is where (IMO) developers really started embracing programming to these kinds of abstract interfaces en masse.

Some examples for the curious, CLU, Smalltalk, Common Lisp/Interlisp-D, C++, Object Pascal.

Yeah it worked well if you were ok with writing code in Java. Guess what? Lots of people don't want to write Java.

WASI lets you use lots of languages included non-GC languages (GC'd languages are a bit of a WIP but it's going to happen).

> Guess what? Lots of people don't want to write Java.

It's funny that some of the most popular languages these days are Go (crippled Java 1.4) and Rust (Java for frontend web developers who need to be tricked into it) so it seems like lots of people really do want to write Java.

That's such a weird thing to say. Go and Rust are both very different to Java.

You didn't need to write java to use the JVM, but okay.

Just like Amsterdam Compiler Kit or IBM TIMI, as two examples among many others for bytecode used by non-GC languages.

https://www.brendangregg.com/blog/2019-12-02/bpf-a-new-type-...

Case in comparison, bpf or ebpf. In that they are both a type of radically different approach on solving the old problem. Bpf being kernel programmability for app developer, wasm being portable execution environment.

Reply on news.ycombinator.com