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] [day] [month] [year] [list]

Message-ID: <CAMj1kXEiVmsQxEsKOy1GwtZRQQ04Wei0OvyBofs1UQy5WxW-pg@mail.gmail.com>
Date:   Wed, 12 Jan 2022 10:13:05 +0100
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Orlando Chamberlain <redecorating@...tonmail.com>
Cc:     Aditya Garg <gargaditya08@...e.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>,
        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 Wed, 12 Jan 2022 at 10:06, Orlando Chamberlain
<redecorating@...tonmail.com> wrote:
>
> On Wed, 12 Jan 2022 19:21:55 +1100
> "Ard Biesheuvel" <ardb@...nel.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