linux-kernel - Re: [PATCH v2] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL

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:   Tue, 7 Jan 2020 02:06:13 -0500
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     linux-kernel@...r.kernel.org, Alistair Delva <adelva@...gle.com>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org
Subject: Re: [PATCH v2] virtio_net: CTRL_GUEST_OFFLOADS depends on CTRL_VQ

On Tue, Jan 07, 2020 at 10:29:08AM +0800, Jason Wang wrote:
> 
> On 2020/1/6 下午8:54, Michael S. Tsirkin wrote:
> > On Mon, Jan 06, 2020 at 10:47:35AM +0800, Jason Wang wrote:
> > > On 2020/1/5 下午9:22, Michael S. Tsirkin wrote:
> > > > The only way for guest to control offloads (as enabled by
> > > > VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) is by sending commands
> > > > through CTRL_VQ. So it does not make sense to
> > > > acknowledge VIRTIO_NET_F_CTRL_GUEST_OFFLOADS without
> > > > VIRTIO_NET_F_CTRL_VQ.
> > > > 
> > > > The spec does not outlaw devices with such a configuration, so we have
> > > > to support it. Simply clear VIRTIO_NET_F_CTRL_GUEST_OFFLOADS.
> > > > Note that Linux is still crashing if it tries to
> > > > change the offloads when there's no control vq.
> > > > That needs to be fixed by another patch.
> > > > 
> > > > Reported-by: Alistair Delva <adelva@...gle.com>
> > > > Reported-by: Willem de Bruijn <willemdebruijn.kernel@...il.com>
> > > > Fixes: 3f93522ffab2 ("virtio-net: switch off offloads on demand if possible on XDP set")
> > > > Signed-off-by: Michael S. Tsirkin <mst@...hat.com>
> > > > ---
> > > > 
> > > > Same patch as v1 but update documentation so it's clear it's not
> > > > enough to fix the crash.
> > > > 
> > > >    drivers/net/virtio_net.c | 9 +++++++++
> > > >    1 file changed, 9 insertions(+)
> > > > 
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index 4d7d5434cc5d..7b8805b47f0d 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -2971,6 +2971,15 @@ static int virtnet_validate(struct virtio_device *vdev)
> > > >    	if (!virtnet_validate_features(vdev))
> > > >    		return -EINVAL;
> > > > +	/* VIRTIO_NET_F_CTRL_GUEST_OFFLOADS does not work without
> > > > +	 * VIRTIO_NET_F_CTRL_VQ. Unfortunately spec forgot to
> > > > +	 * specify that VIRTIO_NET_F_CTRL_GUEST_OFFLOADS depends
> > > > +	 * on VIRTIO_NET_F_CTRL_VQ so devices can set the later but
> > > > +	 * not the former.
> > > > +	 */
> > > > +	if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ))
> > > > +			__virtio_clear_bit(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS);
> > > 
> > > If it's just because a bug of spec, should we simply fix the bug and fail
> > > the negotiation in virtnet_validate_feature()?
> > One man's bug is another man's feature: arguably leaving the features
> > independent in the spec might allow reuse of the feature bit without
> > breaking guests.
> > 
> > And even if we say it's a bug we can't simply fix the bug in the
> > spec: changing the text for a future version does not change the fact
> > that devices behaving according to the spec exist.
> > 
> > > Otherwise there would be inconsistency in handling feature dependencies for
> > > ctrl vq.
> > > 
> > > Thanks
> > That's a cosmetic problem ATM. It might be a good idea to generally
> > change our handling of dependencies, and clear feature bits instead of
> > failing probe on a mismatch.
> 
> 
> Something like I proposed in the past ? [1]
> 
> [1] https://lore.kernel.org/patchwork/patch/519074/


No that still fails probe.

I am asking whether it's more future proof to fail probe
on feature combinations disallowed by spec, or to clear bits
to get to an expected combination.

In any case, we should probably document in the spec how
drivers behave on such combinations.


> 
> >   It's worth thinking  - at the spec level -
> > how we can best make the configuration extensible.
> > But that's not something spec should worry about.
> > 
> > 
> > > > +
> > > >    	if (virtio_has_feature(vdev, VIRTIO_NET_F_MTU)) {
> > > >    		int mtu = virtio_cread16(vdev,
> > > >    					 offsetof(struct virtio_net_config,