(VFIO) is untrusted, ok. But a malicious driver loaded into the kernel
address space would have much easier ways to corrupt the system than to
exploit lazy mode...
Yes, so that we have no need to consider untrusted drivers.
For (3), I agree that we should at least disallow lazy mode if
pci_dev->untrusted is set. At the moment it means that we require the
strictest IOMMU configuration for external-facing PCI ports, but it can
be extended to blacklist other vulnerable devices or locations.
I plan to add an attribute file for each device, espcially for hotplug devices.
And
let the root users to decide which mode should be used, strict or non-strict.
Becasue
they should known whether the hot-plug divice is trusted or not.
Aside from the problem that without massive implementation changes
strict/non-strict is at
best a per-domain property, not a per-device one, I can't see this being
particularly practical
- surely the whole point of a malicious endpoint is that it's going to pretend
to be some common
device for which a 'trusted' kernel driver already exists?
Yes, It should be assumed that all kernel drivers and all hard-wired devices
are trusted. There is
no reason to doubt that the open source drivers or the drivers and devices
provided by legitimate
suppliers are malicious.
If you've chosen to trust *any* external device, I think you may as well have
just set non-strict globally anyway.
The effort involved in trying to implement super-fine-grained control seems
hard to justify.
The default mode of external devices is strict, it can be obviously changed to
non-strict mode. But as
you said, it maybe hard to be implemented. In addition, bring a malicious
device into computer room,
attach and export data it's not easy also. Maybe I should follow
Jean'suggestion first,
add a config item.
+1
On another topic, we did also see a use case for selectively
passthrough'ing devices.
Typically, having the kernel use the identity mapping for when driving a
device is fine. In fact, having the IOMMU translating puts a big
performance burden on the system. However sometimes we may require the
IOMMU involved for certain devices, like for when the kernel device
driver has big contiguous DMA requirements, which is the case for some
RDMA NIC cards.
John
Robin.
If you do (3) then maybe we don't need (1) and (2), which require a
tonne of work in the DMA and IOMMU layers (but would certainly be nice
to see, since it would also help handle ATS invalidation timeouts)
Thanks,
Jean
So that some high-end trusted devices use non-strict mode, and keep others
still using
strict mode. The drivers who want to use non-strict mode, should change to use
new APIs
by themselves.
Why not keep the policy to secure by default, as we do for
iommu.passthrough? And maybe add something similar to
CONFIG_IOMMU_DEFAULT_PASSTRHOUGH? It's easy enough for experts to pass a
command-line argument or change the default config.
Sorry for the late reply, it was Chinese new year, and we had a long discussion
internally, we are fine to add a Kconfig but not sure OS vendors will set it
to default y.
OS vendors seems not happy to pass a command-line argument, to be honest,
this is our motivation to enable non-strict as default. Hope OS vendors
can see this email thread, and give some input here.
Thanks
Hanjun
.
.
.