linux-kernel - Re: UEFI EBS() failures on Lenovo T14s

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: <Z0g_HL01eqXu4cwQ@hovoldconsulting.com>
Date: Thu, 28 Nov 2024 10:59:56 +0100
From: Johan Hovold <johan@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Leif Lindholm <leif.lindholm@....qualcomm.com>,
	Bjorn Andersson <andersson@...nel.org>,
	Ricardo Salveti <ricardo@...ndries.io>,
	Marc Zyngier <maz@...nel.org>, linux-efi@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: UEFI EBS() failures on Lenovo T14s

On Thu, Nov 28, 2024 at 09:52:33AM +0100, Ard Biesheuvel wrote:

> On Thu, 28 Nov 2024 at 09:20, Johan Hovold <johan@...nel.org> wrote:

> > We've run into a buggy UEFI implementation on the Qualcomm Snapdragon
> > based Lenovo ThinkPad T14s where ExitBootServices() often fails.

> > Based on your comments to a similar report for an older Snapdragon based
> > Lenovo UEFI implementation [1], I discovered that allocating an event
> > before calling ExitBootServices() can make the call succeed. There is
> > often no need to actually signal the event group, but the event must
> > remain allocated (i.e. CloseEvent() must not be called).
> >
> > (Raising TPL or disabling interrupts does not seem to help.)
> >
> > Also with the event signalling, ExitBootServices() sometimes fails when
> > starting the kernel automatically from a shell startup.nsh, while
> > systemd-boot seems to always work. This was only observed after removing
> > some efi_printk() used during the experiments from the stub..
.
> So the error code is EFI_INVALID_PARAMETER in all cases? In the
> upstream implementation, the only thing that can make
> ExitBootServices() return an error is a mismatch of the map key, and
> so there is something changing the memory map.

Yes, it's always EFI_INVALID_PARAMETER.

> This might be due to a handler of the
> gEfiEventBeforeExitBootServicesGuid event group that fails to close
> the event, and so it gets signaled every time. This is a fairly recent
> addition, though, so I'm not sure it even exists in QCOM's tree.
> 
> In upstream EDK2, the map key is just a monotonic counter that gets
> incremented on every memory map update, so one experiment worth
> conducting is to repeat the second call to ExitBootServices() a couple
> of times, increasing the map key each time. 

I had already tried repeating the second call (GMM + EBS) by running it
in a loop, and I do see the map_key increasing for each iteration (e.g.
by 0x1a).

> Or use GetMemoryMap() to
> just grab the map key without the actual memory map, and printing it
> to the console (although the timer is disabled on the first call so
> anything that relies on that will be shut down at this point)

I just tried adding another inner loop just calling GetMemoryMap() a few
times and I see the map_key increasing there too for each iteration
(e.g. by 0x6).

(The map size remains constant.)

I do get the feeling that efi_printk() contributes to the memory map
updates, and I can indeed get the reference design fw to similarly fail
if I try to print the map_key after each call to GetMemoryMap() in a
retry loop.

Johan