talos-2: kernel version bump to 6.6.16

[tlaurion]

This is WiP in goal of not putting Talos-2 unmaintained in tree and blocker for #1796

• Also needs fix for Talos II - GPG prompts wait for input on BMC and timeouts, preventing signing from main console (from actual keyboard and gpg prompt on physical display) #1710 (Works solely when BMC used, otherwise GPG prompt sent to BMC, but never to vga output)

---

Current state of this PR: Builds but sealing/unsealing doesn't work.

@SergiiDmytruk @krystian-hebel : some patches are missing to be feature complete, as discussed at #1802 (comment)

TLDR TODOs, adapt:

• https://github.com/linuxboot/heads/blob/79dc677d35e5f23f6dd787ce33753e3535233558/patches/linux-5.5-openpower/0010-arch-powerpc-Kconfig-enable-inclusion-of-drivers-fir.patch
• https://github.com/linuxboot/heads/blob/79dc677d35e5f23f6dd787ce33753e3535233558/patches/linux-5.5-openpower/0011-drivers-firmware-google-expose-CBMEM-as-sysfs-file.patch

Otherwise, Talos-2 cannot replay measurements from exposed CBMEM as file and sealing/unsealing of secret don't work.

---

OLD:

Fails as can been seen CircleCI https://app.circleci.com/pipelines/github/tlaurion/heads/2864/workflows/a472cced-20d2-4540-892e-e8d562a3e63a/jobs/53747?invite=true#step-102-48894_248

Patches having landed under patches/linux-6.6.16-openpower come from https://gitlab.raptorengineering.com/openpower-firmware/machine-talos-ii/op-build/-/tree/f89ea5cc89392de0d1bd6a554009809b5f68692c/openpower/linux and apply cleanly.

Unfortunately, this fails with trace (docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) tlaurion/heads-dev-env:latest -- make -d BOARD=talos-2 #linux.modify_and_save_oldconfig_in_place)
EDIT:

Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration

Fixed by #1802 (comment)

[SergiiDmytruk]

This looks like more relevant error:

Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration

[tlaurion]

This looks like more relevant error:

Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration
Oct 02 15:31:08 cc1: error: '-m32' not supported in this configuration

Yes sorry @SergiiDmytruk , i didn't get the whole error log, pointed to circleci log after having modified OP

[SergiiDmytruk]

Seems to be caused by CONFIG_VDSO32=y which is the result of CONFIG_COMPAT=y. It's for supporting 32-bit PowerPC binaries in PPC64, which seems unnecessary. Maybe there was no 32-bit VDSO before? If this compatibility is desired, likely need to build cross toolchain differently so that -m32 works.

[tlaurion]

@SergiiDmytruk @krystian-hebel kernel builds with 5261213

But patches still need porting for CBMEM output to file and maybe others (0010+) under https://github.com/linuxboot/heads/tree/79dc677d35e5f23f6dd787ce33753e3535233558/patches/linux-5.5-openpower

Otherwise, no sealing/unsealing works. Pushed commit with kernel CBMEM support activated under facad5d which is needed since Talos II uses TPM event log replay to enforce sealing, and requires workaround for cbmem to be accessible as a file per previous implementation, which is a patch.

[SergiiDmytruk]

You likely want an equivalent of that shebangs patch as well to avoid issues with Nix. Top part of 0010 might be necessary, and was probably done for 0011 to work. 0011 does look missing from upstream, CONFIG_GOOGLE_CBMEM might be something else and expose CBMEM as a set of entries rather than a continuous memory buffer.

[tlaurion]

You likely want an equivalent of that shebangs patch as well to avoid issues with Nix.

Unneeded. Those patches were required prior of Linux kernel being made nix friendly somewhere after 5.15 if I recall well (Heads patches/linux* shows those patches not being required anymore, just as for coreboot newer releases that were made nix friendly as well). As can be seen with 5261213 being built by CI successfully.

Top part of 0010 might be necessary, and was probably done for 0011 to work. 0011 does look missing from upstream, CONFIG_GOOGLE_CBMEM might be something else and expose CBMEM as a set of entries rather than a continuous memory buffer.

@SergiiDmytruk facad5d added CONFIG_GOOGLE_CBMEM, while 0010 and 0011 (0010+ as said previously) needs to be reworked for this PR to be merged without regression for #1796 to be fixed and plan for feature freeze for next downstream releases and next qubesos release which might happen between downstream releases. I'm pointing work needing to be done here otherwise Talos-2 will go unmaintained. Unfortunately, I won't have much more time to fix this myself.

[tlaurion]

@SergiiDmytruk modified OP for better task trackablility prior of next release, and assigned to you.

[tlaurion]

@macpijan work spooling needed if #1821 deadline is to be met.

[tlaurion]

Opened Dasharo/dasharo-issues#1133

[SergiiDmytruk]

@tlaurion See Dasharo@c245eec. Didn't test it on hardware, but it builds and probably works because changes are simple additions.

[tlaurion]

@SergiiDmytruk cherry-picked your patch, merged master into this branch, putting ready to review

[SergiiDmytruk]

@tlaurion, I forgot to update that there is a follow-up on the same branch: be99f08. It enables CONFIG_GOOGLE_COREBOOT_CBMEM and disables CONFIG_GOOGLE_CBMEM because I don't think it's used (it exports CBMEM as a file per entry instead of as a single blob).

[tlaurion]

@tlaurion, I forgot to update that there is a follow-up on the same branch: be99f08. It enables CONFIG_GOOGLE_COREBOOT_CBMEM and disables CONFIG_GOOGLE_CBMEM because I don't think it's used (it exports CBMEM as a file per entry instead of as a single blob).

Test of next commit will wait, window for that just passed and talos_2 fails to build per your prior commit pointed as can be seen at https://circleci.com/gh/tlaurion/heads/58361

Will come back to this later, showing how we can loose tie when pointed commits are not right for both or teams, not just for Dasharo :) (poking slightly here).

@SergiiDmytruk You can always test by yourself with same CI by pushing changes yourself: which is why CI are there so we stop wasting our precious times with ping pong game and providing each other things that builds.

[SergiiDmytruk]

@SergiiDmytruk You can always test by yourself with same CI by pushing changes yourself: which is why CI are there so we stop wasting our precious times with ping pong game and providing each other things that builds.

Look at my branch (https://github.com/Dasharo/heads/commits/talos_2-kernel_version_bump_to_6.6.16/), both commits have passed CI yesterday and I even linked passing CI in my previous comment.

[tlaurion]

@SergiiDmytruk You can always test by yourself with same CI by pushing changes yourself: which is why CI are there so we stop wasting our precious times with ping pong game and providing each other things that builds.

Look at my branch (https://github.com/Dasharo/heads/commits/talos_2-kernel_version_bump_to_6.6.16/), both commits have passed CI yesterday and I even linked passing CI in my previous comment.

Perfect now we talk. Doing

[tlaurion]

@tlaurion See Dasharo@c245eec. Didn't test it on hardware, but it builds and probably works because changes are simple additions.

Sorry my bad, I didn't check CI build to check which branch was built, where a commit on github is not referring the branch it comes from. So I only cherry-picked the commit referred in your next reply, not both commits that were applied atop of this branch.

Both commit building on top of master under b205aaf now.

@SergiiDmytruk thanks. Won't be able to test either, board marked as untested per this branch anyway.
I have added a bunch of memory sticks on my machine to use it as a bmc started on-demand server, but as we recall, Raptor Systems shipped a machine with a memory connector broken and older cpu model then what people buy from their shop so machine not representing reaility on my side: 3mdeb have the hardware representing what is sold by them, not me. I don't remember which slot was broken. So machine is not booting anymore and maybe once it boots, since the machine was never tested with so much memory attached, I might open other bugs upstream, so this machine will stay tagged as untested for now, until someone claims having tested it, me or someone else (unknown user from Heads or Dasahro/3mdeb testing master for next release).

---

TLDR: if this compiles, will merge. Board marked untested for now. Once someone has time to test and report machine as working, will move machineout of untested tagging and pick up testing from there: (automated testing of feature freeze commit for other known sold machines/known used machines out there more important than this unsold machine). Plate pretty full for now with feature freeze stuff. Thank you for those patches, @SergiiDmytruk , really much appreciated considering Raptor did a version bum and Heads should follow.

• If this builds, merge

[tlaurion]

@SergiiDmytruk will check tomorrow but ci failed still

[tlaurion]

d3ec7d7#diff-be31657d6b55ca111367dff3bbb8185058e1c16ae45d845b984b4b119d1b3120R131 fix was missing, rebasing on master and fixing merge issues

EDIT: https://github.com/linuxboot/heads/compare/b205aaf11a7a7b94b6b33243d3a59aa063b17b59..7ca7488474a28f5b38df64dc3d9d558ef2222cba is clean. Rebuilding.

TODO:

• if this builds, merging untested

[tlaurion]

This is WiP in goal of not putting Talos-2 unmaintained in tree and blocker for #1796

• Also needs fix for Talos II - GPG prompts wait for input on BMC and timeouts, preventing signing from main console (from actual keyboard and gpg prompt on physical display) #1710 (Works solely when BMC used, otherwise GPG prompt sent to BMC, but never to vga output)

This is nothing new, but unfixed in this PR.