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>
Update kexec to 2.0.26. Add tracing to framebuffer initialization. In
particular, the driver name is traced if not recognized, and messages
about kernel config are shown if the kernel doesn't provide the
framebuffer pointer.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Add CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM and related kernel parameters to
t440p. This board is already on kernel 5.10 and uses i915 graphics.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Allow leaking the DRM framebuffer pointer to userspace, and disable
framebuffer compression, like librem_15v4.
Tested booting memtest86+ and Debian netinstaller on Mini v2.
Do not enable this for L1UM, it uses Aspeed graphics which still don't
work. qemu uses virtio graphics, which also are not working.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Compressed framebuffer requires the driver to track updates to the
framebuffer from the CPU and update the compressed framebuffer. This
doesn't work if we kexec into an OS that will use the linear
framebuffer, so disable it. (The OS kernel can still use compressed
framebuffer if it has i915.)
Linux 5.8 enabled compressed framebuffer on more chipsets using i915,
which is why this stopped working.
memtest86+ and Debian (manually blacklisted i915, comparable to
netinst) now boot correctly on Librem 15v4. This will need to be
enabled for other boards too.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
The i915 driver's ID changed again, now to i915drmfb.
It's unclear why kexec checks this, it seems it could populate the
target kernel's framebuffer info as long as it knows enough about the
host kernel's framebuffer, which it already checks. Maybe we could
improve this, for now just add the new ID again.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
kexec(8) needs to get the framebuffer address in order to set up the
new kernel's boot parameters. This is one of the reasons that using a
>4.20 kernel in Heads prevents framebuffer graphics from working in the
OS kernel.
Linux 4.20 started hiding this address from userspace, because
userspace is not supposed to need physical memory addresses. A
workaround was added to keep leaking the address, apparently for some
proprietary userspace OpenGL drivers. This requires both a Kconfig and
a kernel parameter.
This commit enables the Kconfig on the librem_common config, and the
kernel parameter on the librem_15v4 (where I'm testing this). We will
need to enable it on other >4.20 configs/boards as well.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
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>
By default json-c builds as debug instead of release.
Adding CMAKE_BUILD_TYPE=minsizerel ensures it does not
add debug info and also optimizes for file size.
Signed-off-by: Daniel Pineda <daniel.pineda@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
```
This patch adds ARCH="$(LINUX_ARCH)" to Linux targets working on config
files. Without it, the architecture defaults to that of host, which for
cross-compilation isn't right.
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
- /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
- Based on initial server board
- Uses whiptail as opposed to fbwhiptail (was slow and output fuzzy)
- Simple fix to have dual KVM(BMC) and vga output for consoles
Reasoning for dropping fbwhiptail support is that:
- it is impossible to output framebuffer content through remote BMC console.
- A workstation board config could output to fbwhiptail for VGA and give remote recovery shell access through BMC
- If someone shows interest for that, qemu-coreboot-tpm boards can be used as reference.
- slowness/fuzzyness of fbwhiptail output through AST would still need to be fixed in kernel drivers. Not a priority here.
Limitation:
- Since whiptail is sent to both consoles:
- If one console goes to recovery shell, recovery shell access invalidate TPM PCR4 measurements.
- The other console won't be aware that TPM measurements were invalidated, and will consequently:
- not be able to unseal TOTP if refreshed
- not be able to unseal TPM disk unlock key on default boot
- A reboot will fix this.
