4 ms·
A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software as native blobs and
by BeeOnRope 9y ago
A major underlying cause is that we're doing things in hardware that ought to be done in software. We really need to stop shipping software as native blobs and start shipping it as pseudocode, allowing the OS to manage native execution. This would allow the kernel and OS to do tons and tons of stuff the CPU currently does: process isolation, virtualization, much or perhaps even all address remapping, handling virtual memory, etc. CPUs could just present a flat 64-bit address space and run code in it.
The overall idea has a lot of merit (and, for example, Apple is moving towards this model with the iOS AppStore) - but I don't see how it solves the current problem.
Across a variety of architectures, the market has come down firmly in favor of hardware address translation and protection. There are various implementations, many not subject to the current side-channel, but all of them do most of the heavy lifting in hardware: TLBs and related things "just work".
Lets say you had some intermediate format and executed everything in a single 64-bit address space after a final JIT compilation step (your suggestion, as I understand it). How you would implement process and kernel memory protection? It amounts to a bounds-check on every memory access. Certainly you can use techniques common in bounds-checking JITs today to eliminate many of the checks via proof methods, hoisting and combining bounds checks, etc - but the cost would still be large in many cases.
Maybe you want a hardware assist for this bounds checking then? Well follow that to its logical conclusion and you end up with hardware protection support: maybe in a slightly different form than we have today, but hardware support nonetheless.
There are a lot things we could do differently with a clean-slate design, and I think intermediate representations have a lot of merit (e.g., the radical performance improvements partly as a result of radical architecture changes enabled by use of intermediate formats in the GPU space are evidence this works) - but hardware address translation doesn't seem like the problem here.
- api 9y agoBounds checking in hardware is an awesome idea. It's still simpler than full protection modes and is more versatile. Not only does it allow efficient software JIT implementation of protection but it also allows pervasive bounds checking to eliminate buffer overflows and other common errors. It eliminates the performance incentive for a lot of unsafe code. What I'm suggesting is not a total clean slate. It could be done easily on current processors or current instruction sets and would be more an omission than a change to core architecture. I wonder if doing it on current chips and just ignoring all the protection and remapping logic would have a performance benefit? Look at the boost you get on some databases with transparent hugepages, which kind of do that.