linux-kernel - Re: [BUG][SEVERE] Enabling EFI runtime services causes panics in the T2 security chip on Macs equipped with it.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Jan 2022 16:27:57 +0000
From:   Aditya Garg <gargaditya08@...e.com>
To:     Ard Biesheuvel <ardb@...nel.org>
CC:     "matthew.garrett@...ula.com" <matthew.garrett@...ula.com>,
        "jk@...abs.org" <jk@...abs.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Orlando Chamberlain <redecorating@...tonmail.com>,
        Aun-Ali Zaidi <admin@...eit.net>
Subject: Re: [BUG][SEVERE] Enabling EFI runtime services causes panics in the
 T2 security chip on Macs equipped with it.


> 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.