If you're going for secure boot, I'd advise against GRUB.
Use an UKI, dm-verity and get one part of your disk encryption key from your TPM 2.0 (choose PCRs carefully). Is that not compatible with timeshift?
Also see safeboot.dev, even if that's just for Ubuntu 20.04.
this post was submitted on 28 Aug 2023
45 points (100.0% liked)
Linux
48180 readers
1049 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Any setup where the kernels aren't stored on the btrfs root does not give bootable timeshift snapshots. This includes UKI.
Timeshift snapper rollbacks are nice but they can only work with grub. And that legacyware keeps finding a new way to shoot itself in the foot.
Make daily automated backups to an external drive and/or cloud. You probably don't need the hassle of relying on both timeshift and grub at the same time to work.
My important data is backed up to several usb drives, and kept in sync between two computers via syncthing. Soon I will back it up to my college's box cloud, using rclone's crypt feature.
But this isn't about data. This is about me being able to tinker without worry, breaking down to even the lowest level of my system. In addition to that, I don't want to have to waste time manually restoring a system snapshot/backup, as I will soon be busy with other things like classes. I want a one step process.
Why not tinker in a VM if that's the case? An even better solution for your need of an easy, just works distro that is impossible to FUBAR would be something like Fedora Silverblue or MicroOS.
I think this post is you learning the hard way, there's no such thing as a one step process in Linux.
Why not tinker in a VM if that’s the case?
Can't test battery life in a VM. Also uses up too much resources.
Fedora Silverblue or MicroOS
It's a bit of a pain to get my favorite optimizatons and customizations like uksmd or zram set up on immutable distros.
I got it working, using this guide: https://wejn.org/2021/09/fixing-grub-verification-requested-nobody-cares/.
Certainly an unorthodox grub hack, but it's replicatable and it works. Maybe in the future systemd boot or the refind will gain the features I want. Until then, only grub offers what I want.
If a grub update ever breaks this, or maybe just to futureproof this, then I'll probably just use Arch's PKGBUILD, makepkg, and patch tools to patch the grub_efi_get_secureboot function of sb.c so that grub always thinks it's not in secure boot. And maybe put that version on the AUR.
I think this post is you learning the hard way, there’s no such thing as a one step process in Linux.
No, this post is me proving everybody who told me to switch away from grub, (despite my insistence that only grub has the features I need) wrong.
Can’t test battery life in a VM. Also uses up too much resources.
KVMs barely use any resources.
It’s a bit of a pain to get my favorite optimizatons and customizations like uksmd or zram set up on immutable distros.
I think Fedora enable zram by default, not so sure about Silverblue.
I got it working ... ... patch the grub_efi_get_secureboot function of sb.c so that grub always thinks it’s not in secure boot.
Sounds like you are intentionally breaking secure boot code in grub. If you can't see why this is a problem, maybe you shouldn't be using secure boot.
this post is me proving everybody who told me to switch away from grub.
Nope. The post is proving how ill-equipped grub is to support modern features such as secure boot. Grub is very much legacyware at this point. New security features are being developed over at systemd land.
Sounds like you are intentionally breaking secure boot code in grub. If you can’t see why this is a problem, maybe you shouldn’t be using secure boot.
I understand why this is a problem, or would be on systems where much of the initial stages of the system are left unencrypted. But because literally everything but grubx64.efi is encrypted, there is no need for them to be verified. Only grub, which asks for my password for the decrypting, needs to be verified. This behavior is intended for systems that require more security, for example, to prevent unauthorized loading of drivers by a malicious attacker. But I don't need or want that.
Nope. The post is proving how ill-equipped grub is to support modern features such as secure boot. Grub is very much legacyware at this point. New security features are being developed over at systemd land.
I have no doubt that system-boot will get the features I want, and that grub will probably never get things like tpm auto unlock. But I don't use software based on what features they will have, I select software based on what features it currently has. And right now, grub has features I need, that systemd-boot doesn't have. That's just the reality of the situation.
edit: went through your profile history and you literally made a post of where my setup would be useful, the one about the amd regressions. Oh no, if only you had a setup where you could instantly reboot into an older kernel, with one click. But you don't, so you just have to take the performance hit, or go through the hassle of restoring an entire backup either from the local disk, or worse, from another machine/disk. ;(
I understand why this is a problem, or would be on systems where much of the initial stages of the system are left unencrypted. But because literally everything but grubx64.efi is encrypted, there is no need for them to be verified. Only grub, which asks for my password for the decrypting, needs to be verified. This behavior is intended for systems that require more security, for example, to prevent unauthorized loading of drivers by a malicious attacker. But I don’t need or want that.
Sounds like cope to me. You don't get to tell an attacker which component they can attack when you have misconfigured your security guards.
Oh no, if only you had a setup where you could instantly reboot into an older kernel, with one click.
I keep the LTS kernel around for that. It's a "one-click solution" for boot problems. And anyway, a simple chroot should allow me to fix any problems.
Don't see what advantage snapper rollbacks have for me when I would need to use it rarely. I don't have a habit of intentionally breaking things. And when things break on me (I use Arch btw), they rarely introduce fatal errors.
Sounds like cope to me. You don't get to tell an attacker which component they can attack when you have misconfigured your security guards.
There is only a single thing on my system unencrypted: the grubx64.efi binary. This binary is verified via secure boot. Unless an attacker can break luks2 encryption, they cannot get to anything else.
I keep the LTS kernel around for that
Did you read your own post? The lts kernel was affected too. That's why I used it as an example.
anyway, a simple chroot should allow me to fix any problems.
You could also just nab the older kernel from the archive or something, if your system still boots. But I don't want to have to do that. I have better things to spend my time on then going through the pain of disabling all my security features so I can chroot into an encrypted system.
There is only a single thing on my system unencrypted: the grubx64.efi binary. This binary is verified via secure boot. Unless an attacker can break luks2 encryption, they cannot get to anything else.
I don't know enough about the subject of a secure grub to tell you how wrong you are.
Did you read your own post? The lts kernel was affected too. That’s why I used it as an example.
Yes I did. It was a terrible example. As all I would need to know was the last working version for TPM. Regression in LTS does not factor in this equation.
And most importantly, it would not stop me from booting.
You could also just nab the older kernel from the archive or something, if your system still boots. But I don’t want to have to do that. I have better things to spend my time on then going through the pain of disabling all my security features so I can chroot into an encrypted system.
You think you are saying something smart here but I assure you, you couldn't be more conceited. You are maintaining a patch of grub for a bug that grub has no idea it exists. And you claim not to have time to fix your installation...
I don’t know enough about the subject of a secure grub to tell you how wrong you are.
If you don't know, then why don't you shut up, yeah? I've spent 3 weeks researching this, even going as far to read the source of grub. Don't just assume you're right without doing any research.
You think you are saying something smart here but I assure you, you couldn’t be more conceited. You are maintaining a patch of grub for a bug that grub has no idea it exists. And you claim not to have time to fix your installation…
I have the time now. Classes are just getting started. But I'll be busier in the future. Due to the way that arch is setup, this is easier than signing everything, plus I get instant restores.
And it's not a bug. It's intended behavior for systems like high value servers where security is valued over all else, to prevent privilege escalation by an attacker exploiting a kernel bug to load more kernel modules or taking advantage of a similar exploit. But for my desktop system, such an attack is not in my threat model.
Asswipe.
Why not write your own bug-free grub then....
If you think reading about secure boot for 3 weeks is enough for you know everything about the subject, I don't know what to tell you.
You were never worth my salt anyways, go back to whatever dungeon you crawled from. You pathetic vermin.
Asswipe
Stooping to insults now, huh?
Why not write your own bug-free grub then....
Unironically good advice. Although I would probably just contribute to systemd-boot or refind so that it gets the features I want rather than forking grub, or writing my own bootloader.
If you think reading about secure boot for 3 weeks is enough for you know everything about the subject, I don't know what to tell you.
You can never know everything. But you can know enough.
Besides, you walked in with no knowledge, simply telling me I was wrong. This isn't an actual rebuttal to the points I have brought up.
You were never worth my salt anyways, go back to whatever dungeon you crawled from. You pathetic vermin.
I was so "not worth your salt" that you made 6 replies to me. Sounds like you're crying some salty tears. Am I worth that salt?
To echo your words from earlier in this thread:
Sounds like cope to me
Just edit the source code and recompile bro /s
Dunno why this is downvoted, this is unironically a last resort of mine. I don't want to maintain a fork of grub but if it comes down to it, I may do something similar to this except the sed trick doesn't seem to work anymore.
EDIT: sed trick does work. I just forgot to install grub with --disable-shim-lock.
Maybe they are downvoting because I used /s? idk lol