>Tails: >>* What means, first to enhance QEMU. In general (without ARM and QEMU) *>>* this is - as far as I understood - the idea of the QubeOS. * >Right. The biggest challenge here is integrating the isolation by >virtualization without harming user experience too much. If/once we >have that, using x86 or ARM virtual machines might be a detail.
>We have no clear long-term plans wrt. isolation by virtualization. >This topic raises many questions, for example because I doubt we'll >want to raise hardware requirements significantly, so requiring VT-x >and/or VT-d is probably a non-starter for the primary use cases >supported by Tails. We're in the process of organizing a meeting with >Qubes OS, Whonix and Subgraph; my personal top priority there will be >to discuss this very topic, and get a better idea of what we could do, >how, and when. >Cheers, >-- >intrigeri I've created a project or two regarding XEN's platform used in QubeOS. Just keep in mind that you will be grandfathering in all bugs relating to the virtualization engine. If you would like to see the exposure then look at x86_emulate.c specifically. It wouldn't be too difficult to escape the VM in general so I think it might be worth just adding some direct exploit mitigation techniques rather than assuming virtualization will suffice. You can always force x86_emulate.c's C (gcc/clang) alternative of each instruction rather than the hardware layer that you are expecting it to be executing on.. Several portions of its engine are pretty nasty in particular especially when the Intel books are really confusing.. I've read 1:1 Intel manuals to their implementations in the past.. Just a thought.. shoot me an e-mail if you ever want anymore information or to discuss either.. Thanks, Mike
_______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
