kgpe-d16 linux configs: disable CONFIG_CRYPTO_AES_NI_INTEL (not avail on AMD)
This applied to Q35 qemu board which is AMD, not intel.
generic AES needs to be enabled on non-intel boards, otherwise cryptsetup doesn't know how to deal with xts-plain
Then saved back with linux.save_in_oldconfig_format_in_place
Since legacy boards do not have e1000e as opposed to maximized builds (no network), we also deactivate:
+# CONFIG_INET is not set
+# CONFIG_ETHTOOL_NETLINK is not set
+# CONFIG_NETDEVICES is not set
This makes gpg24 and newer flashrom bump possible
CONFIG_PREEMPT_NONE=y: Remove preemptiveness for servers. Under heads, we are single tasking. No point having this big thing in kernel https://lwn.net/Articles/746780/
IO scheduler: only enable CONFIG_MQ_IOSCHED_DEADLINE=y since we want maximum throughput and do not have concurrent tasks
CONFIG_CPU_ISOLATION=y : Enable CPU Isolation accross all boards: this permits to make sure that the kernel tasks running on a CPU are not distrurbed bu user tasks
CONFIG_MULTIUSER not defined: Removing cluttering since we are single root user under Heads anyway
CONFIG_IO_URING=y : limit number of copy operations between kernel and user space from apps
CONFIG_ZONE_DMA not defined: relevant for older hardware (less then 32bit addressing space)
CONFIG_X86_MPPARSE not defined: relevant for older smp systems
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is enabled and SCHEDUTIL is disabled: we want performance with CPU sched with deadline IO.
CONFIG_PERF_EVENTS_INTEL_UNCORE and CONFIG_PERF_EVENTS_INTEL_CSTATE not defined: we want max perf on Heads
CONFIG_X86_VSYSCALL_EMULATION not defined: no need for syscall emulation under Heads
CONFIG_SECCOMP not defined : usefull if BPF is enabled and used.
CONFIG_ACPI_SPCR_TABLE=y : usefull for serial redirection table and earlycon
CONFIG_PCI_MMCONFIG CONFIG_MMCONF_FAM10H unset but for kgpe-d16 which is either fam10h of fam15h
CONFIG_DM_SNAPSHOT=y CONFIG_DM_THIN_PROVISIONING=y so that recovery shell can provide LVM/DM functionality in later PR.
CONFIG_EXFAT_FS=y so that exfat preformated thumb drives can work out of the box
Adjust CONFIG_HW_RANDOM per platform, removing CONFIG_HW_RANDOM_TIMERIOMEM
Only support processor family needed per board (AMD only AMD, Intel only Intel, removing CONFIG_CPU_SUP_HYGON CONFIG_CPU_SUP_HYGON CONFIG_CPU_SUP_CENTAUR CONFIG_CPU_SUP_ZHAOXIN CONFIG_CPU_SUP_ZHAOXIN everywhere
qemu: support both AMD and INTEL as an exception for the above.
Removed unused compiled modules unpacked under modules.cpio
Removed not needed crypto modules compiled in or as modules, reviewed from https://github.com/osresearch/heads/issues/1396#issuecomment-1538780319 :
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_SKCIPHER=y
CONFIG_CRYPTO_SKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=y
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=y
CONFIG_CRYPTO_SIMD=y
CONFIG_CRYPTO_GLUE_HELPER_X86=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_XTS=y
CONFIG_CRYPTO_ESSIV=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=y
CONFIG_CRYPTO_SHA256_SSSE3=y
CONFIG_CRYPTO_SHA512_SSSE3=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_AES_NI_INTEL=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_USER_API_RNG=y
CONFIG_CRYPTO_USER_API_AEAD=y
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_LIB_AES=y
CONFIG_CRYPTO_LIB_SHA256=y
Remove CONFIG_NO_GFX_INIT from configs having CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE=y
Add CONFIG_BOOTSPLASH_IMAGE from configs having CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE=y
Add CONFIG_LINEAR_FRAMEBUFFER from configs having CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE=y
Set BOOTSPLASH parameters to match bootsplash and jpeg requirements
+CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768
+CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024
+CONFIG_BOOTSPLASH=y
Others paramaters defined per board default setting with coreboot.save_oldconfig_in_place helper
- add additional kernel boot params for i915 where needed:
- adds : drm_kms_helper.drm_leak_fbdev_smem=1 i915.enable_fbc=0 ( to permit kexec into vesa fb of kexec'ed kernel for i915 driven gpus without framebuffer compression, leaking smem fbdev address for kexec to pickup )
advanced qemu-coreboot-*-tpm*-* boards enables virtio qemu/kvm through command line option.
qemu-coreboot-* (whiptail or fbwhiptail) basic boards are using bochs gpu emulation, provided through qemu
linux-qemu.config, if shared as of now, needs to provide both virtio (no need of FB_SIMPLE because DRM) and BOCHS+SIMPLE_FB
It was impossible to use directly 4.14 defconfig and apply it to 5.10.
Saving 4.14 in oldconfig, then editing in 5.10 was necessary.
- E1000E module (as kernel module support...) was lost in conversion and needed to be added back.
Also tuned things up:
- legacy-flash has no RETPOLINE, no security policy at all. Has expected usb controllers modules, exFAT and bare minimal support for flashrom.
- IMPORTANT: CONFIG_X86_IOPL_IOPERM kernel option is required by flashrom
- legacy adds sata, retpoline, additional modules (ethernet), security policy related material on top of legacy-flash config
- maximized adds MMC card support, mousedev+synaptic (to report presence through oem-system-info-xx30), thin provisioning+snapshot support
- tuned with linux.prompt_for_new_config_options_for_kernel_version_bump
Current storage format is oldconfig from now on for proper analysis. If needed, once can save back in defconfig prior of bumping to newer version.
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>
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>
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>
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>
- 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.
gui-init: do not consume two unseal attempt to unseal both totp and hotp + cosmetic changes (slow down TPM DA lockout)
kexec-seal-key: Add DEBUG statement for PCR precalc
seal-totp: add DEBUG statements regarding skipping of PCR5 and PCR6 involvement into TOTP/HOTP sealing ops
seal-hotpkey: Add DEBUG statements related to reuse of TOTP sealed secret
tpmr: add DO_WITH_DEBUG calls to output pcrread and extend calls
tpmr: typo correction stating TRACE calls for tpm2 where it was for tpm1
tpmr: add DO_WITH_DEBUG calls for calcfuturepcr
functions: Cosmetic fix on pause_recovery asking user to press Enter to go to recovery shell on host console when board defines CONFIG_BOOT_RECOVERY_SERIAL
Not so related but part of output review and corrections:
kexec-insert-key: cosmetic changes prepending "+++" to disk related changes
kexec-save-default: cosmetic changes prepending "+++" to disk related changes
config/coreboot-qemu-tpm*.config: add ccache support for faster coreboot rebuild times
Include bash in all builds. Remove CONFIG_BASH.
Remove CONFIG_BASH_IS_ASH from busybox configuration and clean up hacks
in modules/bash.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
-coreboot support of TPM v2.0 (shared config for TPM2 support across all 4 previous variations)
-swtpm set to be launched under TPM v2.0 mode under board config
-Documentation file under each board.md softlinks to qemu-coreboot-fbwhiptail-tpm1.md (which has been generalized)
This is skeleton for TPM v2 integration under Heads
-------------
WiP
TODO:
- libcurl cannot be built as a tpm2-tools dependency as of now not sure why. curl currently needs to be added in board config to be built
- Note: tpm-reset (master and here) needs some review, no handle of no tpm use case. Caller is responsible to not call it otherwise does nothing
- init tries to bind fd and fails currently
- Note: Check if whiptail is different of fbwhiptail in clearing screen. As of now every clear seems to be removed, still whiptail clears previous console output
- When no OS' /boot can be mounted, do not try to TPM reset (will fail)
- seal-hotpkey is not working properly
- setting disk unlock key asks for TPM ownership passphrase (sealing in NV requires ownership, but text is misleading user as if reowning TPM)
- We should cache input, feed tpm behind the scene and wipe passphrase and state clearly that this is TPM disk unlock kye passphrase.
- primary key from TPM2 is invalid most of the time from kexec-select-boot and verifying global hashes but is setuped correctly at disk unlock key setup
- would be nice to take advantage of bash function tracing to understand where we are for debugging purposes, code takes ash in consideration only
- tpmr says it implements nv calls but actually doesn't. Removing those falsely wrapped functions would help.
- Implementing them would be better
- REVIEW TODOS IN CODE
- READD CIRCLECI CONFIG
Current state:
- TPM unseal works without disk unlock key and generates TOTP properly (was missing die condition at unseal to not produce always good TOTP even if invalid)
- TPM disk encryption key fails. Hypothesis is that sealing with USB drivers loaded and measures in inconsistent with sealed with/without.
- TPM disk unsealing happens without USB modules being loaded in non-HOTP setup. This fails.
- Current tests are with fbwhiptail (no clear called so having traces on command line of what happens)
- Testing with HOTP implementation for sealing/unsealing since that forces USB module loads on each boot to remove this from failing possibilities
- update module version, hash
- rename patch
- update config
Busybox 1.33.0 adds base32, which has been disabled in busybox.config
as it conflicts with tpmtotp's base32.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
The calculations outlined at https://github.com/osresearch/heads/pull/1282#discussion_r1072473677
Sums to having 'ifdtool -f layout.txt ifd_shrinked.bin && cat layout.txt'
The example for T440p:
00000000:00000fff fd
00021000:00bfffff bios
00003000:00020fff me
00001000:00002fff gbe
Here: 00bfffff-00021000=BDEFFF
Which is exact result of @rbeslow's calculations.
There is an issue on haswell, maybe because of car, maybe because of non native memory init blob.
But this is not the case for xx20/xx30 boards.
- add x230-maximized-fhd_edp and x230-hotp-maximized-fhd_edp board configs
- add/rework coreboot patch for x230 fhd variant to be applied on top of 4.13
- add coreboot config to point to x230-edp variant, fixing path to vbt file since default path is wrong under. Comment made upstream https://review.coreboot.org/c/coreboot/+/28950/22#message-4904ce82f01ba0505b391e072e4537b6a9f1a229
- remove no gfx init and replace with libgfxinit(defonfig default), set internal display as default
- add x230-hotp-maximized-fhd_edp and x230-maximized-fhd_edp to CircleCI builds
- One single shared coreboot config between boards/x230-hotp-maximized-fhd_edp/x230-hotp-maximized-fhd_edp.config and boards/x230-maximized-fhd_edp/x230-maximized-fhd_edp.config
- Coreboot 4.13 patch from coreboot at patches/coreboot-4.13/0002-x230-fhd-variant.patch
- config/coreboot-x230-maximized-fhd_edp.config points to seperate coreboot config per patch (CONFIG_BOARD_LENOVO_X230_EDP)
I went through all of the different options we copied from the Librem
config. The only thing that stood out as irrelevant was NVMe support.
However, I'm not a Linux kernel expert, and I didn't do a deep dive, so
I'm sure there is still room for improvement.
