GNU/Linux Bootloaders versus Secure Boot (UEFI) Mode

General Privacy & Security
1

I had gotten articles about how the UEFI bootloader is technically a proprietary software. While the OS may be non-proprietary, the bootloader managing the disks may not be compliant to the freedom software guidelines.

https://www.gnu.org/proprietary/proprietary-insecurity.html#uefi-rootkit

While mainstream news media will access the GNU/Linux bootloader software as some invulnerability, the truth is that it is the secure boot mode, also known as UEFI mode, that is causing vulnerabilities. With such facts, despite lack of details, UEFI bootloaders could be considered as potential bootloader malware. That means with only access (with a infected) UEFI bootloader, attempts to snoop on disk and OS data/activities would be possible.

While PureOS may just need an USB to install itself as freedom OS software, the bootloader in question remains to be truly secured. Given the fact that 64 bit computers are using more of UEFI boot modes, GNU/Linux development will need to address bootloader development. Purism is no exception, particularly on past developments.

These facts are the reasons why I ought to push for a GNU/Linux bootloader installation. The thing is, while I may got GNU Grub working for Guix, I cannot see the same implementation for PureOS.

I have boiled down to two choices.
GNU Grub or Libreboot

Maybe during my Linux exploration days, I may have experimented with both bootloaders. I still don’t know which is actually better. I would go for GNU Grub due to its stability in establishment. I seem to have the plan thought out, but I do not think I have the complete instructions, particulars on a general level. Yes, I do not have a PureBoot bootloader as I do not have the Librem desktop/laptop. Still, I am using PureOS anyways and would like to cover all ground of bootloading process.

I am not sure if PureBoot is a bootloader, but it definitely is not freely available for the open public. Perhaps it is a bootloader. Nevertheless, default bootloaders do not have much focus for GNU/Linux OS development. Therefore, I will research on bootloaders.

2 Likes
2

shuup
shuup680Ă—679 82.6 KB

1 Like
3

I honestly don’t know how to reply to that post.

Anyways, I found out that, but could be mistaken, Linux is technically a secure boot mode of its own accord. I’m not sure how Windows operates its own secure boot mode, but there is a chance of proprietary vendor lock-in.

Libreboot is technically a derive variant of coreboot. How well it stacks up to GNU Grub, I have no idea. Still, if it is a qualified freedom bootloader software, its development should suffice as such. As for PureBoot, I wish I have the luxury to experience interaction with this bootloader. Such choices for the consumer, even though some choices are said to be free of monetary costs.

My main concern is that I have no indication that GNU/Linux OS comes installed with GNU Grub or any appropriate bootloader. I managed to get the configuration going, but I can’t figure out if a bootloader was also installed with the OS. I am pretty sure that it didn’t.

I also read recently that there are firmware, which is like the bootloader except it deals with hardware. As for elaboration, that’s another story for some other time.

4

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

…
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.
https://www.gnu.org/proprietary/proprietary-insecurity.html#uefi-rootkit
…

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.