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.

…#375)

Part of the Heads workflow involves handling legitimate changes to /boot
as part of the package manager. This is a challenging workflow to handle
as package managers on many systems work in a completely unattended way
(and some even reboot first, apply updates, and then reboot again).

We need to be able to detect changes that are potentially caused by a
package manager so to do that I've set up a trigger within the OS
(currently just for Debian) that runs both before and after package
updates. It verifies the signatures in /boot and if they fail before
package updates it creates a log file in
/boot/kexec_package_trigger_pre.txt. If they fail after package updates
run /boot/kexec_package_trigger_post.txt is created. These files contain
the following fields:

CHANGED_FILES: A list of files in /boot that failed the sha256sum check
UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to
trigger initramfs changes

Following those fields is a list of log output from the last package
manager run which contains its own formatted fields (I'm pulling from
/var/lib/dpkg/info).

When a user selects a boot option, gui-init first verifies the
checksums just to catch errors before calling kexec-select-boot. If
there are any errors it looks for these package logs and if they exist,
it displays appropriate warnings. If the files are absent it displays a
more generic warning. The user is also given an opportunity to re-sign
the /boot hashes.

By enabling Pass-through iommu, it fixes the GPU glitching issues
we've had with IOMMU, and it also allows us to boot a target kernel
without having to give it intel_iommu=igfx_off as argument.

Fixes access to the EC through the Index I/O interface
Fixes AC and DC LoadLine values to avoid overheating problems
Fix Turbo mode value from EC
Change version name to have '-heads' suffix

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.

…n/heads

…erankin/heads

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.

…nfig (issue linuxboot#375)

…boot#375)

…nment

…ot#385)

also fix verbiage in comments

Also added convenience call to import keys and removed credentials

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

Needed to identify which files should be preserved between upgrades
such as "heads/initrd/*" or "heads/counter"

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.

…t. Still flickering when Xen owns FB.

…kylerankin/heads

…ankin/heads

…in/heads

…lace (pr linuxboot#370)

While the whiptail program wraps text appropriately based on column
size, the fbwhiptail program doesn't, leading to text that scrolls off
the window where it can no longer be read. This change wraps the longer
text output so it all fits.

Wrapping text to 80 characters works but due to font size and padding
the maximum 80 character lines start to get truncated. Extending the
window to 90 characters will resolve this.

…e remaking (issue linuxboot#394)

…el build (linuxboot#394)

…ilds (linuxboot#394)

…nuxboot#397)

… not spuriously rebuilt (linuxboot#397)

…t#394)

…ack clean/dirty status (linuxboot#398)

…urion/x230-fbwhiptail

Also fix up flashrom-x230.sh command only read bios area

…rion/x230-fbwhiptail

…0-CCACHE-GUI_INIT-LINUX_I915FB-COREBOOT_NO_TEXTBUFFER

…. ash_history content replaced with usefull commands. Everything is there to generate keys from Yubikey/Nitrokey, export armored versions to external media and cbfs them into reproducible rom and flash resulting rom with flashrom-x230.sh.

Currently the TPM counter label is hard-coded. By changing it to a
variable in this function we can reuse all of the TPM counter functions
to create other monotonic counters in the TPM (if the hardware supports
it) with custom labels.

Based on the conversation for PR linuxboot#406, we decided to go with a more
generic script for general-purpose flashing instead of having individual
(and therefore very similar) flash scripts for each board type. This
script currently handles flashrom on Librem and X230 board types and
introduces a new CONFIG_BOARD option that sets specific flashrom
arguments based on the board.

It also adds support to gui-init to call this flash script.

To keep the flash logic simpler the GUI logic has been split into a
flash-gui.sh program so flash.sh behaves closer to the original flashrom
scripts it was based from. I've also removed the previous flashrom
scripts and incorporated their options into flash.sh. Finally I set
CONFIG_BOARD via the Makefile instead of setting a duplicate option in
each board's config.

To be able to boot a disk image, passed to QEMU with `-hda
/path/qemu.img`, the appropriate modules are needed. Strange, `libata`
is not enough, and the drive is only detected, when the module `ahci` is
loaded.

> ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100

Tested with QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7)
with the command below,

    qemu-system-x86_64 -enable-kvm -M q35 -m 1G -bios \
    qemu-coreboot/coreboot.rom -serial stdio -L /dev/shm -hda \
    /dev/shm/qemu-debian.img

where `qemu-debian.img` is created with grml-debootstrap.

    grml-debootstrap --vmfile --vmsize 3G --target \
    /dev/shm/qemu-debian.img -r sid

If we want to modify a running BIOS we will need the ability to pull
down the current BIOS, modify it, and then reflash. This change adds a
read option to flash.sh and pulls down three versions of the BIOS and
only exists successfully if all three match.

In addition to being able to flash a ROM from the GUI, it would also be
useful for a user to be able to add a GPG key to their keyring using the
flashing tool. This change adds the ability for a user to edit both a
ROM located on a USB key and also edit the running BIOS by using
flashrom to make a local copy of the running BIOS, edit it, then reflash
it. This also supports the upcoming delete feature in CBFS for
circumstances where keyring files already exist within CBFS.

QEMU emulated drive is detected as `/dev/sda1`. Set it up as the boot
device.

Use the same value as in for `qemu-linuxboot.config`.

QEMU’s USB device is detected as `/dev/sdb1`.

…b.com/paulmenzel/heads

…n/heads

…m/paulmenzel/heads

Allows Qubes/Ubuntu/Fedora ISO media to be used by default
without a custom kexec_iso_add.txt config

Adding the VBT file makes it available through some ACPI memory area
and apparently the VBT contains the information needed by the i915 driver
in order to figure out how to control the screen's backlight.
Without the VBT, we can't control the screen backlight with Fn-F5/Fn-F6
anymore.