This is wrong and has come up a number of times in the past. See amongst other things this: https://www.linuxquestions.org/quest...7/#post6165346

That's because USB3.x add-in cards come without an option ROM for bootable devices.

Because option ROMs don't work with UEFI, so the USB3 support is added to UEFI instead.

If you have a motherboard that has USB3.x ports, where you can indeed boot from a USB3.x device via BIOS. In many cases you can even boot from an add-in USB controller card if it happens to use the same chipset as the onboard ports.

Please read that post carefully.

The procedure relies entirely on the user being able to add his/her own encryption keys to UEFI. If you can't do that, you can't boot.

I'm saying we shouldn't count on that functionality continuing to exist, because as long as the user can add encryption keys, the chain of trust is obviously broken.

That is still factually incorrect.

First, using the Linux Foundation's PreLoader or Fedora's shim does not add encryption keys to the computer's UEFI key database. Instead, PreLoader and shim have been signed by Microsoft with Microsoft's key for third-party applications, which to the best of my knowledge is installed on every consumer computer's DB database, and MOK is implemented as a second-stage authentication via the MokList/MokListRT UEFI variable containing the enrolled MOK keys. So were there to be a proposal to prevent physically present users installing their own keys in a computer's PK and KEK databases, this would not affect PreLoader or shim, which don't operate at that level.

Secondly, to the best of my knowledge there is no proposal to prevent physically present users from setting up their own key databases. In fact, it is a UEFI requirement at present that they should be able to do so in order to prevent vendor lock-in: owners of computers with UEFI boot firmware are expected to guard their own on-site physical security and UEFI secure boot is explicitly not intended to cover that risk. If you have access to the On/Off button of a computer complying with the UEFI specification, you should be able to install your own keys rather than having to rely on Microsoft's keys. If you think that is wrong, show me the document which changes the UEFI rules on this. Note that when I refer to installing your own keys, I am not talking about turning secure boot off. I am talking about installing your own keys for the purpose of operating secure boot. Were you to install your own keys then you would no longer be able to boot up Windows under secure boot, but you could boot up your own kernels which you have signed with the key you have installed.

Edit On looking at it again the UEFI standard certainly permits a Custom Mode at boot-up allowing access to the PK and other keys by a physically present person, and this is ubiquitous, but I am not now certain it is mandatory. In any event as mentioned PreLoader and shim do not depend on this as they have already been signed by Microsoft.

2 members found this post helpful.

Hi,



I can't see a way that Slackware x86 32 bit can be installed on future hardware since it does not support UEFI though Slackware 64bit ships with elilo 32 bit but I have not been able to use it. ( I mean boot Slackware x86_64 on 32bit UEFI. )