[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#970861: marked as done (linux-image-5.7.0-1-amd64: RESET_ATTACK_MITIGATION functionality causing 4-5 min delay in boot on MinnowBoards)

Your message dated Thu, 20 Feb 2025 13:21:50 +0100 (CET)
with message-id <20250220122150.D1F5CBE2EE7@eldamar.lan>
and subject line Closing this bug (BTS maintenance for src:linux bugs)
has caused the Debian Bug report #970861,
regarding linux-image-5.7.0-1-amd64: RESET_ATTACK_MITIGATION functionality causing 4-5 min delay in boot on MinnowBoards
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
970861: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970861
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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>

--- End Message ---
--- Begin Message --- 
Hi

This bug was filed for a very old kernel or the bug is old itself
without resolution.

If you can reproduce it with

- the current version in unstable/testing
- the latest kernel from backports

please reopen the bug, see https://www.debian.org/Bugs/server-control
for details.

Regards,
Salvatore

--- End Message ---
Reply to: