Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: iac594737:Fastmail
Date:   Fri, 7 Oct 2022 13:31:54 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Juergen Gross <jgross@suse.com>,
        "M. Vefa Bicakci" <m.v.b@runbox.com>,
        xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Cc:     Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH v2 0/2] xen/gntdev: Fixes for leaks and VMA splitting
Message-ID: <Y0BijRE6/gdBr9Bn@itl-email>
References: <20221002222006.2077-1-m.v.b@runbox.com>
 <9aa1e6ba-a153-8dfa-ce28-3ab78b26c6e4@suse.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="icHkrWgI+wqJhboV"
Content-Disposition: inline
In-Reply-To: <9aa1e6ba-a153-8dfa-ce28-3ab78b26c6e4@suse.com>
Precedence: bulk


--icHkrWgI+wqJhboV
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 7 Oct 2022 13:31:54 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Juergen Gross <jgross@suse.com>, "M. Vefa Bicakci" <m.v.b@runbox.com>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH v2 0/2] xen/gntdev: Fixes for leaks and VMA splitting

On Fri, Oct 07, 2022 at 07:17:41AM +0200, Juergen Gross wrote:
> On 03.10.22 00:20, M. Vefa Bicakci wrote:
> > Hi all,
> >=20
> > First of all, sorry for the delay!
> >=20
> > These patches continue the code review for the following patches:
> >    https://lore.kernel.org/xen-devel/20220912040002.198191-1-m.v.b@runb=
ox.com/t/#u
> >=20
> > The original description of the patch set is as follows:
> >=20
> >    "The changes in this patch series intend to fix the Xen grant device
> >    driver, so that grant mapping leaks caused by partially failed grant
> >    mapping operations are avoided with the first patch, and so that the
> >    splitting of VMAs does not result in incorrectly unmapped grant pages
> >    with the second patch. The second patch also prevents a similar issue
> >    in a double-mapping scenario, where mmap() is used with MAP_FIXED to
> >    map grants over an existing mapping created with the same grants, and
> >    where grant pages are unmapped incorrectly as well."
> >=20
> > A summary of the changes from v1 is as follows:
> > - Addressed Juergen's code review comment regarding the first patch.
> > - Amended the description of the second patch to note that the described
> >    issues are encountered with PV domains.
> >=20
> > Verification notes:
> >=20
> > - I have tested these commits on top of Linux v5.15.70 and v5.15.71, and
> >    I verified that they compile successfully on top of the tag
> >    "next-20220930", which corresponds to the base commit ID included at
> >    the bottom of this e-mail.
> >=20
> > - My tests consist of using a kernel with Qubes OS v4.1's patches and
> >    these patches on my main computer for day-to-day tasks, in conjuncti=
on
> >    with Qubes OS's version of the Xen hypervisor v4.14.5, with the latt=
er
> >    custom-compiled with CONFIG_DEBUG.
> >=20
> > - I used a test program that verifies the following scenarios with an
> >    unprivileged paravirtualized (PV) Xen domain:
> >=20
> >    - A program mmap()s two pages from another Xen domain and munmap()s
> >      the pages one by one. This used to result in implicit unmap errors
> >      to be reported by Xen and a general protection fault to be trigger=
ed
> >      by Xen in the affected domain, but now works as expected.
> >    - A program mmap()s two pages from another Xen domain and then
> >      attempts to remap (via MAP_FIXED) the same mapping again over the
> >      same virtual address. This used to result in similar issues
> >      (implicit unmap errors and general protection fault), but now is
> >      rejected by the kernel.
> >    - A program mmap()s two pages from another Xen domain and then
> >      attempts to mmap() the same mapping again to a different virtual
> >      address, by passing NULL as mmap()'s first argument. This used to =
be
> >      rejected by the kernel, and it continues to be rejected by the
> >      kernel.
> >=20
> > - Unprivileged PVH Xen domains were also sanity tested with the same
> >    test program. I should note that PVH domains worked as expected
> >    without these patches too.
> >=20
> > - Finally, I have verified that the original "g.e. 0x1234 still pending"
> >    issue does not appear after rapidly resizing GUI windows in Qubes OS
> >    v4.1.
>=20
> Series pushed to xen/tip.git for-linus-6.1

Thanks!
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--icHkrWgI+wqJhboV
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmNAYowACgkQsoi1X/+c
IsET/A//T7lUkkW0Asz4OA/e1UJcpTOuhv17BLYolj8QuDkNfiWix8EXsVX+BfkE
ok4HZW4qD6mYB3OzO0NjweeGQt7I1JtAxCu8uwlHA93f3vqRwntr/Cch7tDqloZ7
0P4YbGiyCzmCB3bsD6bh2AqsFO6uH0bIegiYOMLnXGcpDdQiiJx+wJ62LFqfW1A7
YkW3P0t6bDBFT90WBMy4v0apS4culhw5VOnLE6EIklj+xhSfZoags77z/Ua+Dg9w
blQAaS+bF4Evatf2ZwE/nfYGlPrbPYWRjh9T9kAyFO3PcwrppV1EiDLjM19lK8Vo
57DfdSpHBAmpFTLt4GFJyNf/AoB/jOlpw4LuVpLqgPVrWw17eEHNz7amK9bILJzo
3Y5R1xckDNg0rHyiVD+Vr27CSLadcCn6DSdnSuGOk3sT5iGaci8FGv3NRtOODS9J
MaiM7FyH4D7ttjrz+agrSFk/1/a2cbBKMAwBPy0qglfv8C/Alm11gZCojjFWxSAZ
O6gTN/MgbI7FUeYWX0fv9y6SzUurXG5lfxyTCQCSiECCnFbmuwBOa2W+br24AAgq
oKB38+t5Ax6ObXheQBMFhOm1WsD7Zln5YHLRWgC3Wu9ZSx836a1tey0oFJ5VNzrH
Y2M3ETghA702QUsZiBZX2wH38n+ttptCJotAvIh3bJv5ePia3ac=
=6gwm
-----END PGP SIGNATURE-----

--icHkrWgI+wqJhboV--