Re: [Issue] EFI runtime-wrapper is broken

[Ard Biesheuvel <ardb@kernel.org>]

On Fri, 28 Oct 2022 at 11:10, Gavin Shan <gshan@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@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@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
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel