[Issue] EFI runtime-wrapper is broken

Ard Biesheuvel ardb at kernel.org
Fri Oct 28 02:45:31 PDT 2022


(cc Nhi Pham and Quan Nguyen)

On Fri, 28 Oct 2022 at 11:21, Ard Biesheuvel <ardb at kernel.org> wrote:
>
> On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan at redhat.com> wrote:
> >
> > Hi Ard,
> >
> > I ran into the following crash with v6.1.rc2. I'm not sure if it's known
> > issue. Last good version is v6.0.rc6/rc7. The kernel configuration is attached.
> >
>
> Hello Gavin,
>
> This is probably related to the patch below. It means the firmware is
> buggy, and does not work as it should if the firmware never calls
> SetVirtualAddressMap() [and doing so is explicitly described as
> OPTIONAL by the EFI specification].
>
> The problem here is that other EFI implementations (primarily the
> Qualcomm ones used on Windows-on-ARM laptops) are buggy too, and don't
> tolerate SetVirtualAddressMap().
>
> Can you try whether reverting the patch below helps?
>
>
>
>
> commit d3549a938b73f203ef522562ae9f2d38aa43d234
> Author: Ard Biesheuvel <ardb at kernel.org>
> Date:   Fri Sep 16 11:48:30 2022 +0200
>
>     efi/arm64: libstub: avoid SetVirtualAddressMap() when possible
>
>     EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
>     like to avoid using, if possible. For 64-bit architectures such as
>     arm64, the user and kernel mappings are entirely disjoint, and given
>     that we use the user region for mapping the UEFI runtime regions when
>     running under the OS, we don't rely on SetVirtualAddressMap() in the
>     conventional way, i.e., to permit kernel mappings of the OS to coexist
>     with kernel region mappings of the firmware regions. This means that, in
>     principle, we should be able to avoid SetVirtualAddressMap() altogether,
>     and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
>     omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
>     spec).
>
>     However, there is a corner case on arm64, which, if configured for
>     3-level paging (or 2-level paging when using 64k pages), may not be able
>     to cover the entire range of firmware mappings (which might contain both
>     memory and MMIO peripheral mappings).
>
>     So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
>     is guaranteed to be of sufficient size.
>
>     Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
>
>
>
> > [   71.281677] Unable to handle kernel paging request at virtual address 00000000a934da68
> > [   71.289593] Mem abort info:
> > [   71.292375]   ESR = 0x0000000096000006
> > [   71.296111]   EC = 0x25: DABT (current EL), IL = 32 bits
> > [   71.301411]   SET = 0, FnV = 0
> > [   71.304453]   EA = 0, S1PTW = 0
> > [   71.307581]   FSC = 0x06: level 2 translation fault
> > [   71.312446] Data abort info:
> > [   71.315315]   ISV = 0, ISS = 0x00000006
> > [   71.319138]   CM = 0, WnR = 0
> > [   71.322094] user pgtable: 4k pages, 48-bit VAs, pgdp=0000080046ad6000
> > [   71.328522] [00000000a934da68] pgd=0000000000000000, p4d=0000000000000000
> > [   71.335299] Internal error: Oops: 0000000096000006 [#1] SMP
> > [   71.340860] Modules linked in: bridge stp llc qrtr rfkill sunrpc vfat fat mlx5_ib ib_uverbs cdc_ether usbnet mii ib_core acpi_ipmi ipmi_ssif arm_spe_pmu ipmi_devintf ipmi_msghandler arm_cmn arm_dmc620_pmu arm_dsu_pmu cppc_cpufreq xfs libcrc32c ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helper ttm mlx5_core crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce drm sbsa_gwdt mlxfw tls nvme igb nvme_core psample nvme_common i2c_algo_bit pci_hyperv_intf i2c_designware_platform i2c_designware_core xgene_hwmon dm_mirror dm_region_hash dm_log dm_mod fuse
> > [   71.393089] CPU: 94 PID: 1563 Comm: kworker/u320:3 Not tainted 6.1.0-rc2-gavin+ #6
> > [   71.400646] Hardware name: FOXCONN Mt. Collins/Mt. Collins, BIOS 0ACOC017 (SCP: 1.08.20210825) 10/22/2021
> > [   71.410200] Workqueue: efi_rts_wq efi_call_rts
> > [   71.414636] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [   71.421585] pc : 0xb7ec7ae4
> > [   71.424367] lr : 0xb7ec8668
> > [   71.427149] sp : ffff80002f0e37e0
> > [   71.430452] x29: ffff80002f0e37e0 x28: ffffa4efa13bb0d0 x27: ffffa4efa0e32a18
> > [   71.437575] x26: ffff3fff93ce2d74 x25: ffff3fff90793805 x24: 0000000000000000
> > [   71.444698] x23: 0000000000000000 x22: 0000000000000000 x21: ffffa4efa06f0750
> > [   71.451821] x20: ffff8000279fbcc8 x19: ffffa4efa1df2a80 x18: 0000000000000000
> > [   71.458944] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab19a5fb90
> > [   71.466067] x14: 0000000000000000 x13: 0000000000000010 x12: 0101010101010101
> > [   71.473190] x11: 7f7f7f7f7f7f7f7f x10: fefefefefeff7076 x9 : ffffa4ef9f5f7570
> > [   71.480313] x8 : 00000000b7cc05b8 x7 : ffff80002f0e3b60 x6 : ffff80002f0e3c00
> > [   71.487436] x5 : ffff80002f0e3b58 x4 : 00000000b7e81358 x3 : 00000000b7ec8600
> > [   71.494559] x2 : 0000000001000000 x1 : 0000000001000000 x0 : 00000000a934da60
> > [   71.501682] Call trace:
> > [   71.504116]  0xb7ec7ae4
> > [   71.506551]  0xb7ec8668
> > [   71.508985]  0xb7ec6e08
> > [   71.511419]  0xb7ec68ec
> > [   71.513853]  0xb7ec3824
> > [   71.516287]  0xb7ec05a8
> > [   71.518721]  0xb7ec12a0
> > [   71.521155]  0xb7e53524
> > [   71.523590]  0xb7e53670
> > [   71.526024]  0xb7e582f0
> > [   71.528458]  0xb7e5909c
> > [   71.530892]  0xb7e5a014
> > [   71.533326]  0xb7e508a8
> > [   71.535760]  0xb7cc3328
> > [   71.538195]  0xb7cc0674
> > [   71.540629]  __efi_rt_asm_wrapper+0x2c/0x48
> > [   71.544802]  efi_call_rts+0x2a8/0x440
> > [   71.548454]  process_one_work+0x1e4/0x460
> > [   71.552452]  worker_thread+0x74/0x414
> > [   71.556103]  kthread+0xf0/0xf4
> > [   71.559147]  ret_from_fork+0x10/0x20
> > [   71.562712] Code: 90000000 912c2000 f9400000 f9400000 (f9400401)
> > [   71.568794] ---[ end trace 0000000000000000 ]---
> > [   71.573401] Kernel panic - not syncing: Oops: Fatal exception in interrupt
> > [   71.580263] SMP: stopping secondary CPUs
> > [   71.584932] Kernel Offset: 0x24ef975e0000 from 0xffff800008000000
> > [   71.591012] PHYS_OFFSET: 0x80000000
> > [   71.594488] CPU features: 0x00000,001700a4,6601720b
> > [   71.599353] Memory Limit: none
> > [   71.602395] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
> >
> > Thanks,
> > Gavin
> >



More information about the linux-arm-kernel mailing list