I did some digging @FriarDest, I hope this helps,
-
Secure Boot allows you to whitelist which files are permitted to boot
-
It verifies their signature so they won’t boot if they’ve been tampered with.
-
In order for verification to work, all firmware, bootloader and kernel code (including modules) must be trusted or they can circumvent verification.
-
It requires all BIOS firmware updates be signed by the vendor (unless installing from within the BIOS?).
-
“Secure Boot is not an effective DRM mechanism, because you cannot guaranteed that the firmware is telling you the truth. It’s not TPM based, there’s no hardware protections to insure you’ve booted securely.” - Matthew Garret, 2012
-
Turning Secure Boot on or off does not turn off UEFI
What problem does it solve?
This is what I got from what I watched,
If you’re dual booting Windows or booting other untrusted OSs on the same system any one of them can inject malware into your Linux boot files unless Secure Boot is enabled.
This defeats full disk encryption (FDE) as the boot files can’t be encrypted (else they can’t boot). So the next time you use an infected boot, you’ll unlock FDE, the malware gains unlimited access and now knows your key. It can for example edit the kernel in memory and remain near undetectable while listening to key strokes, infecting files and the like.
Without Secure Boot anything you run or install with root / sudo priveleges will be able to infect your boot files or install firmware on your BIOS which allows malware to survive between hard drive swaps and formats to infect future boot files.
While UEFI is very complicated and bloated which increases attack surface, turning off Secure Boot doesn’t turn off UEFI so given the option it seems like a good idea.
Conclusion
There’s some ambiguity to how well it works as related to things like unsigned configs in initd (see: 2nd link) but it does it’s described job relatively well.
If you only boot one OS on the system and your hardware is physically safe it’s not a huge benefit because infection would require root and if malware gets root you’re pretty screwed already. The exception being BIOS malware though that’s relatively rare.
Best of the videos I watched in order of usefulness:
Matthew Garret, Jan 2012
Red Hat Kernel Dev, specializing in power management and firmware development
https://youtu.be/V2aq5M3Q76U?t=1827
Matthew Garret, Jan 2018
Security Dev at Google, former Red Hat Kernel Dev
https://www.youtube.com/watch?v=ywoMSwvxZo4
Daniel Kiper, May 2018
Oracle Dev, GRUB upstream maintainer
https://www.youtube.com/watch?v=5MtyguMzwpE
UEFI Sponsored Forum, Aug 2018
https://www.youtube.com/watch?v=MgqZkJDx1YI