Hacker News Reader

Comment by blinkingled | Hacker News Reader

Gotta wonder who this is targeted towards - the likes of VMWare definitely not as I am sure they've spent a lot of time optimizing everything that happens in kernel space inside their drivers and surely there's more than 24 API calls they'll need inside the kernel to get something like Fusion working.

Maybe Apple is planning to provide a built-in hypervisor and this is just a start of it. Or maybe this is just for old DOS/Win games that'll sell for $9.99 in the appstore.

Also a cursory look shows the API is rather Intel specific. That's fine for the status quo but if they ever switch CPU vendors again wonder how this will work out.

View on HN

As someone else noted, QEMU is a likely match, perhaps another option for running Vagrant on OS X. But apple probably wouldn't go to this much effort and commit to supporting a hypervisor just to make virtualizing Linux easier. It's not an unmet need, and it's not their primary focus at all.

As you noted, all the existing VM players can provide their own and may want to continue doing that (unless Apple forces them to adopt this one... which is unlikely), so I'd bet on Apple itself being the primary consumer of it in some way.

As for what Apple itself might do with it in the future, perhaps this is just intended to be a low level component that will be used for other high level things in the OS itself, similar to the way XPC is now used all over the place as a core technology. As for what that might be with the hypervisor... I'd just be guessing. Guessing is fun though :)

They did say they were locking down /System soon, maybe that's going to be far more expansive than just the filesystem path, maybe a native hypervisor paired with VT-d allows them to "sandbox" things that currently can't be contained, even kexts? I'm thinking about Qubes OS when I say that http://en.m.wikipedia.org/wiki/Qubes_OS

Where did they say they are locking down /System ?

WWDC 2013 Session 707 "What's New in Kext Development" [1] is about kext signing and where 3rd party kexts should be placed in 10.9+. In the PDF slides you can see on slide 101:

"Get out of /System/Library/Extensions ... in fact ALL of /System (talk to us if you think you need to be here!)"

And then the major point which is only part of the spoken presentation and not IN the PDF itself:

"And another warning I'll throw out here is in the future as we start to lock down the /System folder, you might actually get write errors. So when you try to install a kernel extension into the /System folder, the write itself may fail."

That sounds like either read-only mounting of a separate partition, or kernel level write protection, or some similar solution.

If you want to read it instead of watching the video, you can visit the transcripts for this session over at asciiwwdc.com[2] and search for the phrase "lock down".

[1] https://developer.apple.com/videos/wwdc/2013/?id=707

[2] http://asciiwwdc.com/2013/sessions/707

Thanks, that is very good to know.

This approach solves a few problems:

1. Apps in the Mac App Store can't ship their own kernel extensions along with the app. With the framework, it may not be necessary for virtualization products to do that -- enabling them to ship in the Mac App Store.

2. Compatibility breaks between OS version updates. Every time the kernel interface changes, someone shipping a kernel extension will need to ship an update as well. With this approach, it's possible to keep compatibility and let the implementation of the framework do all the heavy lifting.

3. If virtualization products are going to be in the kernel in order to run, it would be better for the host OS vendor to supply official supported interfaces instead.

Just as Intel is making it easier to do virtualization on their chips with VT-x and VT-d, Apple is making it easier to implement virtualization with Mac OS X as a host with this framework.

> Or maybe this is just for old DOS/Win games that'll sell for $9.99 in the appstore.

Maybe it's the start of an "extreme sandbox" model, where appstore apps are all virtualized.

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/

Reply on news.ycombinator.com