EFI booting crashes

[Atish Patra]

On Wed, Jan 13, 2021 at 5:46 AM Andreas Schwab <schwab at suse.de> wrote:
>
> Looking closer, the fault address is pointing to the GOT of u-boot,
> coming from loading the address of efi_var_buf in efi_var_mem_find:
>
>     80200338:   00078497                auipc   s1,0x78
>     8020033c:   9e84b483                ld      s1,-1560(s1) # 80277d20 <_GLOBAL_OFFSET_TABLE_+0x80>
>
> I wonder how this is supposed to work?  Surely the GOT isn't mapped in
> the EFI runtime memory.
>

You are right. The code snippet where the fault happened is
efi_get_variable_runtime->efi_get_variable_mem->efi_var_mem_find->efi_var_buf

efi_var_buf is at 0x200b2338 where the regions that are mapped are

[    0.181783] Remapping and enabling EFI services.
[    0.182923] efi_create_mapping: virt 20008000 phys be738000
num_pages 1                                     [    0.184485]
efi_create_mapping: virt 2001c000 phys be73c000  num_pages 3
[    0.185068] efi_create_mapping: virt 20020000 phys be740000  num_pages 4
[    0.185692] efi_create_mapping: virt 2003d000 phys bff6d000  num_pages 1

efi runtime services doesn't have mapping for that address which
explains the panic in the kernel.

efi_var_mem_find code was added during the same time as kernel EFI
patches were merged. Most likely, those patches caused a regression
which was never noticed.

It seems that during allocation efi_var_buf was allocated at be740000
which is mapped correctly as a runtime service data. However, the load
address during execution is invalid(0x200b2338). I am debugging this
further.

> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, schwab at suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."



-- 
Regards,
Atish