linux-kernel - Re: [BUG] 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] [day] [month] [year] [list]

Message-ID: <20211209071935.13996bb1@localhost>
Date:   Thu, 09 Dec 2021 07:19:37 +0000
From:   Orlando Chamberlain <redecorating@...tonmail.com>
To:     Aditya Garg <gargaditya08@...e.com>
Cc:     "matthew.garrett@...ula.com" <matthew.garrett@...ula.com>,
        "jk@...abs.org" <jk@...abs.org>,
        "ardb@...nel.org" <ardb@...nel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] Enabling EFI runtime services causes panics in the T2 security chip on Macs equipped with it.

On Thu, 09 Dec 2021 18:05:35 +1100
"Aditya Garg" <gargaditya08@...e.com> wrote:

> On enabling EFI runtime services on Macs with the T2 security chip,
> kernel fails to boot due panics in the T2 security chip. Using

I think it only fails to boot if something is set up to write to nvram
at boot, I can boot fine on a MacBookPro16,1 as long as I don't have
anything writing to nvram (deleting and reading variables is fine).

> 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

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"


--