Okay, just as a refresher, bootloaders are different from firmware, but they do operate in similar function. Bootloader are like booting sub-partitions of a partition. Firmware are like booting devices, even disk partitions.
This post entails my experiences with the UEFI boot mode. So far, I see that there is a uncontrollable automatic boot sequence problem for this mode. I am not sure if the firmware setup menu interface or UEFI boot mode is at fault for automatic device boot execution. Such scenarios could lead to the abuse of live environments making an attempt on disk partition security. I would go into details, but I already made a quote from a suggestion post in a multi-factor authentication topic. The quote below will address workaround for the automatic boot sequence execution, which is relevant to the booting process.
Ribby quoted from PureOS how-to: System U2F Authentication - #14 by Ribby
…
A bit off-topic. A encrypted disk is still at risk from UEFI’s automated external device boot execution acting as OS installers or live OS environments/operations. With live OS environments/operations, one can access the encrypted disk after bypassing disk-based security measures. I would rather prevent such devices to interfere with the hardware-based firmware/interface in the first place. I recommend to apply at least a firmware-based administration passphrase prompt along with setting the UEFI boot sequence to Legacy boot option with all external device check flags unchecked, leaving the internal disk drive check flag checked. If you only have Legacy boot sequence, just uncheck all device check flags. The next computer boot with set the automatic boot sequence to an invalid legacy device error message. The situation would now require manual boot sequence with the unchecked devices, initiating the firmware-based administration passphrase prompt. Until then, we be waiting for the study/possibility of multi-factor authentication for hardware-based firmware/interface, disk encryption, and disk-based GNU Grub bootloader level.
I hope I don’t overwhelm readers with such overflow. Keeping on track is key to security’s progress.
Here is the reference material for UEFI-induced vulnerability.
…
Workarounds may not be enough or are too tedious for streamlined secure booting of the computer. As mentioned from the last post, there are GNU firmware in the works. Some of the names go by libreboot, coreboot, and dasharo. While the download and installation/compilation instructions are more tricky due to its firmware nature, there is the hardware requirement compatibility to look out for. Even with such obstacles, I have yet to determine if there is a firmware that enforces manual boot sequence control for UEFI boot mode. Of course, if there is a 64-bit Legacy boot mode for any firmware, that would work out for me too.
Oh, another reason why I opt for the GNU Grub bootloader is because of username and password prompts and GRUB_INIT_TUNE features. Pretty good features if you ask me. Even though this bootloader can’t address the firmware or UEFI boot mode problem, it excels in the partition boot department.