linux-kernel - Re: IOTLB support for vhost/vsock breaks crosvm on Android

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]

Date:   Sun, 7 Aug 2022 09:35:07 -0400
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Will Deacon <will@...nel.org>, stefanha@...hat.com,
        jasowang@...hat.com, ascull@...gle.com, maz@...nel.org,
        keirf@...gle.com, jiyong@...gle.com, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org,
        virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org,
        Stefano Garzarella <sgarzare@...hat.com>
Subject: Re: IOTLB support for vhost/vsock breaks crosvm on Android

On Sat, Aug 06, 2022 at 11:52:13PM -0700, Christoph Hellwig wrote:
> It really is vhost that seems to abuse it so that if the guest
> claims it can handle VIRTIO_F_ACCESS_PLATFORM (which every modern
> guest should) it enables magic behavior, which I don't think is what
> the virtio spec intended.

Well the magic behavour happens to be used by QEMU to
implement a virtual IOMMU. And when you have a virtual
IOMMU you generally want VIRTIO_F_ACCESS_PLATFORM.
This is how it came to be reused for that.

And since QEMU never passed guest features to vhost
unfiltered we never saw the issue even with old QEMU
versions on new kernels.

It seems natural to pass features unfiltered and we never even said
userspace should not do it, so it's quite understandable that this is
what corsvm did.

-- 
MST