On Wed, Jul 15, 2020 at 01:17:50PM -0600, Chris Murphy wrote:
> On Wed, Jul 15, 2020 at 12:49 PM Solomon Peachy <pizza@xxxxxxxxxxxx> wrote:
> >
> > On Wed, Jul 15, 2020 at 01:41:27PM -0500, Michael Catanzaro wrote:
> > > Note: memtest86+ actually had an upstream release recently after a *very*
> > > long hiatus, so I guess it's no longer dead. But I agree memtest86+ should
> > > be dropped, since it's incompatible with UEFI and surely not what we want
> > > people to try using.
> >
> > Yes and no -- having it available on the fedora installer media is quite
> > useful, and since that's going to have to support dual BIOS/UEFI
> > booting, there's not really any downside.
>
> The same binary can't support both firmware types. As far as I know,
> only the proprietary version offers a UEFI binary. And long ago the
> plan for the free version was not to have dual support, but to
> eventually deprecate the BIOS tester and only offer a UEFI binary.
If someone decided they wanted to spend some time making memtest86+ work
as an EFI binary, I'd be happy to mentor them. I think getting it to
the point where it can test everything except the RAM UEFI is actually
/using/ is probably a medium difficulty but not huge project. It's been
waaay down on my todo list forever, and I've got some ideas about how to
go about it, just not the time to do it myself.
> But another difficulty even if there will be a free UEFI memtest86+ is
> that it would need to be signed for UEFI Secure Boot, same as shim and
> the kernel (and kernel modules). Seems like its own burden.
If we had a UEFI memory tester, you could reasonably add a boot entry
for shim with memtest.efi as the optional loader data (like we do for
fwupd) and enroll it in MoK with something like:
pesign -i memtest.efi -P -h | while read name hash ; do
mokutil --import-hash ${hash}
done
There's not a super *huge* benefit to actually signing it, since you're
sure to be rebooting when you need to use it anyway.
--
Peter
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
