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

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