Re: [PATCH v4 1/2] Avoid using EFI tables Xen may have clobbered

[Demi Marie Obenour <demi@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 5143 bytes --]

On Fri, Sep 30, 2022 at 08:42:41PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 20:17, Demi Marie Obenour
> <demi@invisiblethingslab.com> wrote:
> >
> > On Fri, Sep 30, 2022 at 06:25:53PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> > > <demi@invisiblethingslab.com> wrote:
> > > >
> > > > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> > > > 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>
> > > > ---
> > > >  drivers/firmware/efi/efi.c |  8 +++++---
> > > >  drivers/xen/efi.c          | 35 +++++++++++++++++++++++++++++++++++
> > > >  include/linux/efi.h        |  9 +++++++++
> > > >  3 files changed, 49 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > > > index e4080ad96089abd7f84745dd8461c548bcbb7685..d344f3ff73d1c5ed0c67e3251a9502e66719741d 100644
> > > > --- a/drivers/firmware/efi/efi.c
> > > > +++ b/drivers/firmware/efi/efi.c
> > > > @@ -574,7 +574,6 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
> > > >         unsigned long table;
> > > >         int i;
> > > >
> > > > -       pr_info("");
> > >
> > > Why are you removing these prints?
> >
> > If I left them, I would need to include a pr_cont("\n") later.
> 
> There should always be one at the end of the loop, no? Or is this
> related to the diagnostic that gets printed in your helper?

My helper emits a diagnostic (at severity KERN_WARNING) if the table is
in memory that Xen has not reserved.

> > Checkpatch recommends against that.  What is the purpose of this print?
> > I assumed that since it prints an empty string it is superfluous.
> >
> 
> It prints the leading [invisible] loglevel marker, and the 'efi: ' prefix.

Okay, that makes sense.

> > > >         for (i = 0; i < count; i++) {
> > > >                 if (!IS_ENABLED(CONFIG_X86)) {
> > > >                         guid = &config_tables[i].guid;
> > > > @@ -585,7 +584,6 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
> > > >
> > > >                         if (IS_ENABLED(CONFIG_X86_32) &&
> > > >                             tbl64[i].table > U32_MAX) {
> > > > -                               pr_cont("\n");
> > > >                                 pr_err("Table located above 4GB, disabling EFI.\n");
> > > >                                 return -EINVAL;
> > > >                         }
> > > > @@ -594,10 +592,14 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
> > > >                         table = tbl32[i].table;
> > > >                 }
> > > >
> > > > +#ifdef CONFIG_XEN_EFI
> > >
> > > We tend to prefer IS_ENABLED() for cases such as this one. That way,
> > > the compiler always gets to see the code inside the conditional block,
> > > which gives better build test coverage (even if CONFIG_XEN_EFI is
> > > disabled).
> >
> > Can I count on the compiler eliminating the code as unreachable?  With
> > CONFIG_XEN_EFI disabled xen_config_table_memory_region_max() would be an
> > undefined symbol.
> >
> 
> If you drop the #ifdef in the .h file (as I suggested below) the code
> will compile fine, and the symbol reference will not be emitted into
> the object, so it will link fine even if the Xen objects are not being
> built.
> 
> We rely on this behavior all over the Linux kernel.

Okay, thanks!

> > > > +               if (efi_enabled(EFI_PARAVIRT) && !xen_config_table_memory_region_max(table))
> > >
> > > So the question here is whether Xen thinks the table should be
> > > disregarded or not. So let's define a prototype that reflects that
> > > purpose, and let the implementation reason about how this should be
> > > achieved.
> >
> > xen_config_table_memory_region_max() doesn’t just return whether the
> > table should be disregarded, but also (if the table should not be
> > ignored) the end of the memory region containing it.
> 
> But the calling code never uses that value, right?

The code in this patch does not use that value.  Patch 2 of 2 does use
it.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]