So basically, my setup has everything encrypted except /boot/efi. This means that /boot/grub is encrypted, along with my kernels.

I am now attempting to get secure boot setup, to lock some stuff, down, but I encountered this issue: https://bbs.archlinux.org/viewtopic.php?id=282076

Now I could sign the font files… but I don’t want to. Font files and grub config are located under /boot/grub, and therefore encrypted. An attacker doing something like removing my hard drive would not be able to modify them.

I don’t want to go through the effort of encrypting font files, does anyone know if there is a version of grub that doesn’t do this?

Actually, preferably, I would like a version of grub that doesn’t verify ANYTHING. Since everything but grub’s efi file is encrypted, it would be so much simpler to only do secure boot for that.

And yes, I do understand there are security benefits to being able to prevent an attacker that has gained some level of running access to do something like replacing your kernel. But I’m less concerned about that vector of attack, I would simply like to make it so that my laptops aren’t affected by evil maid attacks, without losing benefits from timeshift or whatnot.

I found the specific commit where grub enforces verification of font files: https://github.com/rhboot/grub2/commit/539662956ad787fffa662720a67c98c217d78128

But I don’t really feel interested in creating and maintaining my own fork of grub, and I am wondering if someone has already done that.

    • moonpiedumplings@programming.devOP
      0·
      1 year ago

      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. ;(

        • moonpiedumplings@programming.devOP
          0·
          1 year ago

          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.