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@xxxxxxxxxxxx>
> ---
> 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?
