|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 5/5] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2()
On 22.01.2021 01:51, Bobby Eshleman wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -244,9 +244,13 @@ __efi64_mb2_start:
> jmp x86_32_switch
>
> .Lefi_multiboot2_proto:
> - /* Zero EFI SystemTable and EFI ImageHandle addresses. */
> + /*
> + * Zero EFI SystemTable, EFI ImageHandle and
> + * dom0 kernel module struct addresses.
> + */
> xor %esi,%esi
> xor %edi,%edi
> + xor %r14d, %r14d
Nit: There's little point in having the d suffixes here and below,
and the code would be slightly easier to read without.
> /* Skip Multiboot2 information fixed part. */
> lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
> @@ -284,6 +288,15 @@ __efi64_mb2_start:
> cmove MB2_efi64_ih(%rcx),%rdi
> je .Lefi_mb2_next_tag
>
> + /* Get Dom0 kernel module struct address from Multiboot2
> information. */
> + cmpl $MULTIBOOT2_TAG_TYPE_MODULE,MB2_tag_type(%rcx)
Not: If elsewhere in the code additions you put blanks after the
comma (which I appreciate), please do so here as well.
> + jne .Lefi_mb2_end
> +
> + test %r14d, %r14d
> + cmovz %ecx, %r14d
So this doesn't truncate the address because higher up %ecx was
loaded instead of %rcx. I realize that's not code you add, but
it still strikes me as odd. Are there indeed guarantees that all
of this will live below 4Gb?
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -3,6 +3,8 @@
> * is intended to be included by common/efi/boot.c _only_, and
> * therefore can define arch specific global variables.
> */
> +#include <xen/types.h>
> +#include <xen/multiboot2.h>
> #include <xen/vga.h>
> #include <asm/e820.h>
> #include <asm/edd.h>
> @@ -762,6 +764,10 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle,
Isn't there a hunk missing up from here to add the new parameter to
efi_multiboot2()?
> gop = efi_get_gop();
>
> + if ( dom0_kernel && dom0_kernel->mod_end > dom0_kernel->mod_start )
> + efi_shim_lock((VOID *)(unsigned long)dom0_kernel->mod_start,
> + dom0_kernel->mod_end - dom0_kernel->mod_start);
While somewhat unrelated to the change itself - how come the fields
are all u32 (and hence you need to cast to unsigned long first)?
There having been requests to allow for about 1Gb initrd images, I
find it quite reasonable to expect that modules may not all fit
below 4Gb.
> --- a/xen/arch/x86/efi/stub.c
> +++ b/xen/arch/x86/efi/stub.c
> @@ -1,7 +1,9 @@
> +#include <xen/types.h>
Please don't, even less so without honoring the alphabetical sorting.
> #include <xen/efi.h>
> #include <xen/errno.h>
> #include <xen/init.h>
> #include <xen/lib.h>
> +#include <xen/multiboot2.h>
> #include <asm/asm_defns.h>
> #include <asm/efibind.h>
> #include <asm/page.h>
> @@ -29,7 +31,8 @@ asm (
> );
>
> void __init noreturn efi_multiboot2(EFI_HANDLE ImageHandle,
> - EFI_SYSTEM_TABLE *SystemTable)
> + EFI_SYSTEM_TABLE *SystemTable,
> + multiboot2_tag_module_t *dom0_kernel)
const?
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -133,6 +133,7 @@ static void efi_console_set_mode(void);
> static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
> static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> UINTN cols, UINTN rows, UINTN depth);
> +static void efi_shim_lock(const VOID *Buffer, UINT32 Size);
> static void efi_tables(void);
> static void setup_efi_pci(void);
> static void efi_variables(void);
> @@ -830,6 +831,17 @@ static UINTN __init
> efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> return gop_mode;
> }
>
> +static void __init efi_shim_lock(const VOID *Buffer, UINT32 Size)
Maybe better efi_shim_lock_verify()?
> +{
> + static EFI_GUID __initdata shim_lock_guid = SHIM_LOCK_PROTOCOL_GUID;
> + EFI_SHIM_LOCK_PROTOCOL *shim_lock;
> + EFI_STATUS status;
> +
> + if ( !EFI_ERROR(efi_bs->LocateProtocol(&shim_lock_guid, NULL, (void
> **)&shim_lock)) &&
Nit: Overly long line.
> + (status = shim_lock->Verify(Buffer, Size)) != EFI_SUCCESS )
> + PrintErrMesg(L"Dom0 kernel image could not be verified", status);
I'm willing to let it be as is, but in principle this function is
not Dom0-specific the way you've split it out. _If_ you leave it
this way, perhaps (on top of the suggestion above) perhaps better
name it efi_shim_lock_verify_dom0()?
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |