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]
Message-ID: <CAMj1kXGem3QB0rj-b57xrcDYkCv6Moi=RX1OUspj3s4vMtsdug@mail.gmail.com>
Date:   Mon, 10 Jan 2022 17:37:57 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Aditya Garg <gargaditya08@...e.com>
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.

On Mon, 10 Jan 2022 at 17:28, Aditya Garg <gargaditya08@...e.com> 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.
>