linux-kernel - Re: [PATCH v1] s390/vfio-ap: Signal eventfd when guest AP configuration is changed

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: <d31e8a98-a87e-41dd-ba41-ba8ac45eadba@linux.ibm.com>
Date: Fri, 17 Jan 2025 07:53:51 -0500
From: Anthony Krowiak <akrowiak@...ux.ibm.com>
To: Halil Pasic <pasic@...ux.ibm.com>
Cc: Alex Williamson <alex.williamson@...hat.com>,
        Rorie Reyes <rreyes@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org, hca@...ux.ibm.com,
        borntraeger@...ibm.com, agordeev@...ux.ibm.com, gor@...ux.ibm.com,
        jjherne@...ux.ibm.com
Subject: Re: [PATCH v1] s390/vfio-ap: Signal eventfd when guest AP
 configuration is changed




On 1/16/25 2:30 PM, Halil Pasic wrote:
> On Thu, 16 Jan 2025 10:38:41 -0500
> Anthony Krowiak <akrowiak@...ux.ibm.com> wrote:
>
>>> Alex, does the above answer your question on what guards against UAF (the
>>> short answer is: matrix_dev->mdevs_lock)?
>> I agree that the matrix_dev->mdevs_lock does prevent changes to
>> matrix_mdev->cfg_chg_trigger while it is being accessed by the
>> vfio_ap device driver. My confusion arises from my interpretation of
>> Alex's question; it seemed to me that he was talking its use outside
>> of the vfio_ap driver and how to guard against that.
> BTW the key for understanding how we are protected form something
> like userspace closing he eventfd is that eventfd_ctx_fdget()
> takes a reference to the internal eventfd context,  which makes
> sure userspace can not shoot us in the foot and the context
> remains to be safe to use until we have done our put. Generally
> userspace is responsible for not shooting itself in the foot,
> so how QEMU uses its end is mostly QEMUs problem in my understanding.

I started digging through that code to try to find the reference to the
eventfd and whether/how it is protected, but got lost in the
twists and turns. Thanks for the info.

>
> Regards,
> Halil