Autore: Mike Guidry Data: To: tails-dev Oggetto: [Tails-dev] Suggestion to hep with exploit mitigation...
>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..