linux-kernel - Re: [PATCH] x86/efistub: Don't try to print after ExitBootService()

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: <9346655c-df15-498b-a6e3-f6dd918c663a@suse.com>
Date:   Thu, 12 Oct 2023 14:28:31 +0300
From:   Nikolay Borisov <nik.borisov@...e.com>
To:     ardb@...nel.org
Cc:     linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH] x86/efistub: Don't try to print after ExitBootService()



On 12.10.23 г. 13:14 ч., kirill.shutemov@...ux.intel.com wrote:
> On Wed, Oct 11, 2023 at 10:25:28PM +0300, Nikolay Borisov wrote:
>> setup_e820() is executed after UEFI's ExitBootService has been called.
>> This causes the firmware to throw an exception because Console IO
>> protocol handler is supposed to work only during boot service
>> environment. As per UEFI 2.9, section 12.1:
>>
>>   "This protocol isused to handle input and output of text-based
>>   information intended for the system user during the operation of code
>>   in the boot services environment."
>>
>> Running a TDX guest with TDVF with unaccepted memory disabled results in
>> the following output:
> 
> Oh. My bad.
> 
> But there's other codepath that does the same. If setup_e820() fails with
> EFI_BUFFER_TOO_SMALL, efi_stub_entry() would try to print "exit_boot()
> failed\n".
> 
> I wouldner if it is feasible to hook up earlyprintk console into
> efi_printk() machinery for after ExitBootService() case? Silent boot
> failure is not the best UX.
> 

So looking at the code the only thing which would prevent refactoring to 
exit logic to directly call exit_boot_func etc and setup_e820 before 
calling efi_exit_boot_services is if the memory map changes. The current 
code ensures that we really have the latest memory map version and so 
setup_e820 is called with the latest version.

Ard, how likely it is that the memory map can indeed change between the 
calls to getmemorymap and exitbootservice?