[CLK] Embed dist-git in source branch by bmastbergen · Pull Request #959 · ctrliq/kernel-src-tree

bmastbergen · 2026-03-11T15:13:16Z

This is a first pass at embedding the CLK dist-git in kernel-src-tree. I've started with the 6.12.74 srpm contents and then tweaked them a bit in the subsequent commits:

Remove kabi generation and checking
Move netfilter modules to modules-core to match Rocky 9
Use configs from ciq/configs instead of copies in SOURCES

And then I added a utility script to generate the source tarball for the srpm.

When we rebase, I have lt_rebase.sh updating the spec to match the kernel we are rebasing onto. See that PR here:
ctrliq/kernel-src-tree-tools#60

And an example of what a rebase on top of this looks like in this branch:
https://github.com/ctrliq/kernel-src-tree/tree/%7Bbmastbergen%7D_ciq-6.12.y-next

Some things I'd like input on:

Should SOURCES and SPECS be in the root directory, or should I move them into the ciq directory?
Should all of these SOURCES and SPECS commits start with [CIQ] ?
I added generate_tarball.sh as a script here so that when we do secure boot builds, those folks can generate the tarball without having to check out any other code. Cool?
The lt_rebase.sh spec update will create a commit every time we rebase. I think thats ok to start, but maybe in the future we'd want to auto squash these or something? We may want to do that with the config commits eventually as well. Not sure.
Deiter had suggested having no SOURCES directory and no tarball at all, since this repo IS the sources. But I couldn't get that to work. My (and Claude's) spec-fu may be too weak for that.
That being said I don't think we need to push a tarball to any kind of lookaside. If a person checks out the 'dist-git' they are getting all of the source. If they want the tarball, they can call generate_tarball.sh.
These PRs do not provide any tooling for the scenario where we want to release additional commits without performing a rebase (ie 6.12.74-2). We will need a workflow and tooling for that, but I wanted to start with the basics here.
I think there is a lot of other stuff we can clean out of the kernel.spec and SOURCES dir. But again, I wanted to start simple, with the least amount of change. These cleanups can be done later.

Once we get this nailed down for 6.12, I'd apply a similar set of commits to ciq-6.18.y as well.

SPECS/kernel.spec

bmastbergen · 2026-03-11T19:44:44Z

I think I'll need to pull in this new kernel-pkg change as well:
https://github.com/ctrliq/kernel-pkg/pull/14/

bmastbergen · 2026-03-12T20:32:04Z

Updated:

Use zstd for source tarball
Picked up @elguero changes for module signing

roxanan1996 · 2026-03-13T15:13:06Z

First glance, it looks ok. There is a small typo in the first commit "Import dist-git from 6.12.64 SRPM" title should use 6.12.74.

Happy to see you asked about the ciq directory. I think they should be in their own directory. and ciq is a good candidate for that.

jdieter · 2026-03-13T15:17:36Z

At an initial glance, this looks fine to me, but I won't be able to fully review it until sometime next week.

This kernel does not guarantee a stable kabi

This aligns module packaging with Rocky 9

The configs are already in ciq/configs, so no need to have another copy in SOURCES

We should be attributing CIQ as the signer of the kernel modules being built and signed during the kernel build and packaging process. This patch adds a 'x509.genkey.rocky' file which will be used when creating the ephemeral cert that is used for signing the kernel modules at build time. Signed-off-by: Michael L. Young <myoung@ciq.com> AUTODEL-1213

bmastbergen · 2026-03-13T15:20:13Z

First glance, it looks ok. There is a small typo in the first commit "Import dist-git from 6.12.64 SRPM" title should use 6.12.74.

Happy to see you asked about the ciq directory. I think they should be in their own directory. and ciq is a good candidate for that.

Thanks. Fixed the commit subject for that initial commit.

ciq feels like a good place for SOURCES and SPECS. I'll wait to pull the trigger on the move until I see if anyone has other thoughts on that.

PlaidCat · 2026-03-13T16:16:00Z

First glance, it looks ok. There is a small typo in the first commit "Import dist-git from 6.12.64 SRPM" title should use 6.12.74.
Happy to see you asked about the ciq directory. I think they should be in their own directory. and ciq is a good candidate for that.

Thanks. Fixed the commit subject for that initial commit.

ciq feels like a good place for SOURCES and SPECS. I'll wait to pull the trigger on the move until I see if anyone has other thoughts on that.

I agree we should keep our dist-git stuff isolated from the original code as much as possible ... one container directory seems ideal at the moment, the configs at this point couple probably just move into SOURCES/ as well

PlaidCat · 2026-03-13T16:30:29Z

SOURCES/generate_all_configs.sh

We don't use this we keep a fully expanded generic build of the CONFIGS (so we can detect when GKH chagnes something)

Correct. It just came with the initial srpm dump. Can remove.

PlaidCat · 2026-03-13T16:31:58Z

SOURCES/kernel.changelog

We probably want to replace this or remove it, starting in RHEL10 they're just keepting a small change log in the SPEC file and yeeting the hug log from FEDORA -> CENTOS -> RHEL in this file.

With our spec changelog plan, I think removing it is probably best.

PlaidCat · 2026-03-13T16:32:42Z

SOURCES/Makefile.rhelver

Do when know where or how this is used?

I believe it is used in the kernel-ark infrastructure somehow. I'm not really sure why it is included in the srpm. We do not need it. Will remove.

Yeah this is a part of the make build which we're not explicitly doing.

bmastbergen · 2026-03-13T16:49:24Z

First glance, it looks ok. There is a small typo in the first commit "Import dist-git from 6.12.64 SRPM" title should use 6.12.74.
Happy to see you asked about the ciq directory. I think they should be in their own directory. and ciq is a good candidate for that.

Thanks. Fixed the commit subject for that initial commit.
ciq feels like a good place for SOURCES and SPECS. I'll wait to pull the trigger on the move until I see if anyone has other thoughts on that.

I agree we should keep our dist-git stuff isolated from the original code as much as possible ... one container directory seems ideal at the moment, the configs at this point couple probably just move into SOURCES/ as well

Ok, thats two votes for moving into ciq, and I think its a good idea. I'll do this in the next push. Thanks!

elguero · 2026-03-13T16:55:06Z

First glance, it looks ok. There is a small typo in the first commit "Import dist-git from 6.12.64 SRPM" title should use 6.12.74.

Happy to see you asked about the ciq directory. I think they should be in their own directory. and ciq is a good candidate for that.

Another thought I had the other day was a directory called dist. Either way, I agree this looks odd to keep on this level.

elguero · 2026-03-13T16:57:40Z

SOURCES/ciq_sbsign.macros

We did make a change on the SB side which removed the need for this file. We should consider removing this file and making any necessary changes to the SPEC file.

Excellent, will do!

PlaidCat · 2026-03-13T17:36:34Z

SOURCES/generate_tarball.sh

+fi
+
+echo "Creating $(basename "$TARBALL")..."
+trap 'rm -vf "$TARBALL"' INT


1. Trap only catches INT (line 72) trap 'rm -vf "$TARBALL"' INT If the pipeline fails (e.g., zstd OOMs, disk full, git archive errors), you get a corrupt/partial tarball left on disk. Should also trap ERR, TERM, and handle the pipeline exit code: trap 'rm -vf "$TARBALL"' INT TERM ERR Or better, use set -e (see below) and trap EXIT with a guard: trap '[ $? -ne 0 ] && rm -vf "$TARBALL"' EXIT

PlaidCat

Everything I think that must be addressed before merging this in is addressed, for those I have tagged I would like to hear from them.

But i'm fine with this moving forward

This got left behind because of .gitignore

PlaidCat

But I'd like the following addressed by the people I've tagged
@jason-rodri & @elguero & @jallisonciq #959 (comment)

@elguero
#959 (comment)
#959 (comment)
#959 (comment)

bmastbergen · 2026-03-20T13:24:01Z

Still looking for approvals here. Really I'm just looking for a quick spot check of the tweaks on top of the 6.12.74 import since that is what we have already used to ship CLK 6.12 kernels. I'm sure there is more stuff for us to tweak and improve going forward, but today I really just want to make sure we can do a secure boot build using this branch and ship the rpms.

jason-rodri · 2026-03-20T14:06:56Z

SPECS/kernel.spec

+%if 0%{?rhel}
+%{log_msg "Adjust FIPS module name for RHEL"}
+for i in *.config; do
+  sed -i 's/CONFIG_CRYPTO_FIPS_NAME=.*/CONFIG_CRYPTO_FIPS_NAME="Red Hat Enterprise Linux %{rhel} - Kernel Cryptographic API"/' $i


This is a debranding exercise, we are not certified for 6.12 so it doesn't really matter. there is no security policy to reference. If you want to update the name you can.

Thank you, Its probably worth setting this to rock or just commenting it out then.

We'll be taking this to 6.18 is expected to have some sort of FIPS certification the mechanism is yet to be locked down yet though.

this is wrapped in an rhel conditional so it will never be true. Also, if/when we ever FIPS certify a CLK kernel we can just set this in the flat configs. We'll never need to patch it in like this.

I'll just remove this. Thanks @jason-rodri

PlaidCat

roxanan1996 · 2026-03-20T15:42:03Z

Noticed a diff in dracut-virt.conf, FIPS is missing.
Silly question, do we need it for clk?

bmastbergen · 2026-03-20T15:57:38Z

Noticed a diff in dracut-virt.conf, FIPS is missing. Silly question, do we need it for clk?

Not a problem now. If/when we FIPS certify a CLK we'll have to add it.

elguero · 2026-03-23T16:11:04Z

ciq/SPECS/kernel.spec

+openssl x509 -inform der -in %{ima_ca_cert} -out imaca.pem
+cat imaca.pem >> ../certs/rhel.pem


When we start working with 10, we will need to handle IMA signing.

elguero · 2026-03-23T17:04:47Z

But I'd like the following addressed by the people I've tagged @jason-rodri & @elguero & @jallisonciq #959 (comment)

@elguero #959 (comment) #959 (comment) #959 (comment)

Hopefully I have addressed all the requested comments.

I looked through the SPEC file and everything looked sane to me.

bmastbergen · 2026-03-23T17:16:00Z

But I'd like the following addressed by the people I've tagged @jason-rodri & @elguero & @jallisonciq #959 (comment)
@elguero #959 (comment) #959 (comment) #959 (comment)

Hopefully I have addressed all the requested comments.

I looked through the SPEC file and everything looked sane to me.

Thanks @elguero

I THINK all of the comments you've made have to do with things to look into for the future and/or minor cleanup things. If thats true, and you think we could build, sign, and ship rpms using what we've got here, then I'll go ahead and merge this.

If I misinterpreted and there is something you think we need to fix before we can build, sign and ship just let me know what that is.

Thanks for looking!

elguero · 2026-03-23T17:40:42Z

But I'd like the following addressed by the people I've tagged @jason-rodri & @elguero & @jallisonciq #959 (comment)
@elguero #959 (comment) #959 (comment) #959 (comment)

Hopefully I have addressed all the requested comments.
I looked through the SPEC file and everything looked sane to me.

Thanks @elguero

I THINK all of the comments you've made have to do with things to look into for the future and/or minor cleanup things. If thats true, and you think we could build, sign, and ship rpms using what we've got here, then I'll go ahead and merge this.

If I misinterpreted and there is something you think we need to fix before we can build, sign and ship just let me know what that is.

Thanks for looking!

Yes, correct. I think we are good. Maybe we could do the uki_addons change to add the two addons. Other than that, I think we are in a good spot for secure boot related items.

bmastbergen · 2026-03-23T17:45:46Z

But I'd like the following addressed by the people I've tagged @jason-rodri & @elguero & @jallisonciq #959 (comment)
@elguero #959 (comment) #959 (comment) #959 (comment)

Hopefully I have addressed all the requested comments.
I looked through the SPEC file and everything looked sane to me.

Thanks @elguero
I THINK all of the comments you've made have to do with things to look into for the future and/or minor cleanup things. If thats true, and you think we could build, sign, and ship rpms using what we've got here, then I'll go ahead and merge this.
If I misinterpreted and there is something you think we need to fix before we can build, sign and ship just let me know what that is.
Thanks for looking!

Yes, correct. I think we are good. Maybe we could do the uki_addons change to add the two addons. Other than that, I think we are in a good spot for secure boot related items.

Great @elguero I've added those lines to uki_addons. If that looks good, give me an approval, and I'll get this merged. Thanks!

PlaidCat

bmastbergen mentioned this pull request Mar 11, 2026

[LTR] Update kernel.spec during rebases ctrliq/kernel-src-tree-tools#60

Merged

bmastbergen requested review from a team, elguero and jdieter March 11, 2026 15:21

jdieter reviewed Mar 11, 2026

View reviewed changes

SPECS/kernel.spec Outdated Show resolved Hide resolved

bmastbergen requested a review from jdieter March 13, 2026 14:05

Import dist-git from 6.12.74 SRPM

39a9627

bmastbergen and others added 6 commits March 13, 2026 11:17

kernel.spec: Remove kabi code

6bc287c

This kernel does not guarantee a stable kabi

kernel.spec: Move netfilter modules to core

683b00d

This aligns module packaging with Rocky 9

kernel.spec: Use configs from ciq/config

4108b87

The configs are already in ciq/configs, so no need to have another copy in SOURCES

Add generate_tarball.sh

16ddf8c

Switch to zstd for source tarball

5fa3033

bmastbergen force-pushed the {bmastbergen}_ciq-6.12.y branch from 8b27245 to 5fa3033 Compare March 13, 2026 15:18

PlaidCat reviewed Mar 13, 2026

View reviewed changes

bmastbergen added 3 commits March 13, 2026 12:58

Remove Makefile.rhelver

a838fec

Remove kernel.changelog

620bcf5

Remove generate_all_configs.sh

0ece9a9

elguero reviewed Mar 13, 2026

View reviewed changes

PlaidCat reviewed Mar 13, 2026

View reviewed changes

bmastbergen requested review from a team, PlaidCat and elguero March 17, 2026 15:40

PlaidCat previously approved these changes Mar 17, 2026

View reviewed changes

Add linux-kernel-test.patch

68ab9b1

This got left behind because of .gitignore

bmastbergen dismissed PlaidCat’s stale review via 68ab9b1 March 17, 2026 18:03

PlaidCat previously approved these changes Mar 18, 2026

View reviewed changes

bmastbergen requested a review from a team March 20, 2026 13:19

jason-rodri reviewed Mar 20, 2026

View reviewed changes

kernel.spec: Remove FIPS config tweak

95ecdf2

bmastbergen dismissed PlaidCat’s stale review via 95ecdf2 March 20, 2026 14:34

bmastbergen requested review from PlaidCat and jason-rodri March 20, 2026 14:35

PlaidCat previously approved these changes Mar 20, 2026

View reviewed changes

roxanan1996 previously approved these changes Mar 23, 2026

View reviewed changes

elguero reviewed Mar 23, 2026

View reviewed changes

uki_addons: Add debug.addon and systemd-volatile-overlay.addon

7c400a5

bmastbergen dismissed stale reviews from roxanan1996 and PlaidCat via 7c400a5 March 23, 2026 17:45

PlaidCat approved these changes Mar 23, 2026

View reviewed changes

elguero approved these changes Mar 23, 2026

View reviewed changes

bmastbergen merged commit 6ca0698 into ciq-6.12.y Mar 23, 2026
6 checks passed

bmastbergen deleted the {bmastbergen}_ciq-6.12.y branch March 23, 2026 18:57

		openssl x509 -inform der -in %{ima_ca_cert} -out imaca.pem
		cat imaca.pem >> ../certs/rhel.pem

Conversation

bmastbergen commented Mar 11, 2026

Uh oh!

Uh oh!

bmastbergen commented Mar 11, 2026

Uh oh!

bmastbergen commented Mar 12, 2026

Uh oh!

roxanan1996 commented Mar 13, 2026

Uh oh!

jdieter commented Mar 13, 2026

Uh oh!

bmastbergen commented Mar 13, 2026

Uh oh!

PlaidCat commented Mar 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bmastbergen commented Mar 13, 2026

Uh oh!

elguero commented Mar 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PlaidCat left a comment

Choose a reason for hiding this comment

Uh oh!

PlaidCat left a comment

Choose a reason for hiding this comment

Uh oh!

bmastbergen commented Mar 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PlaidCat left a comment

Choose a reason for hiding this comment

Uh oh!

roxanan1996 commented Mar 20, 2026

Uh oh!

bmastbergen commented Mar 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elguero commented Mar 23, 2026

Uh oh!

bmastbergen commented Mar 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elguero commented Mar 23, 2026

Uh oh!

bmastbergen commented Mar 23, 2026

Uh oh!

PlaidCat left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Milestone

bmastbergen commented Mar 23, 2026 •

edited

Loading