On 10th of December, I had reported this bug but still haven't got any response from the maintainers. As a result I am sending it again. Consider the fact that is is a severe bug as it causes kernels to not boot at all and results in panics on T2 Macs.
On enabling EFI runtime services on Macs with the T2 security chip, kernel fails to boot due panics in the T2 security chip. Using efi=noruntine (or noefi) as a kernel parameter seems to fix the issue. Also, making NVRAM read-only makes kernels boot. A fix for that would be appreciated.
Link :- https://bugzilla.kernel.org/show_bug.cgi?id=215277
We believe kernel only fails to boot if something is set up to write to nvram at boot, it can boot fine on a MacBookPro16,1 as long as I don't have anything writing to nvram (deleting and reading variables is fine).
The t2 security chip handles nvram and loading bootloaders on these
macs. Its bridgeOS had an update that was bundled with macOS Catalina
(this can't be downgraded, and some computers shipped with macOS
Catalina), that made writing to nvram from Linux cause an invalid
opcode error and a frozen system:
invalid opcode: 0000 [#1] PREEMPT SMP PTI
CPU: 9 PID: 135 Comm: kworker/u24:2 Tainted: G S U C 5.16.0-rc4-00054-g6c3ecb47bb75-dirty #72
Hardware name: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1715.40.15.0.0 (iBridge: 19.16.10548.0.0,0) 10/03/2021
Workqueue: efi_rts_wq efi_call_rts
RIP: 0010:0xfffffffeefc46877
Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
Call Trace:
<TASK>
? _printk+0x58/0x6f
__efi_call+0x28/0x30
efi_call_rts.cold+0x83/0x104
process_one_work+0x219/0x3f0
worker_thread+0x4d/0x3d0
? rescuer_thread+0x390/0x390
kthread+0x15c/0x180
? set_kthread_struct+0x40/0x40
ret_from_fork+0x22/0x30
</TASK>
Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat amdgpu nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_counter nf_tables n
sysimgblt fb_sys_fops cec crc16 intel_pch_thermal sbs ecdh_generic ecc rfkill apple_bl video acpi_tad mac_hid sbshc pkcs8_key_parser drm fuse crypto_user bpf_preload ip_tables x_tables crct10dif_pcl
---[ end trace 22f8aad91761cc4a ]---
RIP: 0010:0xfffffffeefc46877
Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
BUG: kernel NULL pointer dereference, address: 0000000000000008
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/runtime-wrappers.c#n220
and within that section, the invalid opcode seems to be occurring in
this bit of assembly:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/platform/efi/efi_stub_64.S
printing efi_call_virt's arguments with
pr_err("1: %d, 2: %d, 3: %d, 4: %d", *(u32 *)arg1, (u64 *)arg2, (u64 *)arg3, (u64 *)arg4);
gets me "1: 7, 2: -2079343160, 3: -2079343152, 4: -2079343144"
—
I hope I shall get a reply this time.
Regards
Aditya
On Mon, 10 Jan 2022 at 16:37, Aditya Garg <[email protected]> wrote:
>
> On 10th of December, I had reported this bug but still haven't got any response from the maintainers. As a result I am sending it again. Consider the fact that is is a severe bug as it causes kernels to not boot at all and results in panics on T2 Macs.
>
> On enabling EFI runtime services on Macs with the T2 security chip, kernel fails to boot due panics in the T2 security chip.
I don't see how panics in the T2 security chip could be blamed on the
EFI runtime services layer in Linux.
As far as I can tell, what we need here is a DMI quirk that just
disables EFI runtime support on these platforms.
> Using efi=noruntine (or noefi) as a kernel parameter seems to fix the issue. Also, making NVRAM read-only makes kernels boot. A fix for that would be appreciated.
>
> Link :- https://bugzilla.kernel.org/show_bug.cgi?id=215277
>
> We believe kernel only fails to boot if something is set up to write to nvram at boot, it can boot fine on a MacBookPro16,1 as long as I don't have anything writing to nvram (deleting and reading variables is fine).
>
> The t2 security chip handles nvram and loading bootloaders on these
> macs. Its bridgeOS had an update that was bundled with macOS Catalina
> (this can't be downgraded, and some computers shipped with macOS
> Catalina), that made writing to nvram from Linux cause an invalid
> opcode error and a frozen system:
>
> invalid opcode: 0000 [#1] PREEMPT SMP PTI
> CPU: 9 PID: 135 Comm: kworker/u24:2 Tainted: G S U C 5.16.0-rc4-00054-g6c3ecb47bb75-dirty #72
> Hardware name: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1715.40.15.0.0 (iBridge: 19.16.10548.0.0,0) 10/03/2021
> Workqueue: efi_rts_wq efi_call_rts
> RIP: 0010:0xfffffffeefc46877
> Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
> RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
> RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
> RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
> RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
> R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
> R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
> FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
> Call Trace:
> <TASK>
> ? _printk+0x58/0x6f
> __efi_call+0x28/0x30
> efi_call_rts.cold+0x83/0x104
> process_one_work+0x219/0x3f0
> worker_thread+0x4d/0x3d0
> ? rescuer_thread+0x390/0x390
> kthread+0x15c/0x180
> ? set_kthread_struct+0x40/0x40
> ret_from_fork+0x22/0x30
> </TASK>
> Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat amdgpu nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_counter nf_tables n
> sysimgblt fb_sys_fops cec crc16 intel_pch_thermal sbs ecdh_generic ecc rfkill apple_bl video acpi_tad mac_hid sbshc pkcs8_key_parser drm fuse crypto_user bpf_preload ip_tables x_tables crct10dif_pcl
> ---[ end trace 22f8aad91761cc4a ]---
> RIP: 0010:0xfffffffeefc46877
> Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
> RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
> RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
> RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
> RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
> R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
> R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
> FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
> BUG: kernel NULL pointer dereference, address: 0000000000000008
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
>
> This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
>
This is interesting. QueryVariableInfo() was introduced in EFI 2.00,
and for a very long time, Intel MACs would claim to implement EFI 1.10
only. This means Linux would never attempt to use QueryVariableInfo()
on such platforms.
Can you please check your boot log which revision it claims to implement now?
Mine says
efi: EFI v1.10 by Apple
near the start of the kernel log.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/runtime-wrappers.c#n220
> and within that section, the invalid opcode seems to be occurring in
> this bit of assembly:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/platform/efi/efi_stub_64.S
>
Ehm no. __efi_call() is just a trampoline to call into the firmware,
and the opcodes in question are firmware code not Linux code.
> As far as I can tell, what we need here is a DMI quirk that just
> disables EFI runtime support on these platforms.
If that’s the last option, please propose a patch for the same.
>
>> Using efi=noruntine (or noefi) as a kernel parameter seems to fix the issue. Also, making NVRAM read-only makes kernels boot. A fix for that would be appreciated.
>>
>> Link :- https://bugzilla.kernel.org/show_bug.cgi?id=215277
>>
>> We believe kernel only fails to boot if something is set up to write to nvram at boot, it can boot fine on a MacBookPro16,1 as long as I don't have anything writing to nvram (deleting and reading variables is fine).
>>
>> The t2 security chip handles nvram and loading bootloaders on these
>> macs. Its bridgeOS had an update that was bundled with macOS Catalina
>> (this can't be downgraded, and some computers shipped with macOS
>> Catalina), that made writing to nvram from Linux cause an invalid
>> opcode error and a frozen system:
>>
>> invalid opcode: 0000 [#1] PREEMPT SMP PTI
>> CPU: 9 PID: 135 Comm: kworker/u24:2 Tainted: G S U C 5.16.0-rc4-00054-g6c3ecb47bb75-dirty #72
>> Hardware name: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1715.40.15.0.0 (iBridge: 19.16.10548.0.0,0) 10/03/2021
>> Workqueue: efi_rts_wq efi_call_rts
>> RIP: 0010:0xfffffffeefc46877
>> Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
>> RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
>> RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
>> RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
>> RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
>> R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
>> R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
>> FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
>> Call Trace:
>> <TASK>
>> ? _printk+0x58/0x6f
>> __efi_call+0x28/0x30
>> efi_call_rts.cold+0x83/0x104
>> process_one_work+0x219/0x3f0
>> worker_thread+0x4d/0x3d0
>> ? rescuer_thread+0x390/0x390
>> kthread+0x15c/0x180
>> ? set_kthread_struct+0x40/0x40
>> ret_from_fork+0x22/0x30
>> </TASK>
>> Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat amdgpu nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_counter nf_tables n
>> sysimgblt fb_sys_fops cec crc16 intel_pch_thermal sbs ecdh_generic ecc rfkill apple_bl video acpi_tad mac_hid sbshc pkcs8_key_parser drm fuse crypto_user bpf_preload ip_tables x_tables crct10dif_pcl
>> ---[ end trace 22f8aad91761cc4a ]---
>> RIP: 0010:0xfffffffeefc46877
>> Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
>> RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
>> RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
>> RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
>> RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
>> R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
>> R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
>> FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
>> BUG: kernel NULL pointer dereference, address: 0000000000000008
>> #PF: supervisor write access in kernel mode
>> #PF: error_code(0x0002) - not-present page
>>
>> This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
>>
>
> This is interesting. QueryVariableInfo() was introduced in EFI 2.00,
> and for a very long time, Intel MACs would claim to implement EFI 1.10
> only. This means Linux would never attempt to use QueryVariableInfo()
> on such platforms.
>
> Can you please check your boot log which revision it claims to implement now?
>
> Mine says
>
> efi: EFI v1.10 by Apple
Mine says
efi: EFI v2.40 by Apple
>
> near the start of the kernel log.
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/runtime-wrappers.c#n220
>> and within that section, the invalid opcode seems to be occurring in
>> this bit of assembly:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/platform/efi/efi_stub_64.S
>>
>
> Ehm no. __efi_call() is just a trampoline to call into the firmware,
> and the opcodes in question are firmware code not Linux code.
On Mon, 10 Jan 2022 at 17:28, Aditya Garg <[email protected]> wrote:
>
>
> > As far as I can tell, what we need here is a DMI quirk that just
> > disables EFI runtime support on these platforms.
>
> If that’s the last option, please propose a patch for the same.
>
As the EFI maintainer for Linux, I'd be happy to merge a patch that
implements this. But I don't have time to write it, nor do I have
access to a recent Intel Mac, so I wouldn't be able to test it either.
So I suggest that you escalate this issue to whoever is providing
support for running Linux on your hardware, and I'm sure they will be
happy to employ someone to fix this problem for you.
> >
> >> Using efi=noruntine (or noefi) as a kernel parameter seems to fix the issue. Also, making NVRAM read-only makes kernels boot. A fix for that would be appreciated.
> >>
> >> Link :- https://bugzilla.kernel.org/show_bug.cgi?id=215277
> >>
> >> We believe kernel only fails to boot if something is set up to write to nvram at boot, it can boot fine on a MacBookPro16,1 as long as I don't have anything writing to nvram (deleting and reading variables is fine).
> >>
> >> The t2 security chip handles nvram and loading bootloaders on these
> >> macs. Its bridgeOS had an update that was bundled with macOS Catalina
> >> (this can't be downgraded, and some computers shipped with macOS
> >> Catalina), that made writing to nvram from Linux cause an invalid
> >> opcode error and a frozen system:
> >>
> >> invalid opcode: 0000 [#1] PREEMPT SMP PTI
> >> CPU: 9 PID: 135 Comm: kworker/u24:2 Tainted: G S U C 5.16.0-rc4-00054-g6c3ecb47bb75-dirty #72
> >> Hardware name: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1715.40.15.0.0 (iBridge: 19.16.10548.0.0,0) 10/03/2021
> >> Workqueue: efi_rts_wq efi_call_rts
> >> RIP: 0010:0xfffffffeefc46877
> >> Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
> >> RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
> >> RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
> >> RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
> >> RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
> >> R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
> >> R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
> >> FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
> >> Call Trace:
> >> <TASK>
> >> ? _printk+0x58/0x6f
> >> __efi_call+0x28/0x30
> >> efi_call_rts.cold+0x83/0x104
> >> process_one_work+0x219/0x3f0
> >> worker_thread+0x4d/0x3d0
> >> ? rescuer_thread+0x390/0x390
> >> kthread+0x15c/0x180
> >> ? set_kthread_struct+0x40/0x40
> >> ret_from_fork+0x22/0x30
> >> </TASK>
> >> Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat amdgpu nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_counter nf_tables n
> >> sysimgblt fb_sys_fops cec crc16 intel_pch_thermal sbs ecdh_generic ecc rfkill apple_bl video acpi_tad mac_hid sbshc pkcs8_key_parser drm fuse crypto_user bpf_preload ip_tables x_tables crct10dif_pcl
> >> ---[ end trace 22f8aad91761cc4a ]---
> >> RIP: 0010:0xfffffffeefc46877
> >> Code: 8b 58 18 0f b6 0d e1 09 00 00 48 c1 e1 04 e8 30 03 00 00 48 89 05 d9 09 00 00 80 3d a2 09 00 00 01 75 09 48 c7 07 00 10 00 00 <0f> 0b 48 8b 05 a8 07 00 00 8b 40 08 48 83 c0 f0 48 89 07 48 c7 06
> >> RSP: 0018:ffff998d40513dd0 EFLAGS: 00010246
> >> RAX: ffff998d40513eb0 RBX: ffff998d43f17dd8 RCX: 0000000000000007
> >> RDX: ffff998d43f17dc8 RSI: ffff998d43f17dd8 RDI: ffff998d43f17dc8
> >> RBP: ffff998d40513e00 R08: ffff998d43f17dd0 R09: ffff998d43f17dd8
> >> R10: ffff998d40513c80 R11: ffffffff9b4cabe8 R12: ffff998d43f17dc8
> >> R13: ffff998d43f17dd0 R14: 0000000000000246 R15: 0000000000000048
> >> FS: 0000000000000000(0000) GS:ffff8cf8bec40000(0000) knlGS:0000000000000000
> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> CR2: 00007f9133594374 CR3: 0000000100200005 CR4: 00000000003706e0
> >> BUG: kernel NULL pointer dereference, address: 0000000000000008
> >> #PF: supervisor write access in kernel mode
> >> #PF: error_code(0x0002) - not-present page
> >>
> >> This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
> >>
> >
> > This is interesting. QueryVariableInfo() was introduced in EFI 2.00,
> > and for a very long time, Intel MACs would claim to implement EFI 1.10
> > only. This means Linux would never attempt to use QueryVariableInfo()
> > on such platforms.
> >
> > Can you please check your boot log which revision it claims to implement now?
> >
> > Mine says
> >
> > efi: EFI v1.10 by Apple
>
> Mine says
>
> efi: EFI v2.40 by Apple
>
> >
> > near the start of the kernel log.
> >
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/runtime-wrappers.c#n220
> >> and within that section, the invalid opcode seems to be occurring in
> >> this bit of assembly:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/platform/efi/efi_stub_64.S
> >>
> >
> > Ehm no. __efi_call() is just a trampoline to call into the firmware,
> > and the opcodes in question are firmware code not Linux code.
>
On Mon, 10 Jan 2022 at 17:37, Ard Biesheuvel <[email protected]> wrote:
>
> On Mon, 10 Jan 2022 at 17:28, Aditya Garg <[email protected]> wrote:
...
> > >>
> > >> This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
> > >>
> > >
> > > This is interesting. QueryVariableInfo() was introduced in EFI 2.00,
> > > and for a very long time, Intel MACs would claim to implement EFI 1.10
> > > only. This means Linux would never attempt to use QueryVariableInfo()
> > > on such platforms.
> > >
> > > Can you please check your boot log which revision it claims to implement now?
> > >
> > > Mine says
> > >
> > > efi: EFI v1.10 by Apple
> >
> > Mine says
> >
> > efi: EFI v2.40 by Apple
> >
Can you check whether things work as before after applying the change below?
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 147c30a81f15..d7203355cc69 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -399,7 +399,7 @@ static int __init efi_systab_init(unsigned long phys)
efi_nr_tables = systab32->nr_tables;
}
- efi.runtime_version = hdr->revision;
+ efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
efi_systab_report_header(hdr, efi_fw_vendor);
early_memunmap(p, size);
On Tue, 11 Jan 2022 04:45:35 +1100
"Ard Biesheuvel" <[email protected]> wrote:
> On Mon, 10 Jan 2022 at 17:37, Ard Biesheuvel <[email protected]> wrote:
> >
> > On Mon, 10 Jan 2022 at 17:28, Aditya Garg <[email protected]>
> > wrote:
> ...
> > > >>
> > > >> This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
> > > >>
> > > >
> > > > This is interesting. QueryVariableInfo() was introduced in EFI
> > > > 2.00, and for a very long time, Intel MACs would claim to
> > > > implement EFI 1.10 only. This means Linux would never attempt
> > > > to use QueryVariableInfo() on such platforms.
> > > >
> > > > Can you please check your boot log which revision it claims to
> > > > implement now?
> > > >
> > > > Mine says
> > > >
> > > > efi: EFI v1.10 by Apple
> > >
> > > Mine says
> > >
> > > efi: EFI v2.40 by Apple
> > >
>
> Can you check whether things work as before after applying the change
> below?
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 147c30a81f15..d7203355cc69 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -399,7 +399,7 @@ static int __init efi_systab_init(unsigned long
> phys) efi_nr_tables = systab32->nr_tables;
> }
>
> - efi.runtime_version = hdr->revision;
> + efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
>
> efi_systab_report_header(hdr, efi_fw_vendor);
> early_memunmap(p, size);
This patch works for me, I was able to use `efibootmgr -t 2` without
panics and the change to the boot timeout value persisted after a
reboot. (I don't think the Apple firmware would actually use this
timeout value for a timeout time, but it is an nvram vairable that i
was able to write to)
efi: EFI v2.40 by Apple
efi: ACPI=0x7affe000 ACPI 2.0=0x7affe014 SMBIOS=0x7aed0000 SMBIOS 3.0=0x7aece000
SMBIOS 3.1.1 present.
DMI: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1715.60.5.0.0 (iBridge: 19.16.10647.0.0,0) 11/16/2021
("iBridge" might be something to use for a quirk, as it should cover
all Macs with the T2 chip)
--
> On 10-Jan-2022, at 11:15 PM, Ard Biesheuvel <[email protected]> wrote:
>
> On Mon, 10 Jan 2022 at 17:37, Ard Biesheuvel <[email protected]> wrote:
>>
>> On Mon, 10 Jan 2022 at 17:28, Aditya Garg <[email protected]> wrote:
> ...
>>>>>
>>>>> This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
>>>>>
>>>>
>>>> This is interesting. QueryVariableInfo() was introduced in EFI 2.00,
>>>> and for a very long time, Intel MACs would claim to implement EFI 1.10
>>>> only. This means Linux would never attempt to use QueryVariableInfo()
>>>> on such platforms.
>>>>
>>>> Can you please check your boot log which revision it claims to implement now?
>>>>
>>>> Mine says
>>>>
>>>> efi: EFI v1.10 by Apple
>>>
>>> Mine says
>>>
>>> efi: EFI v2.40 by Apple
>>>
>
> Can you check whether things work as before after applying the change below?
Patch works for me Ard :)
I am able to boot without efi=norumtime now.
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 147c30a81f15..d7203355cc69 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -399,7 +399,7 @@ static int __init efi_systab_init(unsigned long phys)
> efi_nr_tables = systab32->nr_tables;
> }
>
> - efi.runtime_version = hdr->revision;
> + efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
>
> efi_systab_report_header(hdr, efi_fw_vendor);
> early_memunmap(p, size);
> On 11-Jan-2022, at 10:47 AM, Orlando Chamberlain <[email protected]> wrote:
>
> On Tue, 11 Jan 2022 04:45:35 +1100
> "Ard Biesheuvel" <[email protected]> wrote:
>
>> On Mon, 10 Jan 2022 at 17:37, Ard Biesheuvel <[email protected]> wrote:
>>>
>>> On Mon, 10 Jan 2022 at 17:28, Aditya Garg <[email protected]>
>>> wrote:
>> ...
>>>>>>
>>>>>> This seems to be triggered by EFI_QUERY_VARIABLE_INFO here
>>>>>>
>>>>>
>>>>> This is interesting. QueryVariableInfo() was introduced in EFI
>>>>> 2.00, and for a very long time, Intel MACs would claim to
>>>>> implement EFI 1.10 only. This means Linux would never attempt
>>>>> to use QueryVariableInfo() on such platforms.
>>>>>
>>>>> Can you please check your boot log which revision it claims to
>>>>> implement now?
>>>>>
>>>>> Mine says
>>>>>
>>>>> efi: EFI v1.10 by Apple
>>>>
>>>> Mine says
>>>>
>>>> efi: EFI v2.40 by Apple
>>>>
>>
>> Can you check whether things work as before after applying the change
>> below?
>>
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 147c30a81f15..d7203355cc69 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/platform/efi/efi.c
>> @@ -399,7 +399,7 @@ static int __init efi_systab_init(unsigned long
>> phys) efi_nr_tables = systab32->nr_tables;
>> }
>>
>> - efi.runtime_version = hdr->revision;
>> + efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
>>
>> efi_systab_report_header(hdr, efi_fw_vendor);
>> early_memunmap(p, size);
>
> This patch works for me, I was able to use `efibootmgr -t 2` without
> panics and the change to the boot timeout value persisted after a
> reboot. (I don't think the Apple firmware would actually use this
> timeout value for a timeout time, but it is an nvram vairable that i
> was able to write to)
>
> efi: EFI v2.40 by Apple
> efi: ACPI=0x7affe000 ACPI 2.0=0x7affe014 SMBIOS=0x7aed0000 SMBIOS 3.0=0x7aece000
> SMBIOS 3.1.1 present.
> DMI: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1715.60.5.0.0 (iBridge: 19.16.10647.0.0,0) 11/16/2021
>
> ("iBridge" might be something to use for a quirk, as it should cover
> all Macs with the T2 chip)
Ard said that Intel Macs have been implementing EFI 1.10 for a long time. If we want to implement the same for T2 Macs too, which claim to use EFI 2.40, maybe we could force implement the same for all Apple Macs? The M1 and later shall use arm so shouldn't be affected. The T2 Macs probably are the last Intel Macs.
>
>
> --
>
Hi Ard
As I said before, if I apply the patch below, the things work well
>
> Can you check whether things work as before after applying the change below?
>
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 147c30a81f15..d7203355cc69 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -399,7 +399,7 @@ static int __init efi_systab_init(unsigned long phys)
> efi_nr_tables = systab32->nr_tables;
> }
>
> - efi.runtime_version = hdr->revision;
> + efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
>
> efi_systab_report_header(hdr, efi_fw_vendor);
> early_memunmap(p, size);
Now, I tried to quirk on the basis of DMI data for some t2 Macs using this patch :-
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 147c30a81..0d73d7709 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -44,6 +44,7 @@
#include <linux/io.h>
#include <linux/reboot.h>
#include <linux/bcd.h>
+#include <linux/dmi.h>
#include <asm/setup.h>
#include <asm/efi.h>
@@ -339,6 +340,52 @@ void __init efi_print_memmap(void)
}
}
+static const struct dmi_system_id apple_use_old_runtime_version[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,4"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MacBookAir8,2"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,2"),
+ },
+ },
+ { }
+};
+
static int __init efi_systab_init(unsigned long phys)
{
int size = efi_enabled(EFI_64BIT) ? sizeof(efi_system_table_64_t)
@@ -347,6 +394,7 @@ static int __init efi_systab_init(unsigned long phys)
bool over4g = false;
void *p;
int ret;
+ const struct dmi_system_id *dmi_id;
hdr = p = early_memremap_ro(phys, size);
if (p == NULL) {
@@ -398,8 +446,15 @@ static int __init efi_systab_init(unsigned long phys)
efi_config_table = systab32->tables;
efi_nr_tables = systab32->nr_tables;
}
-
- efi.runtime_version = hdr->revision;
+
+ dmi_id = dmi_first_match(apple_use_old_runtime_version);
+ if (dmi_id) {
+ efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
+ pr_info("T2 Mac detected. Using runtime service version 1.10\n");
+ }
+ else {
+ efi.runtime_version = hdr->revision;
+ }
efi_systab_report_header(hdr, efi_fw_vendor);
early_memunmap(p, size);
--
2.25.1
But, now the issue doesn't seen to get resolved
Could you help me in this?
On Wed, 12 Jan 2022 at 07:23, Aditya Garg <[email protected]> wrote:
>
> Hi Ard
> As I said before, if I apply the patch below, the things work well
> >
> > Can you check whether things work as before after applying the change below?
> >
> > diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > index 147c30a81f15..d7203355cc69 100644
> > --- a/arch/x86/platform/efi/efi.c
> > +++ b/arch/x86/platform/efi/efi.c
> > @@ -399,7 +399,7 @@ static int __init efi_systab_init(unsigned long phys)
> > efi_nr_tables = systab32->nr_tables;
> > }
> >
> > - efi.runtime_version = hdr->revision;
> > + efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
> >
> > efi_systab_report_header(hdr, efi_fw_vendor);
> > early_memunmap(p, size);
>
> Now, I tried to quirk on the basis of DMI data for some t2 Macs using this patch :-
>
Hello Aditya,
This code runs far too early for DMI checks.
What we might do is just use EFI 1.10 for all Apple x86 EFI machines.
Please try the below:
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ae79c3300129..2303f9b06412 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -722,6 +722,13 @@ void __init efi_systab_report_header(const
efi_table_hdr_t *systab_hdr,
systab_hdr->revision >> 16,
systab_hdr->revision & 0xffff,
vendor);
+
+ if (IS_ENABLED(CONFIG_X86_64) &&
+ systab_hdr->revision > EFI_1_10_SYSTEM_TABLE_REVISION &&
+ !strcmp(vendor, "Apple")) {
+ pr_info("Apple EFI Mac detected, using EFI v1.10
runtime services only\n");
+ efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
+ }
}
static __initdata char memory_type_name[][13] = {
On Wed, 12 Jan 2022 19:21:55 +1100
"Ard Biesheuvel" <[email protected]> wrote:
> What we might do is just use EFI 1.10 for all Apple x86 EFI machines.
I have found logs of pre-T2 x86 Macs that have EFI v2.40 but I haven't
heard of them having the issue with writing to nvram:
[ 0.000000] efi: EFI v2.40 by Apple
[ 0.000000] efi: ACPI=0x88ffe000 ACPI 2.0=0x88ffe014 SMBIOS=0x88f00000 SMBIOS 3.0=0x88efe000
[ 0.000000] secureboot: Secure boot disabled
[ 0.000000] SMBIOS 3.0.0 present.
[ 0.000000] DMI: Apple Inc. MacBookPro14,1/Mac-B4831CEBD52A0C4C, BIOS XXX.XXX.XXX.XXX.0 04/24/2020
MacBookPro14,1 [1], and MacBookPro13,1 [2] have EFI v2.40, but
MacBookPro12,1 [3] has v1.10
[1] https://linux-hardware.org/?probe=b1b965bcfa&log=dmesg
[2] https://linux-hardware.org/?probe=df102d9c8c&log=dmesg
[3] https://linux-hardware.org/?probe=ef5195a62e&log=dmesg
I don't know if this would mean the other Macs with EFI v2.40 would lose
any functionality due to a patch like this (I'm not familiar with what
was added to the runtime services between v1.10 and v2.40).
> Please try the below:
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index ae79c3300129..2303f9b06412 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -722,6 +722,13 @@ void __init efi_systab_report_header(const
> efi_table_hdr_t *systab_hdr,
> systab_hdr->revision >> 16,
> systab_hdr->revision & 0xffff,
> vendor);
> +
> + if (IS_ENABLED(CONFIG_X86_64) &&
> + systab_hdr->revision > EFI_1_10_SYSTEM_TABLE_REVISION &&
> + !strcmp(vendor, "Apple")) {
> + pr_info("Apple EFI Mac detected, using EFI v1.10
> runtime services only\n");
> + efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
> + }
> }
>
> static __initdata char memory_type_name[][13] = {
This patch makes writing to nvram work for me on MacBookPro16,1
--
On Wed, 12 Jan 2022 at 10:06, Orlando Chamberlain
<[email protected]> wrote:
>
> On Wed, 12 Jan 2022 19:21:55 +1100
> "Ard Biesheuvel" <[email protected]> wrote:
> > What we might do is just use EFI 1.10 for all Apple x86 EFI machines.
>
> I have found logs of pre-T2 x86 Macs that have EFI v2.40 but I haven't
> heard of them having the issue with writing to nvram:
>
> [ 0.000000] efi: EFI v2.40 by Apple
> [ 0.000000] efi: ACPI=0x88ffe000 ACPI 2.0=0x88ffe014 SMBIOS=0x88f00000 SMBIOS 3.0=0x88efe000
> [ 0.000000] secureboot: Secure boot disabled
> [ 0.000000] SMBIOS 3.0.0 present.
> [ 0.000000] DMI: Apple Inc. MacBookPro14,1/Mac-B4831CEBD52A0C4C, BIOS XXX.XXX.XXX.XXX.0 04/24/2020
>
> MacBookPro14,1 [1], and MacBookPro13,1 [2] have EFI v2.40, but
> MacBookPro12,1 [3] has v1.10
>
> [1] https://linux-hardware.org/?probe=b1b965bcfa&log=dmesg
> [2] https://linux-hardware.org/?probe=df102d9c8c&log=dmesg
> [3] https://linux-hardware.org/?probe=ef5195a62e&log=dmesg
>
Thanks for providing this context, this is really helpful.
> I don't know if this would mean the other Macs with EFI v2.40 would lose
> any functionality due to a patch like this (I'm not familiar with what
> was added to the runtime services between v1.10 and v2.40).
>
The only differences are capsule update (which we don't use at runtime
anyway, and isn't implemented on Macs as far as I know), and this
QueryVariableInfo() runtime service that is causing the issue. The
efivars code only uses that when it is available, to avoid breaking
systems with buggy firmware when setting variables while the NVRAM is
out of space.
So in summary, this shouldn't matter for Apple machines.
> > Please try the below:
> >
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index ae79c3300129..2303f9b06412 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -722,6 +722,13 @@ void __init efi_systab_report_header(const
> > efi_table_hdr_t *systab_hdr,
> > systab_hdr->revision >> 16,
> > systab_hdr->revision & 0xffff,
> > vendor);
> > +
> > + if (IS_ENABLED(CONFIG_X86_64) &&
> > + systab_hdr->revision > EFI_1_10_SYSTEM_TABLE_REVISION &&
> > + !strcmp(vendor, "Apple")) {
> > + pr_info("Apple EFI Mac detected, using EFI v1.10
> > runtime services only\n");
> > + efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
> > + }
> > }
> >
> > static __initdata char memory_type_name[][13] = {
>
> This patch makes writing to nvram work for me on MacBookPro16,1
>
Thanks. I will take that as a tested-by