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.