3 ms·

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?
        0x0 12y ago
        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?
        mschuster91 12y ago
        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.
        0x0 12y ago
        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.
        wmf 12y ago
        I encourage both of you to check out picoprocesses: http://research.microsoft.com/en-us/projects/drawbridge/ http://research.microsoft.com/en-us/projects/drawbridge/

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?
      - 0x0 12y ago
        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?
        mschuster91 12y ago
        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.
        0x0 12y ago
        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.
        wmf 12y ago
        I encourage both of you to check out picoprocesses: http://research.microsoft.com/en-us/projects/drawbridge/ http://research.microsoft.com/en-us/projects/drawbridge/