flash.sh had a special mode to read (like -r) and then sha256sum the
resulting file. This is no different from just a read followed by a
sha256sum, and the only caller also had logic to sha256sum a cached
file anyway.
Just use flash.sh -r and sha256sum the result.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Basic mode allows (but does not require) setting a default boot option.
Don't seal disk unlock keys in Basic mode.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Some prompts were missed when changing to 0 80 the first time around,
and some new ones were added thinking that size was intentional.
Replace '16 60' with '0 80' globally.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Since 'standard boot' was removed, empty "$option" only occurs due to
error now. Die with a specific error.
Now, we only proceed past ISO boot if no ISOs were present, meaning the
disk might be a plain bootable medium. Present a specific error for
restricted boot in that case.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
The whiptail prompt text was copied from the 'read' prompt but did not
actually have the Abort option. Add it.
The "s for standard boot" option was missing from whiptail. For plain
'read' it does not appear to revert to a normal boot, it actually went
on to try plain bootable USB on the same medium. It's not realistic
for a disk to be both directly bootable and contain ISOs, and this
option does not appear to have been missed since it was missing from
the whiptail/fbwhiptail version, which almost all boards use. Remove
it.
Handle canceling fbwhiptail with esc-esc the same as Abort.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
This feature doesn't require a TPM. The configuration GUI appears
either way, but the actual check was silently skipped on TPM-less
devices. Enable it even if there is no TPM.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Allow configuring the root hash feature when the variables are not set
initially. This worked on Librem boards because the boards all have
defaults for these variables, but didn't work when those defaults were
not present.
Fix set_config function to put quotes around an added variable's value.
Change load_config_value function to default to empty, so it can be
used with non-boolean variables. None of the existing callers cared
about the 'n' default (boolean variables should always be tested ="y"
or !="y" anyway).
Use load_config_value in config-gui.sh for boot device and the root
hash parameters, so unset defaults do not cause a failure. Improve the
prompts so the "current value" text only appears if there is a current
value. Use set_config instead of replace_config so the variables will
be added if needed.
Prevent enabling the root hash feature if it hasn't been configured
yet.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Use CONFIG_BRAND_NAME to control the brand name displayed in the UI.
Override by setting BRAND_NAME when building, either in the Makefile or
on the command line.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Remove brand name from this configuration variable. For backward
compatibility, update config.user in init if the branded variable is
present.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Debian 12's initrd by default now consists of an uncompressed cpio
archive containing microcode, followed by a zstd-compressed cpio
archive. inject_firmware.sh only supported gzip-compressed cpio, so it
could not extract /init from this archive.
Add zstd-decompress to decompress zstd streams (uncompressed size is
about 180 KB).
Add unpack_initramfs.sh which is able to decompress uncompressed, gzip,
or zstd archives, with multiple segments, much like the Linux kernel
itself does.
Use unpack_initramfs.sh to extract /init for blob jail.
Don't compress the new archive segment containing firmware and the
updated /init.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
PureBoot doesn't have any other three-valued settings and this doesn't
present very well in the config UI.
Instead make this a two-valued setting; drop the mode that forces the
EC setting to "stay off" at every boot because this is the default.
When disabling automatic power-on, disable the EC BRAM setting too.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Stop manually loading config values, just update config in environment.
Never test values against "n", since many default to empty. Always
test ="y" or !="y", any other value is off.
Add set_user_config() function to set a value in config.user,
combine configs, and update config in environment. Use it in setting
implementations.
Remove toggle_config, it wasn't very useful because the settings still
test y/n in order to show specific confirmation and success messages.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Blob jail provides device firmware blobs to the OS, so the OS does not
have to ship them. The firmware is passed through the initrd to
/run/firmware, so it works with both installed and live OSes, and there
are no race conditions between firmware load and firmware availability.
The injection method in the initrd is specific to the style of init
script used by PureOS, since it must add a copy command to copy the
firmware from the initrd to /run. If the init script is not of this
type, boot proceeds without device firmware.
This feature can be enabled or disabled from the config GUI.
Blob jail is enabled automatically if the Intel AX200 Wi-Fi module is
installed and the feature hasn't been explicitly configured.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Mini v1/v2's EC can automatically power on the system when power is
applied, based on a value in EC BRAM. Add a configuration setting to
optionally set this value.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
USB autoboot automatically boots to a USB flash drive if one is present
during boot. This is intended for headless deployments as a method to
recover the installed operating system from USB without needing to
attach a display and keyboard.
USB autoboot can be controlled in config.user and the config GUI.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Restricted Boot mode only allows booting from signed files, whether that
is signed kernels in /boot or signed ISOs on mounted USB disks. This
disables booting from abitrary USB disks as well as the forced "unsafe"
boot mode. This also disables the recovery console so you can't bypass
this mode simply by running kexec manually.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
PureBoot Basic mode provides the full Linux userspace in firmware from
Heads without requiring verified boot or a Librem Key. Basic and
verified boot can be switched freely without changing firmware, such as
if a Librem Key is lost.
PureBoot Basic can apply firmware updates from a USB flash drive, and
having a complete Linux userspace enables more sophisticated recovery
options.
Basic mode boots to the first boot option by default, setting a default
is not required. This can be configured in the config GUI.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
enable_usb_storage() inserts usb-storage.ko if not already loaded, then
waits for USB storage devices to appear.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
pause_automatic_boot() prompts that an automatic boot is about to occur
and allows the user to interrupt it.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Extract utilities from config-gui.sh for use in additional config
settings. read_rom() reads the current ROM with a message for failure.
replace_rom_file() replaces a CBFS file in a ROM. set_config() sets a
configuration variable in a file.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Currently Heads will check files in /boot for tampering before booting
into a system. It would be nice if you could use the trusted environment
within Heads and extend this to check files in / itself. This new script
adds that functionality, however due to the length of time it takes to
perform these kinds of checks, it doesn't run automatically (yet).
This feature can be configured from the config GUI - the root device/
directories to check can be set, and it can be configured to run during
boot.
To make this a bit easier to use, I added a feature to detect whether
the hash file exists and if not, to display a more limited menu to the
user guiding them to create the initial hash file. Otherwise it will
display the date the file was last modified, which can be useful to
determine how stale it is.
Reduce friction when generating a new TOTP/HOTP secret by eliminating
an unnecessary 'press enter to continue' prompt following QR code
generation, and by attempting to use the default admin PIN set by
the OEM factory reset function. Fall back to prompting the user
if the default PIN fails.
Also, ensure error messages are visible to users before being returned
back to the GUI menu from which they came by wrapping existing calls to die()
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
On machines without a TPM, we'd still like some way for the BIOS to
attest that it has not been modified. With a Librem Key, we can have the
BIOS use its own ROM measurement converted to a SHA256sum and truncated
so it fits within an HOTP secret. Like with a TPM, a malicious BIOS with
access to the correct measurements can send pre-known good measurements
to the Librem Key.
This approach provides one big drawback in that we have to truncate the
SHA256sum to 20 characters so that it fits within the limitations of
HOTP secrets. This means the possibility of collisions is much higher
but again, an attacker could also capture and spoof an existing ROM's
measurements if they have prior access to it, either with this approach
or with a TPM.
Signed-off-by: Kyle Rankin <kyle.rankin@puri.sm>
On some newer platforms of intel (confirmed on nehalem, sandy/ivy
bridge), coreboot after commit [2ac149d294af795710eb4bb20f093e9920604abd](https://review.coreboot.org/cgit/coreboot.git/commit/?id=2ac149d294af795710eb4bb20f093e9920604abd)
registers an SMI to lockdown some registers on the chipset, as well
as access to the SPI flash, optionally. The SMI will always be triggered
by coreboot during S3 resume, but can be triggered by either coreboot
or the payload during normal boot path.
Enabling lockdown access to SPI flash will effectly write-protect it,
but there is no runtime option for coreboot to control it, so letting
coreboot to trigger such SMI will leave the owner of the machine lost
any possibility to program the SPI flash with its own OS, and becomes
a nightmare if the machine is uneasy to disassemble, so a scheme could
be implement, in which the SMI to lockdown chipset and SPI flash is left
for a payload to trigger, and temporarily disabling such triggering in
order to program the SPI flash needs authentication.
I have implemented a passcode-protected runtime-disableable lockdown
with grub, described [here](https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/hardened_boot/grub-for-coreboot.md#update-for-coreboot-after-commit-2ac149d294af795710eb4bb20f093e9920604abd). In order to implement a similar scheme for
Heads, I wrote [io386](https://github.com/hardenedlinux/io386).
With this commit, io386 will be called before entering boot routine
to trigger the SMI to finalize the chipset and write protect the SPI
flash at the same time. Entering recovery shell will leave the flash
writable.
(The authentication routine implemented in previous revisions has been
split as an independent commit.)
Originally proposed under PR#326
This isn't in a loop, continue makes no sense. ash had silently
ignored it. Proceeding to the do_boot below is the correct behavior.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
For partitioned media or when more than one device is present, this
fixes a benign script error that ash had apparently ignored.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
- Trace calls need to happen after sourcing /etc/functions not before
- Move sourcing of external files at beginning of file, remove /etc/functions sourcing duplicate
- gpg error redirection was sent to /dev/null where expected to be added to whiptail in case of error (2>&1 instead and redirection to file)
Problem
When using a custom password for TPM, the OEM re-ownership process is broken
Impact
The OEM re-ownership process breaks for any user setting a custom password and not just using 12345678
First appeared
6923fb5e20
Detail
on line 498, if blank, the TPM custom password is overwritten with TPM_PASS_DEF (eg, when no custom password is set by the user installing)
```
if [ "$TPM_PASS" == "" ]; then TPM_PASS=$TPM_PASS_DEF; fi
```
so far so good. $TPM_PASS should be used for all TPM interaction from this point. $TMP_PASS_DEF is now a disposed of variable.
we see that happens when resetting the TPM on line 712 (generate_checksums) is that $TPM_PASS is used (correctly)
```## reset TPM and set password
if [ "$CONFIG_TPM" = "y" ]; then
echo -e "\nResetting TPM...\n"
tpmr reset "$TPM_PASS" >/dev/null 2>/tmp/error
---SNIP
```
The TPM now has either the custom password of the user, or the default of 12345678 depending on user selection.
On line 712, we duck into the generate_checksums sub, which for some reason reverts to TPM_PASS_DEF
```
# create Heads TPM counter
if [ "$CONFIG_TPM" = "y" ];then
if [ "$CONFIG_IGNORE_ROLLBACK" != "y" ]; then
tpmr counter_create \
-pwdo "$TPM_PASS_DEF" \
--SNIP
```
This then, rightly, fails due to
```
Authentication failed (Incorrect Password) (ox1) from TPM_CreateCounter
```
- /tmp/initrd_extract was attempted to be deleted while under that directory when no crypptab found.
- changing of directory to / is non-conditional prior of deletion: move to cleaning step
- Clarity on message displayed to user when a generic crypttab will be generated in case of no OS override
TPM password must be 1-32 characters. Loop if the password is not
valid or the repeated password doesn't match, so the user can try
again.
Move prompt_new_owner_password to functions and use in both gui-init
and tpm-reset.
Fixes#1336
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
