New comment by congdanhqx on void-packages repository https://github.com/void-linux/void-packages/issues/12495#issuecomment-504295085 Comment: On June 20, 2019 10:38:25 PM UTC, andkem wrote: >they don't, as you point out, sign the initrd or provide tools for The sbsigntools couldn't sign the initrd itself, it can sign the efi executable (EFIStub enabled kerbel, refind, grub) only. If I understand other comments correctly, grub signs kernel and initrd with gpg. >actually generating keys. The efi signing-key generation is done by openssl and efitools, IIRC, I didn't put the key generator script into the installation because I weren't sure what should be done with the manufacture's key that's existed in EFI firmware? Should we concatenate that key with our newly generated key or we should simply throw it away or we should give users a choice? I don't know about the key generation for GRUB, is it a gpg key? What is our expectation for this? Or we should skip signing if there're no gpg key? >There were some block of the hook that had a >comment stating it was untested, iirc. The untested part is about the EFI_SIGN_ENGINE, That option is used for some specific EFI firmwares, I don't have those firmwares, hence, I couldn't test. >for the week-end so I cannot check. > >For a secure boot solution that isn't trivial (well almost) to >circumvent we need both kernel and initrd to be signed. We also need >the root file system to either be signed and read only, ex. using >dm-verity, or encrypted. I'd suggest that telling people to encrypt >should be enough, since a read only root won't really work with Void >the way it is currently structured. > >The main point to make for using Grub instead of a pure EFI boot is >that we could support having the boot partition encrypted. Even with >signed binaries, there are attacks that can be mitigated by having it Agree, different threat models have different mitigations. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.