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, 30 Sep 2022 13:11:59 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Ard Biesheuvel <ardb@kernel.org>, Jan Beulich <jbeulich@suse.com>
Cc:     xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
        linux-efi@vger.kernel.org, Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        Kees Cook <keescook@chromium.org>,
        Anton Vorontsov <anton@enomsg.org>,
        Colin Cross <ccross@android.com>,
        Tony Luck <tony.luck@intel.com>,
        Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= 
        <marmarek@invisiblethingslab.com>
Subject: Re: [PATCH v4 1/2] Avoid using EFI tables Xen may have clobbered
Message-ID: <YzcjeiOW8+i2Zxsd@itl-email>
References: <cover.1664298147.git.demi@invisiblethingslab.com>
 <f3b624e99adfdbbfc1976a60a73a6b5950e1840d.1664298147.git.demi@invisiblethingslab.com>
 <282a225d-8782-0321-6f0e-19dd4510dc42@suse.com>
 <CAMj1kXFQNqsW5RfHGac-eGbosJHBybu6+-Fap_bi_kVxWNpGeg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="+TWbr9kogh5/wchI"
Content-Disposition: inline
In-Reply-To: <CAMj1kXFQNqsW5RfHGac-eGbosJHBybu6+-Fap_bi_kVxWNpGeg@mail.gmail.com>
Precedence: bulk


--+TWbr9kogh5/wchI
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Fri, 30 Sep 2022 13:11:59 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Ard Biesheuvel <ardb@kernel.org>, Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	linux-efi@vger.kernel.org, Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Kees Cook <keescook@chromium.org>,
	Anton Vorontsov <anton@enomsg.org>,
	Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
	Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek@invisiblethingslab.com>
Subject: Re: [PATCH v4 1/2] Avoid using EFI tables Xen may have clobbered

On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 08:44, Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 30.09.2022 01:02, Demi Marie Obenour wrote:
> > > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_D=
ATA,
> > > EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> > > Xen before Linux gets to start using it.  Therefore, Linux under Xen
> > > must not use EFI tables from such memory.  Most of the remaining EFI
> > > memory types are not suitable for EFI tables, leaving only
> > > EFI_ACPI_RECLAIM_MEMORY, EFI_RUNTIME_SERVICES_DATA, and
> > > EFI_RUNTIME_SERVICES_CODE.  When running under Xen, Linux should only
> > > use tables that are located in one of these types of memory.
> > >
> > > This patch ensures this, and also adds a function
> > > (xen_config_table_memory_region_max()) that will be used later to
> > > replace the usage of the EFI memory map in esrt.c when running under
> > > Xen.  This function can also be used in mokvar-table.c and efi-bgrt.c,
> > > but I have not implemented this.
> > >
> > > Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com>
> >
> > In Xen we don't clobber EfiBootServices{Code,Data} when xen.efi was pas=
sed
> > "-mapbs". Should we perhaps extend the interface such that Dom0 can then
> > also use tables located in such regions, perhaps by faking
> > EFI_MEMORY_RUNTIME in the attributes returned by XEN_FW_EFI_MEM_INFO?
> >
>=20
> I know this ship has sailed for x86, but for the sake of other
> architectures, I'd strongly recommend leaving the EFI_MEMORY_RUNTIME
> bits alone, for the same reasons I gave earlier. (Runtime mappings for
> the firmware code itself, page table fragmentation etc etc)

Why do you say that it has sailed for x86?

> I know very little about Xen, but based on the context you provided in
> this thread, I'd say that the best approach from the Xen side is to
> convert all EfiBootServicesData regions that have configuration tables
> pointing into them into EfiAcpiReclaimMemory.

Should Xen convert the entire region, or should it try to reserve only
the memory it needs?  The latter would require it to parse the
configuration tables.  Is there a list of configuration tables that can
legitimately be in EfiBootServicesData regions?

> I take it XEN_FW_EFI_MEM_INFO is an existing interface? If so, you
> might do the same for the returned type - EfiBootServicesData ->
> EfiAcpiReclaimMemory, and not muck about with the EFI_MEMORY_RUNTIME
> attribute.

It is indeed an existing interface, and this is a much better idea than
what you proposed.
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

--+TWbr9kogh5/wchI
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmM3I3kACgkQsoi1X/+c
IsHimRAAopJdHd1YzyxGmCQs/5C27GsZ6O2Z2oo4shynl65qxosa4wjyQ+hf0uBh
9UUbiWVqVuQHlw2SNR4RklZ9a4lVENb85rfkvFkGkb5JrGVU7PgCpYsNZJ0ZSDiW
SW4w4QR87BwF23Bk6GEiCL+dWTq1wH4iq89tX/S1LhvjaAh88tMf6Xm2lKuS2nek
EjfjWnWDtHLoj7K7M09b5m/8ofqofqiLvqCup6JRvambXHezEEgisxE3FeX3jmOA
Iw8e656o0sia+GK1mMfa1vf7+lHt+bmULbM9Qtjh4OzAim7NIycRj+8mNfnXmhWW
2hozW1E5ALre+lmdDuV9cRStlRmaXVv7YXNav+ia36xMDcxsTQP6V1scmdbkKk29
GxGq8fIU9ySZXmtrygIAF+RU4V4BLe72sqee/K+FcnHcUqJ6WaHW1TYP57eDNfoL
XThEJy7ZSwhVn7KxtQhr16aqysit7XeVr1OjRooP8ju5DouAumAdpEqZTUO8ruLH
dg2AN5DlD3WB8g5x5jFc/UHRvF5cEbNawEfEO6wkPVFozynIDXdvWQDQ/+0t5LnB
TbrEnfoeuiGn5PMB0paCrQKdr4mOxyZHe/EigAEhnMkWo4QyseG6yBme+Ee6N7sv
3A3g8YohKWHsRxRPHc7cdgVjAgc5Wsb1SlNNdgYwBVxW2udbzJ8=
=ag4U
-----END PGP SIGNATURE-----

--+TWbr9kogh5/wchI--