lkml.org 
[lkml]   [2022]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [BUG][SEVERE] Enabling EFI runtime services causes panics in the T2 security chip on Macs equipped with it.
On Wed, 12 Jan 2022 at 10:06, Orlando Chamberlain
<redecorating@protonmail.com> wrote:
>
> On Wed, 12 Jan 2022 19:21:55 +1100
> "Ard Biesheuvel" <ardb@kernel.org> 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

\
 
 \ /
  Last update: 2022-01-12 10:14    [W:0.042 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site