linux-kernel - Re: [RFC 0/4] Virtio uses DMA API for all devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8e00f0310fa78882d3d32270c03b0b6257f35f83.camel@kernel.crashing.org>
Date:   Tue, 07 Aug 2018 09:16:43 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Will Deacon <will.deacon@....com>,
        Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        aik@...abs.ru, robh@...nel.org, joe@...ches.com,
        elfring@...rs.sourceforge.net, david@...son.dropbear.id.au,
        jasowang@...hat.com, mpe@...erman.id.au, linuxram@...ibm.com,
        haren@...ux.vnet.ibm.com, paulus@...ba.org,
        srikar@...ux.vnet.ibm.com, robin.murphy@....com,
        jean-philippe.brucker@....com, marc.zyngier@....com
Subject: Re: [RFC 0/4] Virtio uses DMA API for all devices

On Tue, 2018-08-07 at 08:13 +1000, Benjamin Herrenschmidt wrote:
> 
> OK well, assuming Christoph can solve the direct case in a way that
> also work for the virtio !iommu case, we still want some bit of logic
> somewhere that will "switch" to swiotlb based ops if the DMA mask is
> limited.
> 
> You mentioned an RFC for that ? Do you happen to have a link ?
> 
> It would be indeed ideal if all we had to do was setup some kind of
> bus_dma_mask on all PCI devices and have virtio automagically insert
> swiotlb when necessary.

Actually... I can think of a simpler option (Anshuman, didn't you
prototype this earlier ?):

Since that limitaiton of requiring bounce buffering via swiotlb is true
of any device in a secure VM, whether it goes through the iommu or not,
the iommu remapping is essentially pointless.

Thus, we could ensure that the iommu maps 1:1 the swiotlb bounce buffer
(either that or we configure it as "disabled" which is equivalent in
this case).

That way, we can now use the basic swiotlb ops everywhere, the same
dma_ops (swiotlb) will work whether a device uses the iommu or not.

Which boils down now to only making virtio use dma ops, there is no
need to override the dma_ops.

Which means all we have to do is either make xen_domain() return true
(yuck) or replace that one test with arch_virtio_force_dma_api() which
resolves to xen_domain() on x86 and can do something else for us.

As to using a virtio feature flag for that, which is what Christoph
proposes, I'm not too fan of it because this means effectively exposing
this to the peer, ie the interface. I don't think it belong there. The
interface, from the hypervisor perspective, whether it's qemu, vmware,
hyperz etc... have no business knowing how the guest manages its dma
operations, and may not even be aware of the access limitations (in our
case they are somewhat guest self-imposed).

Now, if this flag really is what we have to do, then we'd probably need
a qemu hack which will go set that flag on all virtio devices when it
detects that the VM is going secure.

But I don't think that's where that information "need to use the dma
API even for direct mode" belongs.

Cheers,
Ben.