Package: linux-image-5.7.0-1-amd64
Severity: normal
Dear Maintainer,
We have a number of MinnowBoards (Intel Atom based SBC with TianoCore EDK II
UEFI firmware) that we use for development of the Debian derived Apertis
distribution. We have recently found that these boards are stalling for
approximately 5 minutes during boot, after the firmware has printed the
following message:
>>>>Clear memory in MRC per MOR request Start, Please wait for some
minutes...
This is replicable with a vanilla Debian image too.
I have performed some diagnosis of the issue and this is what I've discovered:
The delay is a result of the UEFI firmware on the Minnowboard performing a
"MemoryOverwriteRequest", due to it finding that the related
"MemoryOverwriteRequestControl" EFI variable is set.
The kernel provides functionality via the "CONFIG_RESET_ATTACK_MITIGATION"
option to set this bit on boot, which is enabled in the Debian config.
When this option is enabled and the required functionality is present, the
intention appears to be that this EFI variable, which is exposed via
`/sys/firmware/efi/efivars/MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829`,
is cleared by user space on a "clean shutdown after secrets have been evicted"
from memory, as stated in the relevant kernel config option (1). The config
option also suggests that "This should only be enabled when userland is
configured to clear the MemoryOverwriteRequest flag". I have not been able to
find such a mechanism provided in Debian, thus I'd expect to see this memory
clean to end up being performed at every boot where this functionality is
provided.
Of the 6 amd64/x64 based devices I had available for testing, 2 of the machines
(including the MinnowBoard) exposed this EFI variable. The other (an AMD Ryzen
based laptop) didn't seem to present this issue/delay at boot. I am thus unsure
how frequently this issue will be hit by Debian users.
As a Debian user, I am raising this bug to ensure the potentially rare but
inconvenient side effect of having this option enabled have been raised and
indexed somewhere (it's not been the easiest issue to find information about)
and to enable a discussion regarding the suitability of enabling this option by
default in Debian.
Thanks,
Martyn
1)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/Kconfig#n202
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, i386
Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-image-5.7.0-1-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.139
ii kmod 27+20200310-2
ii linux-base 4.6
Versions of packages linux-image-5.7.0-1-amd64 recommends:
ii apparmor 2.13.4-3
ii firmware-linux-free 20200122-1
Versions of packages linux-image-5.7.0-1-amd64 suggests:
pn debian-kernel-handbook <none>
ii grub-efi-amd64 2.04-8
pn linux-doc-5.7 <none>
