Sounds like an interesting framework, my quick search didn't unearth any docs for it though? The only reference on Apples website is "we added this to 10.10"
> Hypervisor (Hypervisor.framework). The Hypervisor framework allows virtualization vendors to build virtualization solutions on top of OS X without needing to deploy third-party kernel extensions (KEXTs). Included is a lightweight hypervisor that enables virtualization of the host CPUs.
As with all Mac frameworks, the full headers are embedded in the framework and the headers all have full Javadoc-style API documentation for each function. Since there are only 24 functions in the whole framework, that's probably enough to work it out.
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.
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
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. 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.
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.
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.
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.
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.
This reminds me of vx32[0], a user level emulation library that seems to target the same interface. One of the main applications using it is 9vx, which is basically a Plan 9 kernel running in userspace.
