On Sat, 21 Oct 2017 16:54:36 -0400 John Franklin <frank...@tux.org> wrote:
> > On Oct 21, 2017, at 5:51 AM, Didier Kryn <k...@in2p3.fr> wrote: > >> Tobias, until I read your posting a couple of days ago I did not > >> realise that UEFI/Secure Boot can be configured such that ONLY my > >> kernels can be booted, not even fresh install media from the > >> vendor. Thank you very much. > > > > Me neither. Who, in fact? There seems to be a lack of > > information on that matter. Does anybody have some link to point > > us? > > A generic guide to Secureboot and updating Secureboot keys in your > uEFI firmware: > > https://www.rodsbooks.com/efi-bootloaders/secureboot.html > https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html > [snip Ubuntu, redhat and opensuse info because I won't run those for obvious reasons] > And finally, writing your own .efi binary, which requires linking a C > program against a vast tree of dependencies a specific crt0 and > static library: > > https://www.rodsbooks.com/efi-programming/hello.html These links pretty much proves my point: Secure Boot is a disaster for those wanting to choose what software to run. Something that used to take no more than correctly configuring grub now requires execution of the volumes of information in these links, with much of that execution being trial and error because of different UEFI/secureboot implementations. Especially telling are the following experps from the links: =========================================================== "some Secure Boot implementations are very finicky about their signed binaries, and will reject some binaries built with at least some versions of GNU-EFI", =========================================================== =========================================================== "Fortunately, users of popular distributions such as Fedora, Ubuntu, and OpenSUSE need not do this, because these distributions sign their own binaries and provide public keys", =========================================================== =========================================================== "OS installation utilities and system upgrade tools may not run or may replace your working custom-signed boot programs with versions that are signed improperly for your system. You'll have to be alert to such potential problems and keep suitable backups for restoration purposes. Disabling Secure Boot may be necessary to install a new OS", =========================================================== =========================================================== "Some of my Secure Boot computers reject a significant fraction of EFI programs that are signed as described on this page. Other computers accept the same binaries just fine, and they work fine on the affected machines when launched via Shim, so it appears that either some computers' Secure Boot implementations are overly strict or there's a subtle problem in the way the binaries are signed that affects only some Secure Boot implementations. Binaries built with recent versions of GNU-EFI seem to be particularly prone to these problems". =========================================================== Remember the days when you could take any bootloader with any kernel in any distro and pretty much boot it up, perhaps with a few chroot adventures? I won't buy a computer or mobo without knowing whether or not it can disable Secure Boot (this isn't a publicized spec), and perhaps the next several years I'll buy Windows 8 or earlier computers in which ability to turn it off (if it existed at all) was a must. SteveT Steve Litt October 2017 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
