Hacker News Reader

> having a trusted compiler could (eventually) massively increase performance by removing processes entirely (no more virtual memory! no more TLB flushes and misses! less task switch overhead!) and eliminating the kernel/user mode separation

I saw a talk a while ago that was advocating for the same thing, except this was about JS and not webassembly. I can't find it tho - I remember it being related to the WAT js talk; It also mentioned that it would eliminate rings on the cpu (and simplify cpus) and context switches which would make execution faster; they were citing some MS research on the matter - damn I really wanna find the talk now...

Edit: https://www.destroyallsoftware.com/talks/the-birth-and-death...

thanks BoppreH

MS research: "Hardware-based isolation incurs nontrivial performance costs (up to 25-33%) and complicates system implementations" (virtual memory and protection rings); I think MS knows what they're talking about here

Thanks for the link. I would argue that a true trusted compiler needs to accept an unmanaged language and emit code without a runtime, though. A runtime is cheating, because you can always make one that implements an iron-clad sandbox that doesn't require processes...by implementing a (very slow) VM.

To put in another way - I don't think that security or performance are that hard to achieve on their own - the hard part is getting both at once. And then, adding expressiveness on top is even more difficult, as Rust as aptly demonstrated.

Rust is not secure at all in the sense used here — untrusted, arbitrary user code written in rust is a security threat.

More specifically, unsafe blocks may violate the compiler's security guarantees and procedural macros actually run inside the compiler process at build time. Declarative macros do this too, but they're far too restricted to allow shenanigans. Procmacros can disable Rust's stability guarantees[0].

[0] https://github.com/m-ou-se/nightly-crimes

Nah, that’s not what I mean. It is a Turing complete language — if it is used to interpret some other language inside itself, it can’t add anything to that languages’ guarantees automatically. You can write a javascript interpreter in rust that is trivial to exploit and access e.g. the file system or whatever.

Singularity was a experimental OS written in a a variant of C# and .Net managed code by MS Research that ran using software isolated processes rather than hardware isolation, this is probably what they where referencing:

https://en.wikipedia.org/wiki/Singularity_(operating_system)

http://joeduffyblog.com/2015/11/03/blogging-about-midori/

There is also a really great blog about Singularity’s “rebirth” experimental OS, Midori, that continued in its footsteps.

I think I heard of this in the early to mid 00’s and it was in the context of Java. This set of ideas has been cooking for a while. Might be about time to taste the proverbial soup.

> it's a trusted compiler

Sorry I have to quibble here, but this term is already a thing, and typically has the opposite connotation: a compiler that must be trusted because we cannot verify the output. It's trusted because we "trust" it (to not screw up).

I would argue that this makes the compiler untrusted--we don't care what it does, whatever it outputs is going to be both statically and dynamically verified to not break the sandbox properties.

> Security based on process isolation is extremely inefficient and coarse-grained - having a trusted compiler could (eventually) massively increase performance by removing processes entirely (no more virtual memory! no more TLB flushes and misses! less task switch overhead!) and eliminating the kernel/user mode separation, with an increase in security.

I thought this right up until, well, about this time in 2017. Side-channel attacks are a real and bad thing. Our conclusion is that Spectre, in all its flavors, break confidentiality for in-process memory, regardless of sandboxing technology. On current hardware, there is no 100% bulletproof way to enforce isolation.

"Trustable" compiler, perhaps?

Trustworthy Compiler is the term we're looking for (analogous to trustworthy computing vs. trusted computing aka JANUS/Intel ME/etc)

Well yeah isn't the same thing then ? The resulting code is plain x86 assembly, and you just trust it to have been sanitized by its transformation to/from WASM. Looks like your definition of a trusted compiler to me.

> a compiler that emits trustable code, regardless of how untrusted the source is

Hasn't this been one of the goals of the design of WebAssembly since day one, and something that has been getting people excited about it too? Using something for one of its intended purposes isn't really a "hack", no?

The hack is translating wasm back to C, then compiling again. It wouldn’t be a hack if they’re running wasm, but they’re not.

AFAIK the ability to compile wasm to native code was pretty much always part of the goal, running wasm in a VM was never the end-game.

Compiling via C might be considered a hack (especially in the sense that it introduces a potential weak link in the chain), but it makes a lot of sense since they want to integrate the result into the Firefox build artefacts, and compiling via C is not exactly novel either.

Sort of. The main goal for WebAssembly is to be a fast platform-agnostic compilation target that you can use in websites. The "in websites" bit means that it has to be completely safe (i.e. no accessing outside memory etc.) but it's not the main goal.

This is a bit of a hack because Mozilla don't care about the platform-agnostic bit, so they're taking LLVM IR, compiling it to WebAssembly, then back to LLVM IR just so that they can ensure that the code is safe.

WebAssembly comes with extra constraints that you probably don't care about if you're compiling to native (e.g. there's no 'goto') so you would get more efficient code (and probably faster compilation) if you just had some way of compiling LLVM IR directly to "safe binary".

That would probably be a mountain of work though so its understandable why they went with this. Would be nice if they said how much the performance was impacted.

In 2021, the world finally achieves AS/400 on the web.

Can you expand on that? Was this a property of C compilers or other languages on IBM mainframes?

I get that it's tongue in cheek, but it would probably be even funnier / ironic if I had more context to understand it.

It's the same spirit as languages adopting functional programming techniques aka rediscovering Lisp.

AS/400 had a machine-independent binary format which was translated ahead of execution by the system's specific compiler into machine code, and all applications ran in the same address space with zero memory protection because the code generated by the compiler ensured isolation.

Oh wow. So again, we have come a full circle?

Incredible, I always thought that was an idea worth exploring. AOT compilation and not paying the cost of context and MMU switch would unlock incredible performance boosts, even on modern processors. I didn't know AS/400 did that already.

IIRC Microsoft explored something similar with their research OS Singularity.

>because the code generated by the compiler ensured isolation

That's fascinating. How does it do so? I thought it only separated the address space into user space and OS space.

I imagine that this was possible because the compiler had help from the AS400 architecture. In other words, doing this for a complex architecture like i64 would be much more difficult.

Modern AS/400 runs on PowerPC, the hardware is completly different from the early 1980's models.

I understand the ISA abstraction. That’s pretty common.

I’m interested in how the compiler ensures process isolation.

From the same era: https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...

No need for past tense, AS/400 still exists, just got the name changed to IBM i.

Yeah, it sounds like this is a clever hack to get clang to compile C code into a safe binary form; with runtime validation around pointers and array lookups and things.

I'm surprised clang doesn't simply have a mode to do this already. Its weird we need this strange wasm dance. I'm imagining a sort of a release mode version of ASAN + UBSAN where the compiled code has bounds checks for all array and pointer lookups. (And probably some more checks, besides). The rule is that it should be impossible for any binary code compiled this way to overrun arrays, or read or write memory outside of its allocated section. No matter the C code, the binary is memory-safe.

It would have a (modest) cost in runtime performance and binary size, but frankly that would be a trade off well worth making in all sorts of software we use daily.

> I'm surprised clang doesn't simply have a mode to do this already. Its weird we need this strange wasm dance

Compiling to WebAssembly doesn't make the code safe; it simply compiles it to a virtual machine with a memory model that isolates any bugs from the rest of the parent process (presuming a bug-free parent process).

Basically, all pointers in WebAssembly are indexes to a global array (or global arrays--one for data and another for functions). It's basically the same trick people use in Rust to get around restrictions on reference cycles. And like in Rust, the compiled code can still have the same dangling pointer and buffer overflow problems, but the memory thus referenced is restricted to the unstructured array, rather than to potentially any address in the parent process' address space.

The difference between Rust and WASM is that when you compile WASM to native code, at least when JIT'ing the code, you can completely elide the extra degree of memory reference indirection. (I don't think the extra indirection can be elided for AOT compilation of WASM code without a special runtime linking step.) The cost, however, is that you're left with this single global data array, so any bug in the WASM program can break any other part of the WASM program, whereas in Rust you effectively end up with many segments of unstructured memory (basically, one per component that uses the trick) that can't be cross-referenced if the program is buggy.

There's a very good reason such a thing doesn't exist: any C compiler that worked like that would break the vast majority of C programs.

Fundamentally, memory safety requires that you keep track of not just where a pointer currently points to, but where a pointer could validly point to. But, as applied in practice, the C ABI requires that pointers be integers of where it currently points to; making pointers also include range information (aka "fat" pointers) is possible, but requires rewriting almost any software you care about--it's the kind of change that's about as fundamental to C programs as assuming 2's complement arithmetic.

The way tools like ASAN and Valgrind work is by instead keeping track of where any pointer could point to (via shadow maps, basically a bit per memory location saying if you can read/write that location), and then padding every allocation with sufficient space that an innocuous read overflow (especially one-past-the-end) is likely to hit the padding. Their guarantees are at best probabilistic, not anything you would want to rely on for security.

Given that one can compile C to Wasm it is simply not true that it would break C code. Wasm implements pointers as offset into an array and then checks for out-of-bounds access. LLVM should be able to do that directly.

Most C and C++ code is perfectly happy with fat pointers provided you take care in how you implement them, especially around (u)intptr_t. For CHERI we see a very tiny % of LoC that need changing; e.g. http://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-ch... documents a recent case study in porting a KDE desktop stack (X11 itself, Qt, other standard graphical desktop libraries, Plasma, Dolphin, Okular) and across the 6 million LoC only 0.026% needed changing.

So, if you pick your fat pointer implementation poorly, then yes, you run up against both the standard and de-facto C, but if you take care then the vast majority of C code just works, and we're (uniquely?) positioned to be able to prove that by having a FreeBSD-based kernel and userspace, and graphical desktop stack (plus an adaptation of WebKit's JSC JIT) all built with a compiler that maps C pointers to capabilities that enforce fine-grained bounds.

> runtime validation around pointers and array lookups and things.

I think you're right but "validation around pointers and array lookups" makes it sound far better than it is. That sounds like the sort of strong validation is "safe" Rust gives you. But all it does is ensure the WASM virtual machine "executing" the WASM code doesn't access RAM outside of the VM's memory space. Everything in that memory space is fair game, so all the foot shooting stuff C allows like corrupting pointers and following them within that memory space is still possible.

It achieves what they want for security I guess, but not much more.

We will always need process boundaries to separate information domains, because side-channel vulnerabilities are not addressed by having a "trusted" compile step.

When it comes to side-channel attacks, process boundaries aren't adequate either. Rowhammer, Meltdown/Spectre, and friends show that handily, and the RSA key leakage attack using SDR shows that even machine isolation isn't going to be enough for some things.

I guess that the idea that trusted compilers are the way forward is predicated on the assumption that we've managed to mitigate most/all side-channel attacks, because there really isn't much you can do about those otherwise.

Those side channels existed because because they very clearly violated process isolation. Of course processes aren't going to isolate if your hardware ignores your isolation boundaries.

Enforcing this kind of isolation in software will likely be quite difficult though.

Why can't a trusted compiler prevent side-channel attacks? All you need to do is prevent the code from accessing the side channel. It seems to me that doing this at compile time would actually be easier than doing it at run time.

It is easy. You just have to forbid access to timers and loops. Where "timers" include anything that can count and store the count in shared memory.

Alternatively, you could forbid branches (and therefore loops, implicitly).

If you can use a loop for timing then you can use an unrolled loop for timing too.

But if you forbid those things, what's left? Loops and branches are what code is made of.

I presume that was meant to be facetious? But a clock is not the thing you would prevent access to. The thing you would prevent access to is whatever it is you want to try to time using that clock.

A key side-channel is execution time, and no, in general, you can't prevent a program from getting a clock. Even without a clock, one can construct one easily using shared memory and threads. Clocks are also easy to find. Even with low resolution clocks, timing differences can be amplified programmatically, making them observable.

The clock is not the thing you would prevent access to. The thing you would prevent access to is whatever it is you want to try to time using that clock.