New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

create "do nothing" unikernel-based domain to isolate unused PCI devices #1743

Open
esheltone opened this Issue Feb 11, 2016 · 2 comments

Comments

Projects
None yet
4 participants
@esheltone

This is inspired by one user's isolation of the Intel HECI communication controller (often PCI device 00:16.0) to its own domain (see first attachment in https://groups.google.com/d/msg/qubes-devel/64-WJIMY18A/-nwwAmhlBAAJ). Although this doesn't mitigate ME's issues, it does reflect a good idea: minimize the devices that have access to dom0 (and vice versa). In other words, why allow a PCI device to be in dom0 if we're not using it, and we have an IOMMU that can isolate it elsewhere? By default, these devices are ending up in dom0. For example, a lot of laptops have a built in flash card reader that very few people make use of.

I propose creating a simple "do nothing" (it implements the minimal set of qrexec and qubesdb functions needed to start and stop cleanly under Qubes) unikernel-based domain whole sole purpose is to assign unused PCI devices to for isolation from dom0 via the IOMMU. The use of a unikernel would minimize the memory cost of the domain. The installer might even automatically assign the Intel HECI communication controller to this domain, along with any other often/always unused PCI devices.

@kbrn

This comment has been minimized.

Show comment
Hide comment
@kbrn

kbrn Feb 11, 2016

ISTM this would be hard to implement; given the diversity of hardware, use cases, etc., how can Qubes reliably determine which PCI devices are not needed? Asking the user seems problematic: can we really trust users to know which PCI devices they don't need in Dom0?

However, there are some good arguments for doing more than is done now: FireWire and ThunderBolt controllers, for example, should default to a quarantine domain, to prevent DMA attacks. I'm not sure if ExpressCard ports are assignable to a VM, but they should be included in this set, too, if possible.

Also, if going this route, it seems better to use one dedicated quarantine VM for each device rather than one for all, especially if using unikernels with negligible memory footprints.

In any case, I definitely support adding a quarantine unikernel VM type to the default distribution!

kbrn commented Feb 11, 2016

ISTM this would be hard to implement; given the diversity of hardware, use cases, etc., how can Qubes reliably determine which PCI devices are not needed? Asking the user seems problematic: can we really trust users to know which PCI devices they don't need in Dom0?

However, there are some good arguments for doing more than is done now: FireWire and ThunderBolt controllers, for example, should default to a quarantine domain, to prevent DMA attacks. I'm not sure if ExpressCard ports are assignable to a VM, but they should be included in this set, too, if possible.

Also, if going this route, it seems better to use one dedicated quarantine VM for each device rather than one for all, especially if using unikernels with negligible memory footprints.

In any case, I definitely support adding a quarantine unikernel VM type to the default distribution!

@liilac

This comment has been minimized.

Show comment
Hide comment
@liilac

liilac Jul 4, 2016

Is it necessary to have anything other than the BIOS in a quarantine VM?

liilac commented Jul 4, 2016

Is it necessary to have anything other than the BIOS in a quarantine VM?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment