On Tue, Jul 7, 2020 at 6:17 AM Gerd Hoffmann <kraxel(a)redhat.com> 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.