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: <CAMj1kXFtr7ejEjjSRj9dcRa7YbO0SR5OR3pm+K6OvbX2=RfhAQ@mail.gmail.com>
Date: Thu, 28 Nov 2024 11:21:34 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Johan Hovold <johan@...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, 28 Nov 2024 at 11:00, Johan Hovold <johan@...nel.org> wrote:
>
> On Thu, Nov 28, 2024 at 09:52:33AM +0100, Ard Biesheuvel wrote:
>
...
> > 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.

Per the spec, the only thing you are permitted to call if
ExitBootServices() fails is GetMemoryMap(), and so this is not a spec
violation.

If GetMemoryMap() itself causes the map key to assume a different
value than the one it returns, or if ExitBootServices() invokes event
callbacks on the second call that may cause the map key to get updated
before it manages to check it, there is obviously something wrong in
the firmware implementation.