On 17/01/2017 12:51, Zrubi wrote: > On 01/17/2017 11:14 AM, [email protected] wrote: > > I'm not a Xen expert, so don't flog me too harshly, and I did > > search the posts for this subject, but couldn't find it. > > > There is a painfully well known problem of having to "trust" Intel > > to properly implement their "Intel Management Engine". Only very > > recently has there been a hardware solution to fixing that problem > > on more recent chipsets, however, I have not heard much from the > > Qubes community on this point. Reference: > > http://hackaday.com/2016/11/28/neutralizing-intels-management-engine/ > > > Xen is capable of booting a VM with its own BIOS. Why would it not > > be possible, for extreme privacy cases, to Xen virtualize Qubes > > (nested VMs) such that IME does not matter, as IME would only > > affect Xen on the hardware, not the VM with the open source BIOS > > which is running Qubes. Reference: > > https://wiki.xenproject.org/wiki/Hvmloader > > > Well it doesn't matter what you try to achieve in a top level VM if > the lower layers (AppVM -> dom0 -> Xen -> EFI/BIOS -> Hardware) are > powned. > > Lower 'layers' always owning the higher ones in any case. > > This is something that most of the people out there not takes into > account (and/or do not care about) > > > I would rather say that an adversary strong enough to pwn the lower layers isn't in most people's threat model, as the effort to defend against it ATM is not worth it for them.
-- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/387be49e-d6dc-50e3-2ad8-8cb9f86238fb%40nopping.eu. For more options, visit https://groups.google.com/d/optout.
