[HN Gopher] Geeking Out with UEFI
___________________________________________________________________
Geeking Out with UEFI
Author : todsacerdoti
Score : 98 points
Date : 2020-10-25 15:24 UTC (7 hours ago)
(HTM) web link (oofhours.com)
(TXT) w3m dump (oofhours.com)
| Fwirt wrote:
| Having an EFI shell binary on a USB stick can be incredibly
| useful when you're troubleshooting boot issues. I went down this
| rabbit hole because the Thinkpad X1 Tablet doesn't play nice with
| GRUB when there's no keyboard attached, but if you setup entries
| directly in EFI you can select a boot partition using the
| touchscreen. There used to be precompiled binaries floating
| around in the tianocore Github repo, but it looks like the link
| has gone dead.
|
| See also Pete Batard's excellent project to support all kinds of
| exotic filesystems in EFI. http://efi.akeo.ie/
| the_only_law wrote:
| I was rather disappointed my MB didn't have a UEFI shell when I
| wanted to recover an completely corrupted GRUB config.
| tsjq wrote:
| I remember when UEFI was about to be released, there were a lot
| of concerns about how this will completely block Linux
| installation, dual boot, etc on Windows computers. Did that
| problem happen? How was that solved?
| salawat wrote:
| Technically solved by allowing you to manage your own keys.
|
| Just what any hobbyist wants to do to dual boot though. Sit
| down and read up on cryptographic signature verification!
| That'll make the hobby more approachable.
| freeone3000 wrote:
| DKMS allows for drivers to be installed without breaking the
| kernel signature. And Ubuntu and Red Hat and Fedora are all
| MS-signed (as will anyone else willing to go through the
| process, which is really only feasible for large orgs but is
| mostly just bureaucracy). So most hobbists will never need to
| mess with mokutil.
| pantalaimon wrote:
| > DKMS allows for drivers to be installed without breaking
| the kernel signature.
|
| how is this possible?
| reanimus wrote:
| You register an additional key, generated by you/the
| installer. Ubuntu automates it as part of setup, afaik
| Fedora doesn't but there are instructions for it. Ubuntu
| generates a key during installation, then requests UEFI
| register it as a secure boot signing key. You reboot,
| UEFI will verify in pre-boot that you asked for the key
| to be added (usually, some BIOSes let you disable this
| check). DKMS will use that key to sign the modules. Since
| the kernel gets the UEFI allowed keys from the firmware,
| it will see these signed modules as valid and load them.
| MertsA wrote:
| It's not, if a kernel was built and signed that allowed
| unsigned modules to be loaded that key should be revoked.
| The way kernel module loading works with secure boot is
| that modules are signed via kmodsign.
|
| https://ubuntu.com/blog/how-to-sign-things-for-secure-
| boot
| reanimus wrote:
| I actually really enjoyed learning about secure boot keys and
| TPMs and all when I was setting it up on my machine. Support
| for managing keys varies by board; some, especially older
| ones, don't let you do much, if at all, especially from
| within Linux.
|
| With modern firmware, you can add a self-generated key pretty
| easily, and it's not hard to do secure boot dual boot with
| Linux (or even macOS if you're using OpenCore, I think!). It
| does require a bit of reading up though. :)
| noja wrote:
| Shims.
|
| MS signed some at the start, see
| https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Sec...
| or https://wiki.debian.org/SecureBoot#Shim
| navaati wrote:
| What I don't understand is, how did that not completely
| nullify the security promises of SecureBoot, rendering the
| whole exercise pointless in the end ?
| voxic11 wrote:
| Because the shim is still secure.
|
| > Shim then becomes the root of trust for all the other
| distro-provided UEFI programs. It embeds a further distro-
| specific CA key that is itself used for signing further
| programs (e.g. Linux, GRUB, fwupdate). This allows for a
| clean delegation of trust - the distros are then
| responsible for signing the rest of their packages. Shim
| itself should ideally not need to be updated very often,
| reducing the workload on the central auditing and CA teams.
| wmf wrote:
| Insecure shims can be revoked.
| https://blogs.gnome.org/hughsie/2020/08/17/updating-
| secure-b...
| [deleted]
| rmrfstar wrote:
| You can manage your own secure boot keys [1].
|
| [1] https://www.linuxjournal.com/content/take-control-your-pc-
| ue...
| MayeulC wrote:
| I think fear of an antitrust lawsuit is what kept Microsoft
| from locking it down completely (IIRC they did it on their RT
| line for a while, though).
| Sunspark wrote:
| The bios in my computer has a toggle for secure boot to be on
| or off. I've had it off the whole time and there was no effect
| on any OS as a result. The issue was limited to bios setups
| that didn't allow this to be toggled, and for those, as pointed
| out by another, signed shims resolved that issue.
| MertsA wrote:
| Even without the shims, right from the start Microsoft was
| requiring that OEMs allow secure boot to be disabled in
| settings if they wanted to pass Microsoft's "Windows
| Certification" requirement.
| rbecker wrote:
| A requirement they later dropped:
| https://tech.slashdot.org/story/15/03/20/2039251/oems-
| allowe...
|
| First they require a lock, but also that the user gets the
| key. Next they require a lock, but the key may be withheld
| from the user. I wonder what they will require next. Their
| Surface RT line of laptops came without unlockable secure
| boot, so no alternative OS could be installed.
| pmoriarty wrote:
| Now if only someone could write a Forth that boostraps a Lisp,
| which gets Emacs running on UEFI
| openfuture wrote:
| Disclaimer: I didn't fully read the article yet.
|
| I wanted to mention the excellent HEADS project (as in the other
| side of TAILS): https://github.com/osresearch/heads
|
| This talk is great: https://trmm.net/Heads_33c3
|
| I remember when UEFI became a thing and people were complaining
| in linux forums that the keys are controlled by the manufacturers
| and 'the whole thing is a ploy by microsoft to kill linux' (UEFI
| is just a convoluted standard way to write BIOS in a certain
| way).
|
| Now we can control the keys, all we need to do is kick UEFI to
| the curb and use linux from BIOS all the way to the DE/WM
| (coreboot..).
|
| Turns out we can turn the boot process into a chain of kexec's
| and simplify everything greatly.
| will_pseudonym wrote:
| I couldn't remember what "DE/WM" meant. If anyone else is in a
| similar situation, they stand for "desktop environment" [0] and
| "window manager" [1]
|
| [0] https://en.wikipedia.org/wiki/Desktop_environment
|
| [1] https://en.wikipedia.org/wiki/Window_manager
| thudson wrote:
| If you want to more easily configure UEFI Secure Boot on your
| Linux system, while also registering your own signing keys to
| eliminate the Microsoft and OEM ones: https://safeboot.dev/
___________________________________________________________________
(page generated 2020-10-25 23:00 UTC)