This is something I've been thinking about. What if we could easily allow all programs to be sandboxed using virtualisation technology? Run your web browser or parts thereof inside of a VM so that any exploits are limited to just that VM.

Bromium does this for common apps (web, pdf, office) on Windows, e.g. each browser tab and HTTP request is a separate VM.

It also alerts if a process does something 'weird', it allows exploits to run in a sandbox and records what they do, so you can analyse it later.

That's way more heavy weight compared to regular seccomp like sandboxes that Chrome uses on Linux - and for too little gain.

The question is, what exactly is the overhead of VT-d and friends, especially when done at OS-level (every process gets its own "virtual" cpu?)

Well, you would need to install 20 copies of OSX if you have 20 apps installed, for one.

Also, for a regular app process, standard unix-level memory protection plus sandboxing should be enough. Regular apps have no use for the virtual ring0 privileges available in a "bare-metal" environment that such virtualization emulates.

> Well, you would need to install 20 copies of OSX if you have 20 apps installed, for one.

Shouldn't it be possible to use bindmounts or other virtual filesystems for the core services?

Sure, that's like novm (https://github.com/google/novm). But you're still running 20 kernels. A picoprocess architecture is better, but I'd still go with containers.

20 kernels... well, not every kernel needs to be a full kernel. Maybe tiny microkernels?

But, you'd need a complete implementation of the OSX kernel and library API surface, because that's what an OSX app expects. If you're going to try to re-use the host kernel via a virtualCPU backdoor, you're not really virtualizing anything anymore and could just stick with the unix process model?

Not exactly, because using a separate CPU with a shared kernel can very effectively isolate processes from each other which is not possible with the unix process model. It would take either a serious kernel bug or a bug in the CPU hardware/microcode to cross the barrier in case of an exploit e.g. in a browser.

I'd rather see the sandbox model for process isolation improved, instead of trying to re-invent it from scratch with a virtual CPU that has backdoor traps for calling into the original kernel for almost everything. I'd think the attack surface would be about the same for that, and any kind of virtualization that is so lightweight that it reuses most of the host kernel. That's exactly the problem that the x86/x86_64 memory protection and CPU ring levels were intended to solve! :) Plus you won't have the stress of having to virtualize a separate network card, file system and memory map.

I encourage both of you to check out picoprocesses: http://research.microsoft.com/en-us/projects/drawbridge/