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: <CAD60JZMbbkwFHqCm_iCrOrKgRLBUMkDQfuJ=Q1T-sZt59eTBrw@mail.gmail.com>
Date:   Sat, 6 Aug 2022 06:52:15 -0400
From:   Stefan Hajnoczi <shajnocz@...hat.com>
To:     Will Deacon <will@...nel.org>
Cc:     Stefano Garzarella <sgarzare@...hat.com>, mst@...hat.com,
        Stefan Hajnoczi <stefanha@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        torvalds@...ux-foundation.org, 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
Subject: Re: IOTLB support for vhost/vsock breaks crosvm on Android

On Sat, Aug 6, 2022 at 5:50 AM Will Deacon <will@...nel.org> wrote:
> On Sat, Aug 06, 2022 at 09:48:28AM +0200, Stefano Garzarella wrote:
> > On Fri, Aug 05, 2022 at 07:11:06PM +0100, Will Deacon wrote:
> > If the VMM implements the translation feature, it is right in my opinion
> > that it does not enable the feature for the vhost device. Otherwise, if it
> > wants the vhost device to do the translation, enable the feature and send
> > the IOTLB messages to set the translation.
> >
> > QEMU for example masks features when not required or supported.
> > crosvm should negotiate only the features it supports.
> >
> > @Michael and @Jason can correct me, but if a vhost device negotiates
> > VIRTIO_F_ACCESS_PLATFORM, then it expects the VMM to send IOTLB messages to
> > set the translation.
>
> As above, the issue is that vhost now unconditionally advertises this in
> VHOST_GET_FEATURES and so a VMM with no knowledge of IOTLB can end up
> enabling it by accident.

Unconditionally exposing all vhost feature bits to the guest is
incorrect. The emulator must filter out only the feature bits that it
supports.

For example, see QEMU's vhost-net device's vhost feature bit allowlist:
https://gitlab.com/qemu-project/qemu/-/blob/master/hw/net/vhost_net.c#L40

The reason why the emulator (crosvm/QEMU/etc) must filter out feature
bits is that vhost devices are full VIRTIO devices. They are a subset
of a VIRTIO device and the emulator is responsible for the rest of the
device. Some features will require both vhost and emulator support.
Therefore it is incorrect to expect the device to work correctly if
the vhost feature bits are passed through to the guest.

Stefan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ