On Tue, Jul 7, 2020 at 6:17 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote: > > 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. Do review it. While "Trusted Computing" was blatantly aimed at DRM rather than user security, its use to lock down the boot process and prevent unauthorized bootloader access has been useful for high security devices in poor security physical environments. > > 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. > > > > 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. Splitting of "/boot" is *bad* a long-known problem. It used to be common place, but it makes disk size management that painful step more awkward for resizing sotrage in virtualization or physical environments. > > 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. It has problems, especially the lack of a useful "lint" for verifying new configs before deployment. I still sadly lament the lack of a "run this config as the default one time only, then revert to the other as default" which LILO supported and I used for testing kernels on new hardware. If the OS booted successfully, the init scripts would run a command to set the default to the new kernel, otherwise a failed boot would revert to the new kernel. Saved my company more than 1000 servers when a vendor did an unauthorized and incompatible hardware upgrade for brand new systems, and the production kernel we deployed on them failed to boot. _______________________________________________ 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
