[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Grab the EFI System Reference Table and check it


  • To: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 2 Sep 2021 11:56:36 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vgtEOi+Tk+N1Qhq1ZjjXcboumpOXjoDLgESCBpFZp68=; b=bjqUCXNF+C5eHhPK7u5tG0SbwsPcL4z5LJ7ozNCnIqL7VgpW9TBON1HL4+hQSxf2t7k9mr7vQZYEXKbysuHkdTJH65pWuXqrer7C2ZoowJAJzCpI5OgYsOzzwLZ69YT+DsFD2Hle2nbtsFgofIIZNTNyHWBmb8GLxOAGbGxfbJQi654GB0Wr/Qt9unJQlzTGDy1YUWyH9K1RowkanTK47b3ix4Ic83ryMAJAn4B44bD08WT3ej/BwS/qYq+9B7/Nf1uYSfQ78BsrcGmCzZH6eeSlcEh6lSYMySHiAvssx73QOehzl9KLF7cn5Id2qMpzKRn8aOlZUtdryeD5DLUK1A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DphjXKh/tuw+Tw+JeXFFe+06FkWazd/Hb6rKuH8qQZY7gObzhmlvNB8oJkzs6wx+xpq5/6f6dIYiAM6ZBv5QrL4GcAvTguGWMKxIkez4FEizSLoykWy1EJDqZsbHKRbmXdbBVK8BYid+J4WIKzMcb7TkRj3KK3+MjZPUJXORURdsCTF1RAY2zOMo1eb/3O0kBhA5yFvJGclwkhGAgSlmE3SZRIi3EId3jiXo5tkXyh/rVufLaHglK7Hw+ImqI/3i8zSQCCOmGCgPk2sV2VXT3q9rEXAjoFOLeQFnD+ze9Wa6xKXneTOREMtwDWLz9lN/6scGR+eALsaoKyOGk+Ycig==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 02 Sep 2021 09:57:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 29.08.2021 14:18, Demi Marie Obenour wrote:
> The EFI System Reference Table (ESRT) is necessary for fwupd to identify

To properly match the UEFI spec, both here and in the subject I suppose
you mean "Resource" instead of "Reference"?

> @@ -171,7 +172,7 @@ static void __init 
> efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable,
>          {
>          case EfiBootServicesCode:
>          case EfiBootServicesData:
> -            if ( map_bs )
> +            if ( map_bs || desc == esrt_desc )
>              {
>          default:
>                  type = E820_RESERVED;

Elsewhere you also permit ESRT to live in EfiRuntimeServicesData. The
code addition here looks to contradict that.

Furthermore you're potentially making a large chunk of data unavailable
just because it contains a small piece of data which needs to be
preserved.

> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -93,6 +93,23 @@ typedef struct _EFI_LOAD_OPTION {
>      CHAR16 Description[];
>  } EFI_LOAD_OPTION;
>  
> +struct esrt_entry {
> +    EFI_GUID fw_class;
> +    uint32_t fw_type;
> +    uint32_t fw_version;
> +    uint32_t fw_lowest_supported_version;
> +    uint32_t fw_capsule_flags;
> +    uint32_t fw_last_attempt_version;
> +    uint32_t fw_last_attempt_status;
> +};
> +
> +struct esrt {
> +    uint32_t esrt_count;
> +    uint32_t esrt_max;
> +    uint64_t esrt_version;
> +    struct esrt_entry esrt_entries[];
> +};

These don't match the gnu-efi style (where we're generally taking
pieces from), but since I can't spot that package supporting ESRT at
all, we have to roll our own, so the style inconsistency is perhaps
okay. But at least - alongside EFI_GUID - I think you want to use EFI
types (UINT<nn>).

> @@ -166,6 +183,41 @@ static void __init PrintErr(const CHAR16 *s)
>      StdErr->OutputString(StdErr, (CHAR16 *)s );
>  }
>  
> +enum esrt_status {
> +    ESRT_NOTFOUND = 0,
> +    ESRT_GOOD,
> +    ESRT_BAD,
> +};

I think we generally try to limit all-caps identifiers to macros.

> +static enum esrt_status __init is_esrt_valid(
> +    const EFI_MEMORY_DESCRIPTOR *const desc) {

Style nit: Brace goes on it own line.

> +    size_t available_len, esrt_len, len;
> +    const uintptr_t physical_start = desc->PhysicalStart;
> +    const uintptr_t esrt = efi.esrt;

Like said above and to match other code in this file, EFI types
(UINTN in particular) should be preferred.

> +    const struct esrt *esrt_ptr;
> +
> +    len = desc->NumberOfPages << EFI_PAGE_SHIFT;
> +    if ( esrt == EFI_INVALID_TABLE_ADDR )
> +        return ESRT_BAD;

I think this is rather ESRT_NOTFOUND, too? But see also below.

> +    if ( physical_start > esrt || esrt - physical_start >= len )
> +        return ESRT_NOTFOUND;
> +    if ( ! ( desc->Attribute & EFI_MEMORY_RUNTIME ) &&
> +           ( desc->Type != EfiRuntimeServicesData ) &&
> +           ( desc->Type != EfiBootServicesData ) )

As you say in the description, the spec mandates the latter. I can
accept you also wanting to cover other plausible types, but then
please add a brief comment mentioning the intentional diverging
from what the spec says. This would then hopefully also clarify
the curious redundancy between checking EFI_MEMORY_RUNTIME and
EfiRuntimeServicesData.

As to style - there are quite a few too many blanks here.

> +        return ESRT_BAD;
> +    available_len = len - (esrt - physical_start);
> +    if ( available_len < offsetof(struct esrt, esrt_entries) )

Iirc both gcc and clang allow sizeof(*estr_ptr) despite the
flexible array member - please prefer that form (also again further
down).

> +        return ESRT_BAD;
> +    esrt_ptr = (const struct esrt *) esrt;

For this and the sizeof() below to be applicable, you need to check
the version to be 1. Also, as to style, there's not supposed to be
any blank after the closing parenthesis.

> +    if ( esrt_ptr->esrt_count <= 0 ||
> +         __builtin_mul_overflow(esrt_ptr->esrt_count,
> +                                sizeof(struct esrt_entry),

sizeof(esrt_ptr->esrt_entries[0]) or alike please.

Also - is __builtin_mul_overflow() supported by all gcc versions we
support building this code with? And is this overflow check needed
in the first place? After all we build EFI code only for 64-bit
hypervisors, and a 32-bit quantity times the sizeof() can't overflow
in 64 bits.

> +                                &esrt_len) ||
> +         esrt_len > available_len - offsetof(struct esrt, esrt_entries) )
> +        return ESRT_BAD;
> +    return ESRT_GOOD;
> +}

Style nit: Please put a blank line ahead of the function's main
"return" statement.

> @@ -835,6 +887,10 @@ static void __init efi_tables(void)
>  {
>      unsigned int i;
>  
> +    BUILD_BUG_ON(sizeof(struct esrt_entry) != 40);
> +    BUILD_BUG_ON(_Alignof(struct esrt_entry) != 4);
> +    BUILD_BUG_ON(offsetof(struct esrt, esrt_entries) != 16);

Why? We're not doing this for other types declared locally in this
source file afaics. Plus - did you check that all gcc versions we
support for building this code can actually deal with the C99
_Alignof()? I would generally have expected you to use __alignof(),
as we do elsewhere.

> @@ -1042,9 +1101,7 @@ static void __init efi_exit_boot(EFI_HANDLE 
> ImageHandle, EFI_SYSTEM_TABLE *Syste
>      EFI_STATUS status;
>      UINTN info_size = 0, map_key;
>      bool retry;
> -#ifdef CONFIG_EFI_SET_VIRTUAL_ADDRESS_MAP
>      unsigned int i;
> -#endif
>  
>      efi_bs->GetMemoryMap(&info_size, NULL, &map_key,
>                           &efi_mdesc_size, &mdesc_ver);
> @@ -1055,6 +1112,10 @@ static void __init efi_exit_boot(EFI_HANDLE 
> ImageHandle, EFI_SYSTEM_TABLE *Syste
>  
>      for ( retry = false; ; retry = true )
>      {
> +        enum esrt_status esrt_status = ESRT_NOTFOUND;
> +        const EFI_MEMORY_DESCRIPTOR *esrt_desc =
> +            (const EFI_MEMORY_DESCRIPTOR*) EFI_INVALID_TABLE_ADDR;

Style: Misplaced blank.

> @@ -1063,8 +1124,31 @@ static void __init efi_exit_boot(EFI_HANDLE 
> ImageHandle, EFI_SYSTEM_TABLE *Syste
>          if ( EFI_ERROR(status) )
>              PrintErrMesg(L"Cannot obtain memory map", status);
>  
> +        for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
> +        {
> +            EFI_MEMORY_DESCRIPTOR *desc = efi_memmap + i;
> +            switch ( is_esrt_valid(desc) )

Style: Blank line please between declaration(s) and statement(s).
I question the need for the local variable though - you only need
it ...

> +            {
> +            case ESRT_NOTFOUND:
> +                break;
> +            case ESRT_GOOD:
> +                esrt_status = ESRT_GOOD;
> +                esrt_desc = desc;

... here.

> +                break;
> +            case ESRT_BAD:
> +                esrt_status = ESRT_BAD;
> +                break;
> +            }
> +        }
> +        if ( esrt_status != ESRT_GOOD )
> +            efi.esrt = EFI_INVALID_TABLE_ADDR;

In the end you don't distinguish ESRT_BAD from ESRT_NOTFOUND, so I
don't see the need for the enum. The function can simply return
bool then.

> +        /*
> +         * We cannot pass efi.esrt because we need to explicitly compare the
> +         * descriptor pointers for equality.
> +         */
>          efi_arch_process_memory_map(SystemTable, efi_memmap, efi_memmap_size,
> -                                    efi_mdesc_size, mdesc_ver);
> +                                    efi_mdesc_size, mdesc_ver, esrt_desc);

I'm not convinced this is "need" (as the comment says), but at best
"want", for being an implementation choice. But the model itself is
suspect to me in the first place, as said above.

> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -19,6 +19,7 @@ struct efi {
>      unsigned long acpi20;       /* ACPI table (ACPI 2.0) */
>      unsigned long smbios;       /* SM BIOS table */
>      unsigned long smbios3;      /* SMBIOS v3 table */
> +    unsigned long esrt;         /* EFI System Reference Table */
>  };

I have to admit that I'm having difficulty spotting why this field
needs adding here: No other component in Xen wants to use it. Yet
that's what the struct is for.

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.