The error/warning background gradient colors were defined
for the librem 13 boards, but not for the librem 15 ones.
Add the missing exports.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
With addition of IOMMU/RMRR patches, passthru is no longer needed
for proper IOMMU functionality
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
This changes Heads' bootscript for the x230 to gui-init and adds config
options needed for it. The config is very similar to the librem13v2 config.
My comparison of startup-time from a power-button press shows 2.5 seconds
more with these changes applied.
That said, the experience is smooth, the GUI is beautiful and easier to use
than the shell and text menu, especially during setup. That's what we
buy with startup time here.
The Librem Key is a custom device USB-based security token Nitrokey is
producing for Purism and among other things it has custom firmware
created for use with Heads. In particular, when a board is configured
with CONFIG_LIBREMKEY, this custom firmware allows Heads to use the
sealed TOTP secret to also send an HOTP authentication to the Librem
Key. If the HOTP code is successful, the Librem Key will blink a green
LED, if unsuccessful it will blink red, thereby informing the user that
Heads has been tampered with without requiring them to use a phone to
validate the TOTP secret.
Heads will still use and show the TOTP secret, in case the user wants to
validate both codes (in case the Librem Key was lost or is no longer
trusted). It will also show the result of the HOTP verification (but not
the code itself), even though the user should trust only what the Librem
Key displays, so the user can confirm that both the device and Heads are
in sync. If HOTP is enabled, Heads will maintain a new TPM counter
separate from the Heads TPM counter that will increment each time HOTP
codes are checked.
This change also modifies the routines that update TOTP so that if
the Librem Key executables are present it will also update HOTP codes
and synchronize them with a Librem Key.
The bios regions of the 12M coreboot image is 7M: 4M and 3 of the 8M split
image. The rest of the 8M image _generated_ with fake data and not usable
on real systems! It's dangerous to create them and suggest flashing them
externally.
That's exactly why the x230-flash build target is there: To
have a self-contained 4M image and enable easy unlocking of the 8M image
using the _original_ data.
the heads-wiki project is updated accordingly.
Closes#307Closes#302
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
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.
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.
