MELF: Multivariant Executables for a Heterogeneous World | Hacker News Reader

MELF: Multivariant Executables for a Heterogeneous World

usenix.org

24 pointsteleforce13 comments

I think heterogenous means different architectures. X64 and GPU in one binary, running on both at the same time. This seems to be about variants of a single isa, e.g. whether avx is available or not, with load time dispatch.

It can mean both. More specifically, the paper uses the term "Heterogeneous ISA", which more often refers to when two CPU ISAs are completely different (e.g. ARM vs. x86). The paper does reference previous work in that area, and hints that their system could be used for that, but does not present an example of actually doing it.

I've noticed that some other authors prefer to distinguish the two types of "heterogeneous ISA" systems by instead using the term "Partial ISA" when referring to when there is a shared core instruction set.

So it looks like this is a lot more fine-grained than traditional fat binaries like mach-o traditionally provides. I do wonder whether you could use the same technology to provide totally different architecture support in a single binary, although I grant that may actually be less useful in practice than what they're doing here.

This is so hideously ugly compared to a solution like WASM.

WASM needs to stop trying to reinvent the OS and just implement POSIX which 99.99999% of all software is written to use. There also needs to just be WASM as a binary format for specific OSes rather than a separate virtual WASM OS.

How would WASM solve the addressed problem?

If it were generally available you could ship binaries in one coherent format to be specialized on each system for that systems hardware.

So a bit like the JVM and JIT complation?

>WASM needs to stop trying to reinvent the OS and just implement POSIX which 99.99999% of all software is written to use.

And thus, in one fell swoop, defeat the very core purpose of WASM.

The only reason for using WASM is that it does NOT allow access to all the system resources by default. It denies all access, which is a very good thing. Actual working, implemented, widely available, Capability Based Security is an exceedingly rare and precious resource that appears and tends to rapidly wink back out of existence due to cries to "speed up" or "make more compatible" such platforms.

The beauty of WASM is that you can run ANY WASM code, no matter how confused, buggy, or evil, and it can not ever access resources you didn't explicitly give it access to from the outside.

The closest real world analogy I've found (so far) is that of cash in a wallet. If you want to buy something for $4.50, and you hand over $5.00 (an economic capability), you can't somehow accidentally give away your house and car in the process, nor does that cause the other party to permanently gain access to your banking account.... unlike using a credit card could.

The current horrible POSIX model of security is to hand over your wallet, and sign a non-revocable power of attorney to make a simple $5 purchase. The program gets ALL of your Authority by default, which is nuts.

----

This seems more like fuzzing the optimization options on a compiler and keeping all the results, and seeing which works best at run-time. As far as I can tell, all the code is native code, unlike WASM.

That's the theory, in practice the security of WASM is like any other sandbox: the security just shifts to the app hosting the sandbox, which typically are buggy C apps like Chrome.

I think the difference between intentionally exposing stuff and blocking out stuff is very important.

With POSIX and the like we do security mostly by disabling things. By default a program can break into your browser and steal your saved credit card number, and you're trying to figure out how to block that.

With something like WASM you need to specifically make available an API to the code running inside. So if it shouldn't open files, you never give it a file API in the first place. You're under full control of what the code can work with, and it never expands without your knowledge, like when the kernel acquires a new feature.

I’d love to see what you describe take root, but with probably over a trillion dollars worth of software sunk cost in current systems I find it deeply unlikely unless porting could be automated.

The great satan of computing is backward compatibility. It’s almost always why we can’t have nice things.

Otherwise you are confined to greenfield projects only, and to only the subset of the project that is greenfield.

I wonder if there's a 90% compatible POSIX subset that's easier to get people to adopt. Like they say, the best time to plant a tree is 20 years ago. The second best time is now. We have to do stuff and hope they work out, not twiddle our thumbs waiting for the cruft to go away. I know that's easier said than done though.

It seems that almost all of the functions in the POSIX library[1] assume authority do do things with the file system, threads, time, etc. This is exactly the wrong thing to give to code if you care about security. It would be a non-trivial job to fake all these calls, and tie them into PowerBoxes, etc.

[1] https://en.kompf.de/cplus/posixlist.html

Reply on news.ycombinator.com