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: <1DA0C4D6-F14D-4342-9533-A50ED1DD4BDF@live.com>
Date:   Tue, 11 Jan 2022 07:35:52 +0000
From:   Aditya Garg <gargaditya08@...e.com>
To:     Orlando Chamberlain <redecorating@...tonmail.com>
CC:     Ard Biesheuvel <ardb@...nel.org>, "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 11-Jan-2022, at 10:47 AM, Orlando Chamberlain <redecorating@...tonmail.com> wrote:
> 
> On Tue, 11 Jan 2022 04:45:35 +1100
> "Ard Biesheuvel" <ardb@...nel.org> wrote:
> 
>> On Mon, 10 Jan 2022 at 17:37, Ard Biesheuvel <ardb@...nel.org> wrote:
>>> 
>>> On Mon, 10 Jan 2022 at 17:28, Aditya Garg <gargaditya08@...e.com>
>>> wrote:  
>> ...
>>>>>> 
>>>>>> 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
>>>> 
>> 
>> Can you check whether things work as before after applying the change
>> below?
>> 
>> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
>> index 147c30a81f15..d7203355cc69 100644
>> --- a/arch/x86/platform/efi/efi.c
>> +++ b/arch/x86/platform/efi/efi.c
>> @@ -399,7 +399,7 @@ static int __init efi_systab_init(unsigned long
>> phys) efi_nr_tables           = systab32->nr_tables;
>>        }
>> 
>> -       efi.runtime_version = hdr->revision;
>> +       efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
>> 
>>        efi_systab_report_header(hdr, efi_fw_vendor);
>>        early_memunmap(p, size);
> 
> This patch works for me, I was able to use `efibootmgr -t 2` without
> panics and the change to the boot timeout value persisted after a
> reboot. (I don't think the Apple firmware would actually use this
> timeout value for a timeout time, but it is an nvram vairable that i
> was able to write to)
> 
> efi: EFI v2.40 by Apple
> efi: ACPI=0x7affe000 ACPI 2.0=0x7affe014 SMBIOS=0x7aed0000 SMBIOS 3.0=0x7aece000 
> SMBIOS 3.1.1 present.
> DMI: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1715.60.5.0.0 (iBridge: 19.16.10647.0.0,0) 11/16/2021
> 
> ("iBridge" might be something to use for a quirk, as it should cover
> all Macs with the T2 chip)
Ard said that Intel Macs have been implementing EFI 1.10 for a long time. If we want to implement the same for T2 Macs too, which claim to use EFI 2.40, maybe we could force implement the same for all Apple Macs? The M1 and later shall use arm so shouldn't be affected. The T2 Macs probably are the last Intel Macs.
> 
> 
> -- 
>