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: <3d6e81511571260de1c8047aaffa8ac4df093d2e.camel@kernel.crashing.org>
Date:   Tue, 31 Jul 2018 15:36:22 -0500
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Christoph Hellwig <hch@...radead.org>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     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-07-31 at 10:30 -0700, Christoph Hellwig wrote:
> > However the question people raise is that DMA API is already full of
> > arch-specific tricks the likes of which are outlined in your post linked
> > above. How is this one much worse?
> 
> None of these warts is visible to the driver, they are all handled in
> the architecture (possibly on a per-bus basis).
> 
> So for virtio we really need to decide if it has one set of behavior
> as specified in the virtio spec, or if it behaves exactly as if it
> was on a PCI bus, or in fact probably both as you lined up.  But no
> magic arch specific behavior inbetween.

The only arch specific behaviour is needed in the case where it doesn't
behave like PCI. In this case, the PCI DMA ops are not suitable, but in
our secure VMs, we still need to make it use swiotlb in order to bounce
through non-secure pages.

It would be nice if "real PCI" was the default but it's not, VMs are
created in "legacy" mode all the times and we don't know at VM creation
time whether it will become a secure VM or not. The way our secure VMs
work is that they start as a normal VM, load a secure "payload" and
call the Ultravisor to "become" secure.

So we're in a bit of a bind here. We need that one-liner optional arch
hook to make virtio use swiotlb in that "IOMMU bypass" case.

Ben.