Super-UEFIinSecureBoot-Disk VS release

You can edit UEFI drivers from the operating system's bootloader, and you can even flash the UEFI itself from the OS in most computers. While secure boot. Failing that, you can shim a preloader between the bootloader and the UEFI and load arbitrary drivers despite secure boot, like is done here : https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

Any sufficiently motivated attacker can make a UEFI rootkit happen, and it's in the wild right now. TPM really do offer no protection to users, either against userspace malware, or rootkits. It's purely about DRM.

Badabing badaboom

I was able to get around this by using a signed grub bootloader instead. What I did was modify a minimal grub disk from here to point to my manjaro installation using the partition uuid in its grub config. Its basically used to bypass secure boot and chainload the default unsigned grub2 which will start the system.

Try this if you want FreeBSD on a Secure Boot PC. I do this on my work PC.

This project works pretty good getting around the forced secure boot with the VCS: https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

The image above represents an error I ran into while building Potabi on Sept-9, 2021. The build is currently supposed to be using the RE Base release b_1.0a-base, the files of which are listed below. For testing purposes, I grabbed the RE Base b_1.0a-base disc1.iso file, as listed in the release. I ran it in QEMU on my personal machine, where the difference in bases between here and on the FreeBSD virtual machine being used for builds should be non-existent. Since I am coming back into development a month after I last did anything, I cannot say with any certainty that this will provide anything useful, but on The Potabi Foundation YouTube Channel, I uploaded a timelapse of this build for fun, not even trying to use it to help debug anything. It shows no issue, as far as I can tell.