linux-kernel - Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted

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: <d5b4f80db724da9d7571b614be76dd8b2b57432e.camel@kernel.crashing.org>
Date:   Tue, 16 Jul 2019 09:24:06 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Thiago Jung Bauermann <bauerman@...ux.ibm.com>,
        "Michael S. Tsirkin" <mst@...hat.com>
Cc:     virtualization@...ts.linux-foundation.org,
        linuxppc-dev@...ts.ozlabs.org, iommu@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, Jason Wang <jasowang@...hat.com>,
        Christoph Hellwig <hch@....de>,
        David Gibson <david@...son.dropbear.id.au>,
        Alexey Kardashevskiy <aik@...ux.ibm.com>,
        Paul Mackerras <paulus@...abs.org>,
        Ram Pai <linuxram@...ibm.com>,
        Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        Michael Roth <mdroth@...ux.vnet.ibm.com>,
        Mike Anderson <andmike@...ux.ibm.com>
Subject: Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is
 encrypted

On Mon, 2019-07-15 at 19:03 -0300, Thiago Jung Bauermann wrote:
> > > Indeed. The idea is that QEMU can offer the flag, old guests can
> > > reject
> > > it (or even new guests can reject it, if they decide not to
> > > convert into
> > > secure VMs) and the feature negotiation will succeed with the
> > > flag
> > > unset.
> > 
> > OK. And then what does QEMU do? Assume guest is not encrypted I
> > guess?
> 
> There's nothing different that QEMU needs to do, with or without the
> flag. the perspective of the host, a secure guest and a regular guest
> work the same way with respect to virtio.

This is *precisely* why I was against adding a flag and touch the
protocol negociation with qemu in the first place, back when I cared
about that stuff...

Guys, this has gone in circles over and over again.

This has nothing to do with qemu. Qemu doesn't need to know about this.
It's entirely guest local. This is why the one-liner in virtio was a
far better and simpler solution.

This is something the guest does to itself (with the participation of a
ultravisor but that's not something qemu cares about at this stage, at
least not as far as virtio is concerned).

Basically, the guest "hides" its memory from the host using a HW secure
memory facility. As a result, it needs to ensure that all of its DMA
pages are bounced through insecure pages that aren't hidden. That's it,
it's all guest side. Qemu shouldn't have to care about it at all.

Cheers,
Ben.