The latest kernels seem to have a work-around the the TPM issue that was causing stuttering on AMD systems. So, I re-enabled TPM on my (MSI) motherboard. Along the way, I learned of the Secure Boot option. Found the appropriate settings going over my MoBo documentation and researching what I may need to know for Arch/EOS installs using systemd-boot. Looks like it may be a bit involved…also kinda looks like it’s maybe not really worth the effort? Maybe just sort of a Microsoft thing? This machine only runs EOS (no Windows).
.
…so, do I actually need it?
If it turns out that it really is worth setting up, is there any EndeavourOS specific and/or systemd-boot specific documentation I should be aware of (in addition to ArchWiki of course)?
Nobody can answer this but you. Be very wary of secure boot information on Linux forums. Much of it is from people who don’t actually understand the technology or what it protects and believe it is bad because it comes from Microsoft.
The reality is that it can add security. However, if that security is valuable to you or protects your specific use case is a different question.
Ok then, I need to better understand what it does then. It appears that, if I don’t set up an appropriate hook, my system may fail to boot on the next kernel update because the new kernel will be “unsigned”.
Yes, switching over to boot using secureboot will likely require several changes. I don’t think it will work on EOS without changing some of the automation around kernel-install.
I certainly don’t need it (or want it), and probably you don’t need it either, but it’s your system, you are the only one who knows what you need.
As far as I’m concerned, Secure BootM$ is just a conspiracy between Microsoft and hardware manufacturers to screw over Linux and BSD users. And before you call me paranoid, keep in mind that I very well might be, but that does not necessarily make me wrong.
From what I’m coming to understand, it’s like a “tamper evident seal” on the kernel. At this point, I think I have a general idea of what I need to do to implement it. However, it also appears that just keeping the kernel up to date is a decent protection as well. It appears the more common Linux based rootkits are targeting older kernels likely to be found on corporate systems. Research is on-going though. For now, secure boot is disabled.
I don’t use it… SEDutil is not compatible with it, I prefer to use my chosen type of drive encryption than having this “feature”.
It is possible to use with EnOS if you want, there is a very good tutorial in Arch’s wiki…
Based on what I have been reading, it seems that grub/shim would be the easier approach to get it running.
IMO if you are asking this question then you don’t need it. Secure boot is for (afaik) scenarios in which your PC is stolen unless you also verify your entire OS on every boot. A good implementation, including UEFI password, verified initramfs and possibly FDE will take your time to setup and a bad one will be easy to bypass.
I don’t use secure boot because I don’t see any benefit.
Nah, it’s exactly what @Kresimir said + another proprietary black box layer to f**k with you and huge vulnerability point…kinda like that Intel boot guard crap. Very secure…
Maybe, on the other hand, I’m old enough to recall the kerfuffle on Slashdot when UEFI was coming out. A lot of people were pretty convinced it was just Microsoft trying to lock down motherboards with proprietary boot code. Didn’t actually work out that way in the end.
That being said, I generally don’t like to use the PC I depend on as a “test box”. That’s why I keep an old PC around. Unfortunately, my available old PC doesn’t have this technology (and I very nearly recycled it anyway). I won’t make any changes until I know exactly what Secure Boot does, why (and if) I need it, and how I would implement it.
I tell you what it does, sometimes something happens to it and you can’t boot up your linux system without a few hours of troubleshooting. Had this happen once on EOS, couple times with ubuntu. On different machines too.
there’s a link in the thread about secure boot not being secure at all. If you search this forum, there are a lot of threads about secure boot… nothing positive.
Secure boot can be combined with disk encryption for reasonably good security, relying only on secure boot is a bad idea imo because someone can just boot to UEFI and toggle secure boot off.
Sure, but i’m saying that having UEFI and Secure boot is a very bad idea regardless and can not be considered secure in any way, it introduces more vulnerabilities and reduces everyone’s freedom. It’s absolute garbage that you can’t really get rid off.
If we could use only disk encryption and not using any proprietary firmware + TPM at all, or use completely free and open source software in our systems - it would be much better.
My point is that you can stack secure boot and FDE as seperate layera, even if secure boot is vulnerable your data is still safe. (unless there is a stupid implementation like enrolling disk unlock key to TPM)
Well, i can be super autistic and come up with many ways that it wouldn’t be the case and your encryption keys can be snooped if you (reasonably) assume backdoors through UEFI / Intel ME / AMD PSP / Pluton CPUs…Most people would say it’s applicable only if alphabet agencies are actively onto you, personally i’m not super sure about it…
I think you mean TPM, I had to disable amd fTPM recently because it made my system stutter. Disk encryption not gonna make your turned on system safer. Also I’m not sure that you can recover your system if that TPM thingy fails.
There was a recent windows exploit where they managed to bypass secure boot… Same thing can happen with Linux.
