Solving the IME Problem with Virtualization

[john.m...@gmail.com]

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

I realize this is hardly efficient, but, if it would work, it would eliminate having to "trust" Intel.

...or, what, would the Intel hardware still be able to peek into the the hardware, even though the hardware, the Xen VM with Qubes in it, and the Qubes VMs are all running VT-x and VT-d?

Thanks,

John E. Mayorga

[Zrubi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/17/2017 11:14 AM, john.m...@gmail.com 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)



- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYfgVFAAoJEH7adOMCkunmyQsP+QGLXmncVjEcHOZJjX1VgLpS
HUhOQoK9hCXzOpI1YiHpNGuA17YSBEgXB0TXxCwKk5If2voJiwde5ixysnnukqZL
4LFVu/D2vd+VyoJFwTQ7dO5dosIm66axin7TbXE4ejagKWYmDURhyEzkvKmiqz8q
ReJT4yy4xLwO8dtFh4E1hidvLVQ6jg6HGFww6ZenHDt15AHY7iMbd6pfoybDMyXH
Uifaqi/S8EMJjX9d3InR4rndYPRU8F0bl2W30aoq0raEisxuYAhauIBCb8jBFh6L
/XfE8oaWcsEt3M3TpNvU0TuWDQuHZqiorVuYfFsfliJDA96mPwbikiVNpc5HwcCJ
32r9Sim45It5A0clts6ub4nPtCy04Y6QaucA/nMAWclrud/bLxjaMujBwNDQX0XQ
Vwtr02wFkCKMyMjdse4uLZDeKAaHJRkrkBrhXehPMiTXYjvcx15Wp934o2VV7yPD
1v+tukvHMkbbPu03XjExRGoJs6a+3yrkHDQuNTOkEmOHZ2224GoyX0sSLX021enf
8FxXX6XkxWT/pSOpl5Gfa7kSaK9Nm8S1Q/bPFvS1gVX4rqB4MltXulXicAfBH1eU
b2iuj2Yn6Za6kSxcf9SM328cF9DIavSvns+7omOb/K8sE0e3hAvFw2xsPYPsnJES
tq8h2CGcFFgEFMB4JiUF
=ygdh
-----END PGP SIGNATURE-----

[Sae]

On 17/01/2017 12:51, Zrubi wrote:
> On 01/17/2017 11:14 AM, john.m...@gmail.com 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.