You are not logged in.
Strike0 wrote:Yes, afaik. If you need a trusted boot chain, also consider the other options mentioned above, secureboot probably the most widely supported (and fastest to boot).
NTA but I find it ironic that you mention a malware targeting secureboot and recommend me secureboot in the same post.
Yes, albeit it was triggered by the publication. For completeness sake I'd like to add that I considered recommending heads as an alternative to secureboot too. I did not mention it, because while the heads bios boots really fast, its authentication of the kernel takes a similar time to your encrypted boot. You authenticate the kernel using a usb token or HTOP app, the physical handling alone takes a few seconds .. so it's probably not for you. Plus, its support is limited to a few devices (mostly older thinkpad models, afaik). If you do look into such alternatives, you can also check coreboot status for your device.
Offline
NTA but I find it ironic that you mention a malware targeting secureboot and recommend me secureboot in the same post.
To put this into perspective I think it's worth pointing that this malware targets a specific vulnerable Microsoft binary which can be tricked to run arbitrary code and thus bypass any further signature validation. Grub itself had a similar issue two years ago (CVE-2022-14372) which in turn triggered a mass-revocation of old shim binaries.
There's little even a perfectly secure firmware can do about this, if it's asked to trust a certain certificate and a vulnerable binary signed with the certificate wasn't revoked. I don't know if it's possible to boot Windows with custom secure boot keys w/o the Microsoft UEFI key, but depending on the hardware it's perfectly possible to do so under Linux, i.e. use our own keys and remove Microsoft's certificates from the DB, which thwarts these kind of attacks.
As such I don't think this attack exposes a systemic flaw in secure boot. I'd say it's similar in nature to local privilege escalation attacks in the Linux kernel, which Linux has had plenty in its history, yet we wouldn't go so far as to say that Linux is systemically insecure either.
Last edited by 3beb6e7c46a615a (2023-03-04 10:03:38)
Offline
Looks like it was mentioned, but here is the patched GRUB with argon2 in AUR:
https://aur.archlinux.org/packages/grub … -luks2-git
My setup is similar to yours, but I just encrypted the entire btrfs filesystem along with /boot with LUKS1. I have not found another solution to minimizing unlock times other than making a compromise with iteration count. If the above patch gets pushed to the main repos, I'll switch over on my next install.
Last edited by bestfriend (2023-03-04 18:12:01)
Offline
My setup is similar to yours, but I just encrypted the entire btrfs filesystem along with /boot with LUKS1. I have not found another solution to minimizing unlock times other than making a compromise with iteration count. If the above patch gets pushed to the main repos, I'll switch over on my next install.
I used to do this as well. I believe Manjaro sets it up like this if you tick "encrypt" in the setup. I decided that for my main OS, LUKS2 is much better than LUKS1. So if I did it that way, I'd be compromising the encryption of the entire OS, just to get around a technical limitation that only happens at early boot time. So I decided it makes more sense to encrypt only the boot part in crappy LUKS1, and the rest can stay LUKS2. Not burning the blanket to kill one flea type of thing.
The argon2 patch seems like one useful thing to come out of the thread. I might try it one day when I'm really bored. But between it being on AUR, and based on git, I'm kind of suspecting a whole bunch of stuff will probably break when I try it and require some tedious troubleshooting. Seems hardly worth it just to shave off 5 secs of my boot time. I've decided that instead I'll spend the 5 secs meditating on how shoddy the state of encryption is in the present day and sending bad energy to the people responsible for it. Who knows, maybe I'll get lucky and they'll merge it into main Grub sometime before I die of old age...
Offline
Yes, albeit it was triggered by the publication. For completeness sake I'd like to add that I considered recommending heads as an alternative to secureboot too. I did not mention it, because while the heads bios boots really fast, its authentication of the kernel takes a similar time to your encrypted boot. You authenticate the kernel using a usb token or HTOP app, the physical handling alone takes a few seconds .. so it's probably not for you. Plus, its support is limited to a few devices (mostly older thinkpad models, afaik). If you do look into such alternatives, you can also check coreboot status for your device.
Nah man I'm just messing with you. I read the articles I know it's ms crap only. Still though UEFI seems like kind of a clusterfuck, tbh. Lots of features I don't need as an individual consumer, and lots of new things to break or open security holes. No real problem solved. I can see that it's got some very nice stuff for big corporations to screw with the customer or employee, so no wonder they push it. But I'm kind of surprised to see people here on Arch forums just lap it up and seriously recommend secure boot or something (no offense meant). I assume they just pegged me for a noob and decided to troll me with bad advice lol. But then again I guess arch jumped on the systemd bandwagon pretty quick too, so it figures.
Offline
A new bios, UEFI, was needed for a number of technical reasons. Secureboot is only a subset of UEFI. The systemic problem of secureboot is that after 10 years (W8 introduced it in 2012), it is still not possible to ascertain the state you run. You cannot be certain the mainboard you buy in half a year has been patched against said new malware, or the mb you bought a year ago will receive patches. I'd be glad to be factually proven wrong and see major mainboard vendors distribute complete CRL for their UEFI implementations re the new malware cve. As stated above, shim did a mass revocation and you can find CVE patches in Grub's git, and that is the difference to a systemic fail. If you depend on security somewhat, the best you can do probably is to buy W11 hardware next time and never use W on it (as W is a prime target, always). Because W11 sb requirements for vendors got tightened, to get the problems in check (and platform lock-in consumers).
Back to the topic, I agree it's good to wait until the patch for argon2 is in the regular repo grub, unless you want to experiment with it. The author of the aur package explicitly states they had to make changes to apply the patch. YMMV.
Offline
decided that for my main OS, LUKS2 is much better than LUKS1. So if I did it that way, I'd be compromising the encryption of the entire OS,[…]
But you did already. You've put the most privileged executable of your entire system, i.e. the kernel, on the partition with the weakest encryption; a partition which you unlock through entirely untrusted code from a boot sector which is neither encrypted nor authenticated.
There are certainly a lot of valid criticisms wrt secure boot, but I do have a hard time understanding how you can think of a traditional BIOS boot setup as more secure.
Offline