On Wed, Apr 29, 2020 at 01:42:13PM +0800, Lu Baolu wrote:
On 2020/4/29 12:57, Michael S. Tsirkin wrote:Oh, thanks for that! I didn't realize Linux is doing this.
On Wed, Apr 29, 2020 at 10:22:32AM +0800, Lu Baolu wrote:No. I am talking about untrusted devices like thunderbolt peripherals.
On 2020/4/29 4:41, Michael S. Tsirkin wrote:I think you are talking about untrusted*drivers* like with VFIO.
On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote:For untrusted devices, IOMMU is forced on even iommu=pt is used;
* Michael S. Tsirkin<mst@xxxxxxxxxx> [2020-04-28 12:17:57]:Even a hardware iommu does not imply a 100% security from malicious
Okay, but how is all this virtio specific? For example, why not allowIs swiotlb commonly used for multiple devices that may be on different trust
separate swiotlbs for any type of device?
For example, this might make sense if a given device is from a
different, less trusted vendor.
boundaries (and not behind a hardware iommu)?
hardware. First lots of people use iommu=pt for performance reasons.
Second even without pt, unmaps are often batched, and sub-page buffers
might be used for DMA, so we are not 100% protected at all times.
We always trust drivers hosted in kernel and the DMA APIs are designed
for them, right?
Please refer to this series.
https://lkml.org/lkml/2019/9/6/39
Best regards,
baolu
So it seems that with modern Linux, all one needs
to do on x86 is mark the device as untrusted.
It's already possible to do this with ACPI and with OF - would that be
sufficient for achieving what this patchset is trying to do?
Adding more ways to mark a device as untrusted, and adding
support for more platforms to use bounce buffers
sounds like a reasonable thing to do.