On Tue, Jul 7, 2020 at 11:17 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote: > > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and > > > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot > > > are not. Which makes sense to me. Why would you encrypt /boot? The > > > files you can find there are public anyway, you can download them from > > > the fedora servers. Encrypting /boot would make the boot process more > > > fragile for no benefit. > > > > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would > > encrypt /boot to ensure that your boot images have not been tampered with, > > Well, if that is your concern the answer is secure boot. That will not > only prevent tampering with /boot files, but also prevent tampering with > the bootloader itself. It's part of the solution, how exactly does secure-boot it deal with the initrd when isn't signed because it's generate on install, or changes to config files such as grub.cfg? It doesn't, you need technologies such as a TPM2 to measure and attest, and things like IMA to enforce policies. > > or config files haven't been read by somebody other than the end > > user. > > Hmm, typically that is pretty standard stuff and very simliar on all > fedora installs. Only the root filesystem uuid differs, and possibly > local tweaks like configuring a serial console. I can't see how reading > that is of much concern. There's lots of cases where that is a concern, if you can't trust one part of your boot chain can you trust any of it? > > > We could that by using vfat for /boot. Or by shipping & using xfs.efi, > > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs > > > filesystems. > > > > Is there a notable benefit to using that over GRUB2, which already has > > support on both UEFI and BIOS? > > Well, for my day-to-day work it doesn't make much of a difference. Both > get the job done. > > I generally dislike the grub2 config file format. I'm not going to > repeat all the arguments here which have been mentioned numerous times > already. With BLS support things became a bit better because for the > most part I can just ignore grub.cfg after install. > > I suspect the grub2 maintainers have a different view on this. They > have to deal with the mess to make sure I don't have to. And on top > of that getting changes merged upstream to grub2 seems to be a PITA, > leading to a huge stack of patches in the fedora grub2 rpm ... Well the whole upstream situation has started improving recently and the number of patches is coming down and being unified. The whole stack of patches was fairly standard across distros. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
