On 05/02/2017 05:25 AM, Vít Šesták wrote:
> * There seems to be some MEI PCI device (see lspci | grep -i mei) in dom0 and
> /dev/mei0. I am not sure how all the parts (network stack, MEI PCI device,
> MEI software for OS and management while offline) are connected together. I
> am also unsure if having it in dom0 is good (i.e., it prevents passing
> malicious inputs to it) or bad (i.e., it adds attack surface). The safest
> approach seems to be attaching it to /dev/null with IOMMU (VT-d) isolation.
> Just crerating an autostarted (and maybe also autoshutdown)
> network-disconnected dummy VM with all ME-related PCI devices should do the
> trick. The VM would be trusted not to pass any malicious input to MEI, but it
> would not be trusted for anything else (so that it could absorb attack from
> MEI). I am unsure if this adds some actual protection or if it is totally
> hopeless.
I remember a few days ago reading that you can talk to ME via SMBus, and
that is in fact the way ME talks to other components when the system is
off and therefore can't talk over PCI. PCI is obviously another way to
talk to ME.
Keeping them in dom0 won't hurt anything. The fact that ME cannot be
exploited locally from a VM (assuming the Qubes OS security model holds)
is enough to protect you from local exploits. In case of successful
exploitation. the ME has full access to RAM in any case, so moving them
to another VM won't give you any extra security.
--
Rudd-O
http://rudd-o.com/
--
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 qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/21446e90-3336-4d91-2249-9c60123a2b04%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.
