linux-kernel - Re: [PATCH V6 8/9] virtio: harden vring IRQ

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:   Wed, 15 Jun 2022 19:24:08 +0100
From:   Cristian Marussi <cristian.marussi@....com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        virtualization <virtualization@...ts.linux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Marc Zyngier <maz@...nel.org>,
        Halil Pasic <pasic@...ux.ibm.com>,
        Cornelia Huck <cohuck@...hat.com>,
        eperezma <eperezma@...hat.com>, Cindy Lu <lulu@...hat.com>,
        Stefano Garzarella <sgarzare@...hat.com>,
        Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
        Vineeth Vijayan <vneethv@...ux.ibm.com>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>,
        linux-s390@...r.kernel.org, conghui.chen@...el.com,
        Viresh Kumar <viresh.kumar@...aro.org>,
        netdev <netdev@...r.kernel.org>, pankaj.gupta.linux@...il.com,
        sudeep.holla@....com, Bjorn Andersson <bjorn.andersson@...aro.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>
Subject: Re: [PATCH V6 8/9] virtio: harden vring IRQ

On Wed, Jun 15, 2022 at 09:41:18AM +0800, Jason Wang wrote:
> On Wed, Jun 15, 2022 at 12:46 AM Cristian Marussi
> <cristian.marussi@....com> wrote:

Hi Jason,

> >
> > On Tue, Jun 14, 2022 at 03:40:21PM +0800, Jason Wang wrote:
> > > On Mon, Jun 13, 2022 at 5:28 PM Michael S. Tsirkin <mst@...hat.com> wrote:
> > > >
> >

[snip]

> > >
> > > >  arm_scmi
> > >
> > > It looks to me the singleton device could be used by SCMI immediately after
> > >
> > >         /* Ensure initialized scmi_vdev is visible */
> > >         smp_store_mb(scmi_vdev, vdev);
> > >
> > > So we probably need to do virtio_device_ready() before that. It has an
> > > optional rx queue but the filling is done after the above assignment,
> > > so it's safe. And the callback looks safe is a callback is triggered
> > > after virtio_device_ready() buy before the above assignment.
> > >
> >
> > I wanted to give it a go at this series testing it on the context of
> > SCMI but it does not apply
> >
> > - not on a v5.18:
> >
> > 17:33 $ git rebase -i v5.18
> > 17:33 $ git am ./v6_20220527_jasowang_rework_on_the_irq_hardening_of_virtio.mbx
> > Applying: virtio: use virtio_device_ready() in virtio_device_restore()
> > Applying: virtio: use virtio_reset_device() when possible
> > Applying: virtio: introduce config op to synchronize vring callbacks
> > Applying: virtio-pci: implement synchronize_cbs()
> > Applying: virtio-mmio: implement synchronize_cbs()
> > error: patch failed: drivers/virtio/virtio_mmio.c:345
> > error: drivers/virtio/virtio_mmio.c: patch does not apply
> > Patch failed at 0005 virtio-mmio: implement synchronize_cbs()
> >
> > - neither on a v5.19-rc2:
> >
> > 17:33 $ git rebase -i v5.19-rc2
> > 17:35 $ git am ./v6_20220527_jasowang_rework_on_the_irq_hardening_of_virtio.mbx
> > Applying: virtio: use virtio_device_ready() in virtio_device_restore()
> > error: patch failed: drivers/virtio/virtio.c:526
> > error: drivers/virtio/virtio.c: patch does not apply
> > Patch failed at 0001 virtio: use virtio_device_ready() in
> > virtio_device_restore()
> > hint: Use 'git am --show-current-patch=diff' to see the failed patch
> > When you have resolved this problem, run "git am --continue".
> >
> > ... what I should take as base ?
> 
> It should have already been included in rc2, so there's no need to
> apply patch manually.
> 

I tested this series as included in v5.19-rc2 (WITHOUT adding a virtio_device_ready
in SCMI virtio as you mentioned above ... if I got it right) and I have NOT seen any
issue around SCMI virtio using my usual test setup (using both SCMI vqueues).

No anomalies even when using SCMI virtio in atomic/polling mode.

Adding a virtio_device_ready() at the end of the SCMI virtio probe()
works fine either, it does not make any difference in my setup.
(both using QEMU and kvmtool with this latter NOT supporting
 virtio_V1...not sure if it makes a difference but I thought was worth
 mentioning)

Thanks,
Cristian