Since a USB boot target can't be the default (at least currently,
/boot must be on internal media), skip the extraneous prompt to
set it as such when booting from USB.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Using sort on USB boot options produces a reverse-ordered list,
leading users to often select the wrong option. Add the -r
parameter to sort to correct the list order and make the default
option the first in the list.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
As part of the config gui we want to be able to have the system define
new config options without them being lost if the user makes their own
changes in CBFS. To allow that this change creates a function initiated
in init that combines all /etc/config* files into /tmp/config. All
existing scripts have been changed to source /tmp/config instead of
/etc/config. The config-gui.sh script now uses /etc/config.user to hold
user configuration options but the combine_configs function will allow
that to expand as others want to split configuration out further.
As it stands here are the current config files:
/etc/config -- Compiled-in configuration options
/etc/config.user -- User preferences that override /etc/config
/tmp/config -- Running config referenced by the BIOS, combination
of existing configs
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/.
