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
| ||
|
Date: Sun, 29 Mar 2020 08:25:05 -0400 From: "Michael S. Tsirkin" <mst@...hat.com> To: Eugenio Perez Martin <eperezma@...hat.com> Cc: "virtualization@...ts.linux-foundation.org" <virtualization@...ts.linux-foundation.org>, Halil Pasic <pasic@...ux.ibm.com>, Stephen Rothwell <sfr@...b.auug.org.au>, Linux Next Mailing List <linux-next@...r.kernel.org>, kvm list <kvm@...r.kernel.org>, Cornelia Huck <cohuck@...hat.com>, Christian Borntraeger <borntraeger@...ibm.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 0/6] vhost: Reset batched descriptors on SET_VRING_BASE call On Sun, Mar 29, 2020 at 02:19:55PM +0200, Eugenio Perez Martin wrote: > On Sun, Mar 29, 2020 at 1:49 PM Michael S. Tsirkin <mst@...hat.com> wrote: > > > > On Sun, Mar 29, 2020 at 01:33:53PM +0200, Eugenio Pérez wrote: > > > Vhost did not reset properly the batched descriptors on SET_VRING_BASE event. Because of that, is possible to return an invalid descriptor to the guest. > > > This series ammend this, and creates a test to assert correct behavior. To do that, they need to expose a new function in virtio_ring, virtqueue_reset_free_head. Not sure if this can be avoided. > > > > Question: why not reset the batch when private_data changes? > > At the moment both net and scsi poke at private data directly, > > if they do this through a wrapper we can use that to > > 1. check that vq mutex is taken properly > > 2. reset batching > > > > This seems like a slightly better API > > > > I didn't do that way because qemu could just SET_BACKEND to -1 and > SET_BACKEND to the same one, with no call to SET_VRING. In this case, > I think that qemu should not change the descriptors already pushed. Well dropping the batch is always safe, batch is an optimization. > I > do agree with the interface to modify private_data properly (regarding > the mutex). > > However, I can see how your proposal is safer, so we don't even need > to check if private_data is != NULL when we have descriptors in the > batch_descs array. Also, this ioctls should not be in the hot path, so > we can change to that mode anyway. > > > > > > > Also, change from https://lkml.org/lkml/2020/3/27/108 is not included, that avoids to update a variable in a loop where it can be updated once. > > > > > > This is meant to be applied on top of eccb852f1fe6bede630e2e4f1a121a81e34354ab in git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git, and some commits should be squashed with that series. > > > > Thanks a lot! I'll apply this for now so Christian can start testing, > > but I'd like the comment above addressed before I push this to Linus. > > > > > Eugenio Pérez (6): > > > tools/virtio: Add --batch option > > > tools/virtio: Add --batch=random option > > > tools/virtio: Add --reset=random > > > tools/virtio: Make --reset reset ring idx > > > vhost: Delete virtqueue batch_descs member > > > fixup! vhost: batching fetches > > > > > > drivers/vhost/test.c | 57 ++++++++++++++++ > > > drivers/vhost/test.h | 1 + > > > drivers/vhost/vhost.c | 12 +++- > > > drivers/vhost/vhost.h | 1 - > > > drivers/virtio/virtio_ring.c | 18 +++++ > > > include/linux/virtio.h | 2 + > > > tools/virtio/linux/virtio.h | 2 + > > > tools/virtio/virtio_test.c | 123 +++++++++++++++++++++++++++++++---- > > > 8 files changed, 201 insertions(+), 15 deletions(-) > > > > > > -- > > > 2.18.1 > >
Powered by blists - more mailing lists