Since fbwhiptail allows us to customize the background colors, we should
colorize warnings and error messages to provide a user with an
additional subtle cue that there might be a problem. I have added two
additional configuration options:
CONFIG_WARNING_BG_COLOR
CONFIG_ERROR_BG_COLOR
and in the librem13v2.config file you can see an example for how to set
them to be yellow and red gradients, respectively. I've also updated the
main two scripts that use whiptail to include those background colors.
If you decide to use regular whiptail, just don't set these config
options and it should behave as expected.
When a user gets confirmation of their boot menu choice, that's largely
to give them the option of making their boot choice the default. In the
case of "force mode" there's no reason for the user to be presented with
that dialog so this change skips right ahead to the boot once they have
In the event a user does pick the insecure "force" boot option that
bypasses checksum and signing checks in Heads, it would be nice to
provide a clear visual warning during the boot process that they are in
this state. This change will add a kernel argument that changes the boot
console background to be red and removes any boot splash that might
obscure it, in the event the user picks the insecure boot mode.
Since a user should only boot into this mode during emergencies, having
it be apparent that it's an unsafe mode helps ensure the user doesn't
pick this boot option needlessly.
Currently when the boot entries change, kexec-select-boot dies. Given
the normal loop is set up to catch this event and display a regular boot
menu at the next iteration of the loop, instead of dying it would be
better to just warn and then return from that function back into the
main loop. In addition to that I added a GUI menu for the same warning
when in GUI mode.
There was a bug in the "force" boot mode where it would still fail if
signatures didn't match. This was because the check_config function
validates the signatures for kexec files. I've added a few conditionals
here so that in the case of a forced boot mode, we can bypass those
signature checks that would prevent boot and error out to a recovery
console.
The point of this change is to provide a failsafe (failunsafe?) mode for
less technically-savvy users who will ultimately be using Heads by
default on Librem laptops.
There are some scenarios where an end user might forget to update hashes
in /boot after an initrd change or might have some other hash mismatch.
Currently that user would then be stuck in a recovery console in Heads
not knowing what to do within that limited shell environment to fix the
situation.
This change adds a 'force' mode to kexec-select-boot that goes straight
into a boot menu and bypasses the hash checks so the user could more
easily get back into their system to attempt to repair it. It adds
appropriate warnings about why this is a risky option and moves it down
toward the bottom of the menu. The goal would be to just have this be an
emergency option our support could guide a user to if they ended up in
this situation.
When selecting the boot menu option (m) in the gui-init you call out to
kexec-select-boot. To better maintain the graphical menu experience,
I've added a -g option to kexec-select-boot that, when set, will use a
graphical whiptail menu for the most common menu selection modes.
if "CONFIG_TPM=y" is not present in the config file, functionalities
needing TPM could be disabled, while leaving other functionalities intact.
This will make Heads a more general-usage bootloader payload atop coreboot.
Changed the checking of required hashes or required rollback state
to be right before boot, allowing the user to sign/set defaults
in interactive mode.
Also cleaned up usages of recovery and fixed iso parameter
regression.
Similar to qubes-update, it will save then verify the hashes of
the kexec files. Once TOTP is verified, a normal boot will verify
that the file hashes and all the kexec params match and if
successful, boot directly to OS.
Also added a config option to require hash verification for
non-recovery boots, failing to recovery not met.
Refactored boot parsing code and applied that in local-init to
scan /boot for grub options and allow the user to unsafely boot
anything. This goes a long way to addressing #196.
Optionally the user can customize those boot parameters or enforce
arbitrary hashes on the boot device by creating and signing config
files in /boot/ or /media/ or /media/kexec_iso/ISO_FILENAME/.
