[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-efi
Subject:    Re: [PATCH 7/8] Documentation/x86/boot: Clarify segment requirements for EFI handover
From:       Arvind Sankar <nivedita () alum ! mit ! edu>
Date:       2020-01-31 19:24:29
Message-ID: 20200131192429.GB2346161 () rani ! riverdale ! lan
[Download RAW message or body]

On Thu, Jan 30, 2020 at 03:04:39PM -0500, Arvind Sankar wrote:
> The 32-bit EFI handover entry point requires segments to be setup in the
> same way as for the regular 32-bit boot.
> 
> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
> ---
>  Documentation/x86/boot.rst | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
> index c9c201596c3e..3e13b7d57271 100644
> --- a/Documentation/x86/boot.rst
> +++ b/Documentation/x86/boot.rst
> @@ -1412,6 +1412,12 @@ from the boot media and jump to the EFI handover protocol entry point
>  which is hdr->handover_offset bytes from the beginning of
>  startup_{32,64}.
>  
> +For the 32-bit handover entry point, the GDT and segments must be setup as for
> +the 32-bit boot protocol, i.e. a GDT must be loaded with the descriptors for
> +selectors __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G flat
> +segment; __BOOT_CS must have execute/read permission, and __BOOT_DS must have
> +read/write permission; CS must be __BOOT_CS and DS, ES, SS must be __BOOT_DS.
> +
>  The function prototype for the handover entry point looks like this::
>  
>      efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp)
> -- 
> 2.24.1
> 

I realized this is actually wrong. At the handover entry, the firmware
is still in control, so we can't require the bootloader to install a
different GDT from what the firmware had installed, and in fact OVMF for
one just passes the firmware GDT.

This seems to be working today by accident. OVMF sets up a GDT which
looks like this:
	NULL
	DATA
	CODE32
	DATA
	CODE32
	0
	DATA
	CODE64
	0
and this is what is installed when efi_stub_entry is called. Since
selectors 2 and 3 are code and data this works for us in 32-bit and in
mixed mode, and we don't care in 64-bit mode, but it seems like a bad
thing to rely upon.

I think we should save the segment descriptors in addition to the GDTR
on stub entry and restore them in the mixed-mode thunk before calling
the firmware?
[prev in list] [next in list] [prev in thread] [next in thread]