linux-kernel - Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers

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: <c7c5e449-3df1-4162-b5ef-c9e05945d22b@amd.com>
Date: Thu, 3 Apr 2025 16:34:04 +0800
From: Zhu Lingshan <lingshan.zhu@....com>
To: David Woodhouse <dwmw2@...radead.org>, "Michael S. Tsirkin"
 <mst@...hat.com>
Cc: virtio-comment@...ts.linux.dev, hch@...radead.org,
 Claire Chang <tientzu@...omium.org>,
 linux-devicetree <devicetree@...r.kernel.org>,
 Rob Herring <robh+dt@...nel.org>, Jörg Roedel
 <joro@...tes.org>, iommu@...ts.linux-foundation.org,
 linux-kernel@...r.kernel.org, graf@...zon.de
Subject: Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of
 SWIOTLB bounce buffers

On 4/3/2025 4:22 PM, David Woodhouse wrote:
> On Thu, 2025-04-03 at 04:13 -0400, Michael S. Tsirkin wrote:
>> On Thu, Apr 03, 2025 at 08:54:45AM +0100, David Woodhouse wrote:
>>> On Thu, 2025-04-03 at 03:34 -0400, Michael S. Tsirkin wrote:
>>>> Indeed I personally do not exactly get why implement a virtual system
>>>> without an IOMMU when virtio-iommu is available.
>>>>
>>>> I have a feeling it's about lack of windows drivers for virtio-iommu
>>>> at this point.
>>> And a pKVM (etc.) implementation of virtio-iommu which would allow the
>>> *trusted* part of the hypervisor to know which guest memory should be
>>> shared with the VMM implementing the virtio device models?
>> Is there a blocker here?
> Only the amount of complexity in what should be a minimal Trusted
> Compute Base. (And ideally subject to formal methods of proving its
> correctness too.)
>
> And frankly, if we were going to accept a virtio-iommu in the TCB why
> not just implement enough virtqueue knowledge to build something where
> the trusted part just snoops on the *actual* e.g. virtio-net device to
> know which buffers the VMM was *invited* to access, and facilitate
> that?
you trust CPU  and its IOMMU, and the virtio-iommu is provided by the hypervisor,
emulated by the CPU. If you don't trust virtio-iommu, then you should not trust
the bounce buffer, because it is unencrypted, more like a security leak.

Actually everything is suspicious even the CPU, but you have to trust a TCB and
try to minimize the TCB. I remember there is an attestation mechanism to help
examine the infrastructure.  We need a balance and a tradeoff.

Thanks
Zhu Lingshan
>
> We looked at doing that. It's awful.
>
>>> You'd also end up in a situation where you have a virtio-iommu for some
>>> devices, and a real two-stage IOMMU (e.g. SMMU or AMD's vIOMMU) for
>>> other devices. Are guest operating systems going to cope well with
>>> that?
>> They should. In particular because systems with multiple IOMMUs already
>> exist.
>>
>>> Do the available discovery mechanisms for all the relevant IOMMUs
>>> even *allow* for that to be expressed?
>> I think yes. But, it's been a while since I played with this, let me
>> check what works, what does not, and get back to you on this.
> Even if it could work in theory, I'll be astonished if it actually
> works in practice across a wide set of operating systems, and if it
> *ever* works for Windows.
>
> Compared with the simple option of presenting a device which
> conceptually doesn't even *do* DMA, which is confined to its own
> modular device driver...