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:   Wed, 21 Sep 2022 21:53:47 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Ard Biesheuvel <ardb@kernel.org>, Jan Beulich <jbeulich@suse.com>
Cc:     Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
        xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3] Support ESRT in Xen dom0
Message-ID: <YyvATLLjX1jTOWGU@itl-email>
References: <20220919193257.2031-1-demi@invisiblethingslab.com>
 <CAMj1kXEBfJUfTQ3THqqKxsU09_S98B_TjTECKwGM0WAv_5tZaA@mail.gmail.com>
 <7930b617-d473-94dd-c7e4-33ffa19da13e@suse.com>
 <CAMj1kXEJ9d3-8xa7rkczY7ur2zDm9CjqM7u1eEdHHmPG=Oo=xA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="05nNIFABQReCPqy0"
Content-Disposition: inline
In-Reply-To: <CAMj1kXEJ9d3-8xa7rkczY7ur2zDm9CjqM7u1eEdHHmPG=Oo=xA@mail.gmail.com>
Precedence: bulk


--05nNIFABQReCPqy0
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Sep 2022 21:53:47 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Ard Biesheuvel <ardb@kernel.org>, Jan Beulich <jbeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3] Support ESRT in Xen dom0

On Tue, Sep 20, 2022 at 06:09:49PM +0200, Ard Biesheuvel wrote:
> On Tue, 20 Sept 2022 at 17:54, Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 20.09.2022 17:36, Ard Biesheuvel wrote:
> > > On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
> > > <demi@invisiblethingslab.com> wrote:
> > >>
> > >> fwupd requires access to the EFI System Resource Table (ESRT) to
> > >> discover which firmware can be updated by the OS.  Currently, Linux =
does
> > >> not expose the ESRT when running as a Xen dom0.  Therefore, it is not
> > >> possible to use fwupd in a Xen dom0, which is a serious problem for =
e.g.
> > >> Qubes OS.
> > >>
> > >> Before Xen 4.16, this was not fixable due to hypervisor limitations.
> > >> The UEFI specification requires the ESRT to be in EfiBootServicesData
> > >> memory, which Xen will use for whatever purposes it likes.  Therefor=
e,
> > >> Linux cannot safely access the ESRT, as Xen may have overwritten it.
> > >>
> > >> Starting with Xen 4.17, Xen checks if the ESRT is in EfiBootServices=
Data
> > >> or EfiRuntimeServicesData memory.  If the ESRT is in EfiBootServices=
Data
> > >> memory, Xen allocates some memory of type EfiRuntimeServicesData, co=
pies
> > >> the ESRT to it, and finally replaces the ESRT pointer with a pointer=
 to
> > >> the copy.  Since Xen will not clobber EfiRuntimeServicesData memory,
> > >> this ensures that the ESRT can safely be accessed by the OS.  It is =
safe
> > >> to access the ESRT under Xen if, and only if, it is in memory of type
> > >> EfiRuntimeServicesData.
> > >>
> > > TBH I still don't think this is a scalable approach. There are other
> > > configuration tables that may be passed in EFI boot services memory,
> > > and MS especially were pushing back in the UEFI forum on adding table
> > > types that were passed in anything other the EfiBootServicesData.
> >
> > Within Xen we might abstract the approach currently implemented in
> > case more such pieces of data appear.
> >
> > While I can easily believe MS might be advocating for this model,
> > I view it as problematic not only for Xen. How would you pass on
> > this information across kexec, for example, without introducing
> > further producer-consumer dependencies requiring separate protocols
> > to be followed?
> >
>=20
> In this case, I don't think this is unreasonable for configuration
> tables, which only have a GUID and a base address. If the OS knows the
> GUID, and knows how to interpret the contents, it can decide for
> itself whether or not to preserve it. If it doesn't know the GUID, the
> memory is just treated as available memory [after EBS()]

Should an OS uninstall any configuration tables that it does not
preserve if it ever plans to kexec()?  Does Linux do this?
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--05nNIFABQReCPqy0
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmMrwEsACgkQsoi1X/+c
IsETXhAAjr/+MWrA8eEVIEoYZ4PVctW84sTRXfBslltf7TZULl9zyWi/RSuYwj5K
a+a4Os05PC9xpu/GvyWO/6QTr1PwCIFIBkvi2eyfjem3KDbDdDA+qrLsoya/LD6C
1rnDabmZzzPcQsh19Mzc6ngipdbX7bLYjJkxwFpJ4KFKZi1ug4x2URa5VASYFuIv
i0I6imccxH5+92DXTaQBmSg2wHxG6zBkNYlEmbY16SgYV5mfWLpqw/85d2TMOOkt
uCohyxjC6uj7wyJ+QZ4fofo+yEl0Al4evWCve0Om5CknYJt+43Q2P89XJzmkxnJ8
T8x+BraQZ287kph/PCCzS/kLAt2dqjgS8XjZeP4g9AYF9H85FMa0g0lNFzhtkiEp
OvYedpSzFMR/XREw1yV9YBqMakfoI7VE2Kv3yqDXVfByFyDUMfBmGWyrGbr/ZtjE
9lhCgStB+qWnhYJluP6VyI7/gF/Q3MBuz9emMk+dDryMKTmMyo3ae2ADKgol4ASw
iF6pZD6y4JRYxIgpo5RT8mnkcEzGIoOAK5tPLb0XXzsJXUScskxE5Aoizvlf7HDQ
GukOXADUe0g+KyVhCDidy6bZK5a1FFyMLiJhe8hcU/PgRJDQ6R7/WDl5DmNX1eyv
acqYpMno6laktT9yopfjGGdZ9YanM3oN8DskXXD2L/u9ClNIQv4=
=l07Z
-----END PGP SIGNATURE-----

--05nNIFABQReCPqy0--