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

Re: [Xen-devel] [PATCH RFC 6/7] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2()



On Fri, May 04, 2018 at 09:46:33AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53, <daniel.kiper@xxxxxxxxxx> wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -383,9 +383,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
> >
> >          /* Skip Multiboot2 information fixed part. */
> >          lea     (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
> > @@ -423,6 +427,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)
> > +        jne     .Lefi_mb2_end
> > +
> > +        test    %r14d,%r14d
> > +        cmovz   %ecx,%r14d
> > +        jmp     .Lefi_mb2_next_tag
> > +
> > +.Lefi_mb2_end:
> >          /* Is it the end of Multiboot2 information? */
> >          cmpl    $MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
> >          je      .Lrun_bs
> > @@ -484,9 +497,12 @@ __efi64_mb2_start:
> >          /* Keep the stack aligned. Do not pop a single item off it. */
> >          mov     (%rsp),%rdi
> >
> > +        mov     %r14d,%edx
> > +
> >          /*
> >           * efi_multiboot2() is called according to System V AMD64 ABI:
> > -         *   - IN:  %rdi - EFI ImageHandle, %rsi - EFI SystemTable.
> > +         *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> > +         *         %rdx - dom0 kernel module struct address.
>
> How come everything further up treats this as a 32-bit quantity only?

According to the Multiboot2 spec the bootloader is not allowed to
put the kernel (xen.gz) and the modules above 4 GiB boundary. And
comment below __efi64_mb2_start label is clear about that.

> > @@ -47,6 +49,7 @@ extern const struct pe_base_relocs {
> >
> >  static void __init efi_arch_relocate_image(unsigned long delta)
> >  {
> > +#if 0
> >      const struct pe_base_relocs *base_relocs;
> >
> >      for ( base_relocs = __base_relocs_start; base_relocs <
> > __base_relocs_end; )
> > @@ -95,6 +98,7 @@ static void __init efi_arch_relocate_image(unsigned long 
> > delta)
> >          }
> >          base_relocs = (const void *)(base_relocs->entries + i + (i & 1));
> >      }
> > +#endif
> >  }
>
> ???

Please forget it. This is just an RFC. It will be fixed in v2.

> > @@ -669,7 +673,9 @@ static bool __init
> > efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
> >
> >  static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }
> >
> > -void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable)
> > +void __init efi_multiboot2(EFI_HANDLE ImageHandle,
> > +                           EFI_SYSTEM_TABLE *SystemTable,
> > +                           multiboot2_tag_module_t *dom0_kernel)
>
> const?

Will do.

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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