Memtest gives "bad shim signature" error

[Beyil]

when you select memtest from the Grub menu with Secure boot enable you get the error of "Bad Shim Signature" I should not need to disable secure boot just to run this test, which then opens up the system for other security issues...

ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: memtest86+ 6.20-3
ProcVersionSignature: Ubuntu 6.2.0-36.37-generic 6.2.16
Uname: Linux 6.2.0-36-generic x86_64
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: KDE
Date: Sat Nov 18 17:30:24 2023
InstallationDate: Installed on 2023-10-22 (28 days ago)
InstallationMedia: Kubuntu 23.04 "Lunar Lobster" - Release amd64 (20230414.1)
SourcePackage: memtest86+
UpgradeStatus: Upgraded to mantic on 2023-11-18 (1 days ago)

[Marc Deslauriers (mdeslaur)]

Can I make this bug public so the developers can see it?

[Beyil (rjbgolding)]

Please do. I am suspecting someone did not have the Memtest86+ signed like the kernels...

[Fantu (fantonifabio)]

Exactly, signature for secureboot support "out of the box" is actually missed.
No ETA on this, that seems a steady progress: https://github.com/rhboot/shim-review/issues/314
disabling it temporarily for the sole execution of memtest does not pose a risk, the risk is if you run something infected and affects the bootloader within Windows or Linux systems (much rarer, but there is malware for it too).
another note: secureboot mitigates these problems but does not avoid them because unfortunately there are also malware that manage to act on the boot even with secureboot active (through vulnerabilities or valid keys)

[Beyil (rjbgolding)]

would it be a large hurdle to have each distro that uses it to sign it while they are building their final builds?? like Canonical signs it just like they sign the kernels that they use for each release, which would then have it signed for all the sub flavors of ubuntu...

[Fantu (fantonifabio)]

If I'm not mistaken, once the build has been done with a valid signature on Debian and the package has been synchronized in the derivatives (normally it's just a sync from Debian) there would be no need to do anything else

[Beyil (rjbgolding)]

this may tie into another bug that may or may not have been fixed. I have a Multiboot system. When I had it running with the MBR style of only one boot drive, grub kept getting overwritten with the other distro's. As long as it was one of the ubuntu flavors I had no issues but as soon as it was debian or fedora going to ubuntu it gave a shim mismatch error and would not boot. I ended up stripping out all of the boot selectors and then setting up an EFI partition on each distro's drive to keep them all separated to their own drive, then using the UEFI boot selector to set which drive and distro to boot from. this included telling the installer to use the drive that distro was going to and setting the EFI flag to datadrive on all the EFI boot partitions save the one that that distro was being installed to so it would not install on a different drive despite what it was told in the installer... updating is not an issue as it doesn't attempt to redo the drive mapping unlike the initial installer, anyways I degressed into another issue but it giving that mismatch may also extend to this issue...