Announcement

Collapse
No announcement yet.

GRUB2 EFI Support In Fedora 31 Likely To Include New Security Modules

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by sandy8925 View Post
    You're wrong.
    no sir, you are wrong.

    GRUB also auto-detects OS
    No, that's a helper script that runs and rebuilds a STATIC grub configuration.
    "auto-detection" means that it actually does this on its own power, and GRUB does not.

    The issue for multiboot environments is that you have a single distro that will be the "main GRUB distro" as it is the one running this helper script to update the GRUB STATIC configuration, you can't have all distros update a common grub without screwing up stuff.

    rEFInd by default will scan for stuff on boot so you don't need to write any configuration. It does support static config too but it's not required. It's basically fire-and-forget. I never touched my EFI partition in years (while each time you update the kernel the "auto detection" helper script

    You can easily set up the command line parameters for Linux kernels in GRUB, in the config file /etc/default/grub. You can also boot memtest from GRUB - it's not new, that capability has been around for several years.
    And each time you need to run the grub update script, that updates the STATIC grub configuration. And if you have multiple OS then you need to have different commandlines for each in /etc/default/grub.

    rEFInd reads the kernel commandline parameter file in each distro's /boot every boot so you just edit it and it's ready, and you don't need to have a central file for all distros.

    Leave a comment:


  • Kano
    replied
    Maybe you should mention that the GRUB os detection uses os-prober - I patched it several times

    The topic is only about Secure Boot enabled installations where you chainload a signed (by the OS vendor) grub.efi from a signed (usually with MS keys) shim.efi. I would prefer a MS signed systemd-boot/gummiboot binary without any limits however - that would be a much cooler news

    Leave a comment:


  • sandy8925
    replied
    Originally posted by starshipeleven View Post
    Sorry but I have to stop you right there good sir.
    rEFInd is VERY good at dealing with multiboot environments as it scans all kernels/OS/bootloaders on boot so it will autodetect everything without any mainteneance on your side.
    It also allows you to edit the command line parameters (actually allows you to set up multiple sets of them in a config textfile beforehand so you can just choose another profile if you don't want to type).

    It also has menu for EFI tools like memtest and EFI shell (that you need to provide and drop in the appropriate folder), and can reboot to UEFI firmware (as long as the UEFI allows this at all).

    It also detects automatically the secure boot management tool things a distro installs in the EFI partition so you can also invoke them on boot to do key management.

    GRUB can do all this only with extensive configuration that has to be updated manually on any kernel/OS/bootloader change.


    What GRUB can do which rEFInd can't do is actually access LVM or RAID (* with metadata=0.9 it can access it but your array size is now limited to 2TB) or encrypted partitions to boot your kernel.
    You're wrong.

    GRUB also auto-detects OS - in distros like Ubuntu, Fedora etc. it's automatically done as a part of kernel updates. In distros like Arch where you choose the bootloader, it doesn't get run automatically, but we just need to run a simple command "grub-mkconfig -o <grub_cfg_file_path>" and GRUB auto-detects all installed OS and adds entries for them.

    You can easily set up the command line parameters for Linux kernels in GRUB, in the config file /etc/default/grub. You can also boot memtest from GRUB - it's not new, that capability has been around for several years.

    I don't know about Secure Boot support, but I use Arch Linux so I have to set up stuff manually. I know someone who has Ubuntu installed on a computer, with Secure Boot enabled and it uses Grub, and it works fine for them, no manual config required.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Kano View Post
    I don't see a security gain if it is still possible to pass kernel options without a password without encryption. You own the system in seconds this way
    Afaik GRUB can be set to ask for password before editing boot settings

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by Britoid View Post
    The EFI partition is not very big.
    Resize it, or nuke it together with the Windows installation and have the distro create a new, bigger one automatically during installation.

    Yes but said size is by default set by the factory,
    It's a Fat32 partition with "esp/boot" flags on a HDD/SSD man. Are we unable to resize partitions now? How do we install Linux at all I ask.

    and if /efi gets full of EFI binaries there's no way to sanely clean out anything unused automatically.
    Distros using EFI partition instead of /boot will clean up after themselves just as all distros clean up the /boot folder of unused kernels.

    They are basically using the EFI partition as if it was a FAT32 /boot partition. Because that's all it is. A Fat32 partition with some flags set.

    Leave a comment:


  • Britoid
    replied
    Originally posted by Kano View Post
    GRUB does not store the kernel+initrd in the ESD, that means that systemd-boot (old name gummiboot) has a bigger attack vector. /boot does not need to exist if you enter the password twice or store it inside the initrd. If you want to do an evil maid attack with the ESD it is still possible, but harder as the grub.cfg itself is not stored in the ESD. At least it would be different, you would need to enable an EFI keylogger and then chainload to GRUB EFI. The Linux Foundation loader already solved the Secure Boot part in this case. Basically Fedora (and others like Ubuntu/Debian who reused the patches) began to disable lots of GRUB features if they detect Secure Boot, you can not scan for files, use loopback (because the modules are not signed and not inside the GRUB.EFI like the newly added ones), chainload to EFI (the last maybe because of shim). I don't see a security gain if it is still possible to pass kernel options without a password without encryption. You own the system in seconds this way
    GRUB doesn't meld with secure boot, it uses its own stack. The features are disabled because they have been used to work around secure boot.

    Leave a comment:


  • Britoid
    replied
    Originally posted by bachchain View Post

    The EFI partition can be as big as you want it to be.
    Yes but said size is by default set by the factory, and if /efi gets full of EFI binaries there's no way to sanely clean out anything unused automatically.

    Where as /boot you have full control over.

    Leave a comment:


  • Kano
    replied
    GRUB does not store the kernel+initrd in the ESD, that means that systemd-boot (old name gummiboot) has a bigger attack vector. /boot does not need to exist if you enter the password twice or store it inside the initrd. If you want to do an evil maid attack with the ESD it is still possible, but harder as the grub.cfg itself is not stored in the ESD. At least it would be different, you would need to enable an EFI keylogger and then chainload to GRUB EFI. The Linux Foundation loader already solved the Secure Boot part in this case. Basically Fedora (and others like Ubuntu/Debian who reused the patches) began to disable lots of GRUB features if they detect Secure Boot, you can not scan for files, use loopback (because the modules are not signed and not inside the GRUB.EFI like the newly added ones), chainload to EFI (the last maybe because of shim). I don't see a security gain if it is still possible to pass kernel options without a password without encryption. You own the system in seconds this way
    Last edited by Kano; 03-26-2019, 11:51 PM.

    Leave a comment:


  • bachchain
    replied
    Originally posted by Britoid View Post

    The EFI partition is not very big.
    The EFI partition can be as big as you want it to be.

    Leave a comment:


  • Britoid
    replied
    Originally posted by starshipeleven View Post
    I don't see much purpose in a separate /boot when you have the EFI partition.

    It's a design choice afaik. They envisioned using it with kernels in the EFI partition because you must have that anyway, so why not using it.
    The EFI partition is not very big.

    Leave a comment:

Working...
X