6 ms·

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 ke

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.

toyg 12y ago
> 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.
- X-Istence 12y ago
  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.
  - transpute 12y ago
    Bromium does this for common apps (web, pdf, office) on Windows, e.g. each browser tab and HTTP request is a separate VM.
    - NickNameNick 12y ago
      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.
- blinkingled 12y ago
  That's way more heavy weight compared to regular seccomp like sandboxes that Chrome uses on Linux - and for too little gain.
  - mschuster91 12y ago
    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?)
    - 0x0 12y ago
      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.
      - mschuster91 12y ago
        > 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?
        wmf 12y ago
        Sure, that's like novm (https://github.com/google/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.
        mschuster91 12y ago
        20 kernels... well, not every kernel needs to be a full kernel. Maybe tiny microkernels?
        12y ago
mrsteveman1 12y ago
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 http://en.m.wikipedia.org/wiki/Qubes_OS
- protomyth 12y ago
  Where did they say they are locking down /System ?
  - mrsteveman1 12y ago
    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 https://developer.apple.com/videos/wwdc/2013/?id=707 [2] http://asciiwwdc.com/2013/sessions/707 http://asciiwwdc.com/2013/sessions/707
clinton_sf 12y ago
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.

toyg 12y ago

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

X-Istence 12y ago
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.
- transpute 12y ago
  Bromium does this for common apps (web, pdf, office) on Windows, e.g. each browser tab and HTTP request is a separate VM.
  - NickNameNick 12y ago
    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.
blinkingled 12y ago
That's way more heavy weight compared to regular seccomp like sandboxes that Chrome uses on Linux - and for too little gain.
- mschuster91 12y ago
  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?)
  - 0x0 12y ago
    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.
    - mschuster91 12y ago
      > 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?
      - wmf 12y ago
        Sure, that's like novm (https://github.com/google/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.
        mschuster91 12y ago
        20 kernels... well, not every kernel needs to be a full kernel. Maybe tiny microkernels?
        12y ago

mrsteveman1 12y ago

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 http://en.m.wikipedia.org/wiki/Qubes_OS

protomyth 12y ago
Where did they say they are locking down /System ?
- mrsteveman1 12y ago
  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 https://developer.apple.com/videos/wwdc/2013/?id=707 [2] http://asciiwwdc.com/2013/sessions/707 http://asciiwwdc.com/2013/sessions/707

clinton_sf 12y ago

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.