To sum it all up, I was looking to completely migrate from Windows 10 to Linux Mint (version 22, Cinnamon Edition). I followed an installation tutorial on YouTube, flashed the ISO to a bootable flash drive using balenaEtcher and booted Mint in my notebook. Something went wrong during the installation though: I tried to go a few steps back to review my options, and when I tried to proceed again I was met with this error:
ubi-partman failed with exit code 10
It seems it means there was a problem with partitions (I selected the option to wipe Windows and replace it with Mint in the installer), so I quit Mint and tried to boot it again so I could redo the installation. However, when i tried to boot it again I was met with this error:
Failed to open \EFI\BOOT\mmx64.efi - Not Found Failed to load image ??: Not Found Failed to start MokManager: Not Found Something has gone seriously wrong: import_mok_state() failed: Not Found
So essentially, since my Windows 10 system was wiped, I was left without an OS. So I looked up the error and it seems it’s because version 22 of Mint doesn’t have MokManager (don’t know how it booted the first time then, but okay), so downloaded the ISO for a different one (version 21.2, Cinnamon Edition) that does have it and flashed my flash drive with it (on a different laptop, since mine was wiped.) When I tried to boot it to my laptop, I was met with yet another error:
Verifying shim SBAT data failed: Security Policy Violation Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation
Now, it seems this will be solved by disabling Secure Boot in the BIOS. However, I’m a bit aprehensive on disabling Secure Boot, since the laptop I used to flash the OS into my bootable drive is a very, very old and unupdated machine. What are the odds of my flash drive being infected with malware that can compromise the installation if i disable Secure Boot? What should I do in this situation? Can anyone shine me some light? Any help would be appreciated, thanks!
It is highly unlikely that you have malware sophisticated enough to do something like compromise installation media (already exceedingly rare) yet not sophisticated enough to bypass secure boot.
The purpose of secure boot is to verify that the boot loader and kernel are approved by the manufacturer (or friends of such). There are certainly ways to inject software into a system that doesn’t reside in those locations. It just makes boot sector viruses and kernel mode rootkits slightly more technically challenging to write when you can’t simply modify those parts of the operating system directly. If malware gets root on your installation it’s game over whether or not you have secure boot enabled. Much of the software in a computer is none of those things protected by secure boot.
Plus, take another wager: most systems today ship with secure boot enabled. If you were a malware author, would you still be writing malware that needs secure boot turned off to run? Of course not! You would focus on the most common system you can to maximize impact. This, boot sector viruses are mostly lose to time. Malware authors moved on.
Overall, it’s a pretty inconsequential feature born of good intentions but practically speaking malware still exists in spite of it. It’s unlikely to matter to any malware you would find in the wild today. Secure boot keys get leaked. You can still get malware in your applications. Some malware even brings its own vulnerable drivers to punch into the kernel anyway and laugh in the face of your secure boot mitigation. The only thing secure boot can actually do when it works is ensure that on the disk the boot loader and kernel look legit. I guess it kind of helps in theory.
Very informative, thanks!