Add these two functions for use in config-gui.sh for future toggles.
load_config_value() obtains the value of a config setting, defaulting
to 'n'. get_config_display_action() displays 'Enable' or 'Disable'
depending on the current value.
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
* Properly initialize sensor IDs of 2nd CPU to fix fan control.
* Use 2s delay for I2C communications with TPM in OPAL (configured in
device tree).
* Stop building unused parts of skiboot using host GCC.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
It only extends PCR10 and logs it separately.
Added entries are to compensate disabling IMA which selects those config
options.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Updated to reproducible version of fbwhiptail.
Added flags to remove debug info.
Updated url to current one instead of going through redirect.
Signed-off-by: Daniel Pineda <daniel.pineda@puri.sm>
Bash uses .build to keep count of the build number, which conflicts
with heads build system usage of .build to keep track of built modules.
If .build already exists when bash/configure is run it will increment by 1
the build number. This is configurable on the call to the support script
support/mkversion.sh, which is called from the bash/Makefile.
Patching the Makefile template used during bash configuration allows
disabling the build number increment.
Signed-off-by: Daniel Pineda <daniel.pineda@puri.sm>
We don't need coreboot to initialize graphics on this boards, this
eliminates some unneeded code and the gnat dependency for them.
Coreboot was using libgfxinit, but it was initializing in text mode.
Heads' kernel will then switch to graphics mode, and we hand that
framebuffer from i915 to the target kernel during kexec.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
