Made sure all linux configs are in good oldconfig state by:
docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:v0.2.3
find ./boards/ -type f | awk -F "/" {'print $3'} | sort | uniq | while read board; do make BOARD=$board linux.modify_and_save_oldconfig_in_place; done
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
Cloudfare patches to speed up LUKS encryption were upstreamed into linux kernel and backported to 5.10.9: https://github.com/cloudflare/linux/issues/1#issuecomment-763085915
Therefore, we bump to latest of 5.10.x (bump from 5.10.5 which doesn't contain the fixes)
Trace:
sed -i 's/5.10.5/5.10.214/g' boards/*/*.config
find ./boards/*/*.config | awk -F "/" {'print $3'}| while read board; do echo "make BOARD=$board linux"; make BOARD=$board linux; echo make BOARD=$board linux.save_in_oldconfig_format_in_place || make BOARD=$board linux.modify_and_save_oldconfig_in_place; done
git status | grep modified | awk -F ":" {'print $2'}| xargs git add
git commit --signoff
- Move patches from 5.10.5 -> 5.10.214
- Add linux kernel hash and version under modules/linux
- Change board configs accordingly
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
librems vs mainline have:
- mei module not compiled in
- Streamline modules/linux Makefile helpers so that one asks on console for new Kconfig options to be y/n, another one to do olddefconfig (accept new defaults)
- Exercice proves again that oldconfig exposes new things added into kernel by default as opposed to defconfig format.
- Add TCP Syn cookies to all linux configs (all boards add CDC tethering AFAIK. Add this protection by default)
- Remove unneeded network card drivers from librems common and unify
- Remove unneeded microsoft surface drivers from librems common and unify
- Remove WMI embedded Binary MOF driver CONFIG_WMI_BMOF
- Unify removed Kconfig options from x230 ported to 6.1.8 to librems common
- Verify qemu (AMD) changes working (note, there is clock source watchdog that would need to be investigated seperately for QEMU TCG mode, that is, not KVM)
- Review crypto backend requirements/unify once more
- Removed bunch of unused stuff under QEMU Q35 (AMD)
Q/A:
- CONFIG_RANDSTRUCT_NONE vs CONFIG_RANDSTRUCT_FULL? CONFIG_RANDSTRUCT_NONE now.
- CONFIG_LDISC_AUTOLOAD=y?
- CONFIG_PTP_1588_CLOCK_OPTIONAL=y?
- CONFIG_X86_THERMAL_VECTOR=y?
- ACPI-WMI (Windows Management Instrumentation) mapper device (PNP0C14) enabled by ACPI_VIDEO and depended by DRM drivers.
- ACPI_VIDEO seems needed.
- CONFIG_INPUT_VIVALDIFMAP=y anabled by CONFIG_KEYBOARD_ATKBD (AT/PS2 Keyboard)
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
- Closes https://github.com/linuxboot/heads/pull/1452
- coreboot: Take Talos II 0.7 release coreboot config file that was inside of cbfs and use it as a base upstream.
- linux: Readd sysctl and proc requirements for cbmem to work.
TODO: fix gpg2 module so that the following doesn't happen (a ppc64 thing. Can't figure out why):
```
Adding generated key to current firmware and re-flashing...
Board talos-2 detected, continuing...
37281653053696daf2e40a8efe9451b557d9d6ab586830dc85f814bf2e03a05f /tmp/talos-2.rom
Initializing Flash Programmer
Reading old flash contents. Please wait...
Flashing: [##################################################\] (100%)
Verifying flash contents. Please wait...
The flash contents were verified and the image was flashed correctly.
Signing boot files and generating checksums...
180726119: 000E452213510000005A
gpg: error running '//bin/dirmngr': probably not installed
gpg: failed to start dirmngr '//bin/dirmngr': Configuration error
gpg: can't connect to the dirmngr: Configuration error
gpg: no default secret key: No dirmngr
gpg: signing failed: No dirmngr
```
dirmngr is deactivated per configure statement --disable-dirmngr, and works as expected on x86
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
prepare_thumb_drive: default to creating 10% LUKS container on usb drive, prompts for passphrase is not provided and scan drives if no --device specified
NOTE: qemu usb_thumb drive of 128 mb are not big enough so that 10% of it (12mb) can be used to create thumb drive.
Adds:
- e2fsprogs to support ext4 filesystem creation through mke2fs
- add /etc/mke2fs.conf so that mke2fs knows how to handle ext2/ext3/ext4
- removes mke2fs support from busybox
- bump busybox to latest version which adds cpu accelerated hash functions (not needed per se here)
- Adds exfatprogs to have mkfs.exfat and fsck.exfat
- Adds prepare_thumb_drive /etc/luks-functions to be able to prepare a thumb drive with percentage of drive assigned to LUKS, rest to exfat
- Modify most board configs to test space requirements failing
- Talos2 linux config: add staging Exfat support
- Make e2fsprogs and exfatprogs included by default unless explicitely deactivate in board configs
- Change cryptsetup calls : luksOpen to open and luksClose to close to addresss review
- etc/luks_functions: cleanup
GOAL here is to have secure thumb drive creation which Heads will be able to use to backup/restore/use generated GPG key material in the future (next PR)
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>
- 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.
