-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the CIQ Kernel Source Tree repository.
This is a multi branch tree with all of CIQ's kernels we maintain from our Rocky LTS's to CentOS Bridge (7.9) and some additional branches for RESF SIG/CLOUD and FIPS (true source of truth is here: ciq-fips). There may be some more in the future but for now this is our forked maintenance.
We would like to invite anyone who wishes to help out to contribute but there are a couple of asks to start.
- Commit Message Requirements
- Built against Vault/LTS Environment
- kABI Check Passed, where Valid (Pre 9.4 RT does not have kABI stability)
- Boot Test
- Kernel SelfTest results
- Additional Tests as determined relevant
We have a couple of pieces of internal tooling for the moment to make sure we integrate all our changes into a more traditional Dist-git model which is cloned to here: CIQ LTS DIST GIT
We have tooling that uses git cherry-pick -nsx <upstream sha> underneath, which will create the engineer doing the backport the author of the commit. We made this decision so that if someone adds any watcher and e-mailer program from the original authors from getting slammed we're restricting that to the participants in this kernel source tree.
In order to make sure we credit the original author and build tooling for ourselves we include the original author in a commit header.
Most of the fields are pretty optional but we will request changes to this if needed.
<Original Commit Subject>
#Start CIQ HEADER
(optional ticket) jira VULN-####
(optional feature/cve/bugfix/sync/etc) cve CVE-####-###
commit-author [Written Name <email>]
commit <original upstream sha>
(required if modification)upstream-diff`
#End CIQ Header
<original commit message body>
https://github.com/ctrliq/kernel-src-tree/commit/8998df1511050f09e5ee1379e4c099cacdde7434
[kernel-src-tree]$ git log 8998df1511050f09e5ee1379e4c099cacdde7434
commit 8998df1511050f09e5ee1379e4c099cacdde7434
Author: Greg Rose <[email protected]>
Date: Mon Nov 18 11:41:40 2024 -0800
mISDN: fix use-after-free bugs in l1oip timer handlers
jira VULN-168
cve CVE-2022-3565
commit-author Duoming Zhou <[email protected]>
commit 2568a7e0832ee30b0a351016d03062ab4e0e0a3f
The l1oip_cleanup() traverses the l1oip_ilist and calls
release_card() to cleanup module and stack. However,
This is an exmaple of a cherry that went wrong and and explination on why its different than the upstream commit. In the below example Brett used the 5.14 Kernel Long Term kernel as a reference as well.
https://github.com/ctrliq/kernel-src-tree/commit/35efc690ef85be68dd3b1c93e477f555e28a6af1
[kernel-src-tree]$ git log --grep upstream-diff
commit 35efc690ef85be68dd3b1c93e477f555e28a6af1
Author: Brett Mastbergen <[email protected]>
Date: Wed Nov 20 12:46:14 2024 -0500
bpf: Fix crash due to out of bounds access into reg2btf_ids.
jira VULN-136
cve CVE-2022-0500
commit-author Kumar Kartikeya Dwivedi <[email protected]>
commit 45ce4b4f9009102cd9f581196d480a59208690c1
upstream-diff commit 3363bd0cfbb80 ("bpf: Extend kfunc with PTR_TO_CTX, PTR_TO_MEM
argument support") was introduced after 5.15 and contains an out of bound
reg2btf_ids access. Since that commit hasn't been backported, this patch
doesn't include fix to that access. If we backport that commit in future,
we need to fix its faulting access as well
When commit e6ac2450d6de ("bpf: Support bpf program calling kernel function") added
kfunc support, it defined reg2btf_ids as a cheap way to translate the verifier
reg type to the appropriate btf_vmlinux BTF ID, however
commit c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL")
We do not require a specific methodology for development setting up a PC or VM, however internally we do prioritize the cloud-images for ease of "resetting" the VM if something goes wrong during testing. More will be added to this table as they become available.
Warning
If the way the Rocky base images are set up if you do a dnf update you'll upgrade the whole thing to the tip of Rocky X.Y that is the newest version.
| Name (Distro Version) | Kernel Version Forked | Branch | Cloud Image Location | Additional Notes |
|---|---|---|---|---|
| CentOS Bridge (CBR) ie CentOS 7.9 | kernel-3.10.0-1160.119.1.el7 |
ciqcbr7_9 | c7.9 x86_64 qcow2 c7.9 images repo | |
| Rocky LTS 8.6 | kernel-4.18.0-372.32.1.el8_6 |
ciqlts8_6 | r8.6 x86_64 qcow2 r8.6 images repo | |
| Rocky LTS 8.6 - RealTime | kernel-rt-4.18.0-372.32.1.rt7.189.el8_6 |
ciqlts8_6-rt | r8.6 x86_64 qcow2 r8.6 images repo | You'll have to enable RT kernel inside the VM |
| FIPS 8 Legacy Compliant (non-certified) | kernel-4.18.0-425.13.1 |
fips-legacy-8-compliant/4.18.0-425.13.1 | Note its based off 8.6 but uses the 8.7 there are no public repos for this kernel | |
| Rocky LTS 8.8 | kernel-4.18.0-477.27.1.el8_8 |
ciqlts8_8 | r8.8 x86_64 qcow2 r8.8 images repo | You'll have to enable RT kernel inside the VM |
| Rocky LTS 8.8 RealTime | kernel-rt-4.18.0-477.27.1.rt7.290.el8_8 |
ciqlts8_8-rt | r8.8 x86_64 qcow2 r8.8 image repo | You'll have to enable RT kernel inside the VM |
| Rocky LTS 9.2 | kernel-5.14.0-284.30.1.el9_2 |
ciqlts9_2 | r9.2 x86_64 qcow2 r9.2 Images repo | |
| Rocky LTS 9.2 RealTime | kernel-rt-5.14.0-284.30.1.rt14.315.el9_2 | ciqlts9_2-rt | r9.2 x86_64 qcow2 r9.2 Images repo | You'll have to enable RT kernel inside the VM |
| FIPS 9 Compliant | kernel-5.14.0-284.30.1.el9_2 |
fips-9-compliant/5.14.0-284.30.1 | r9.2 x86_64 qcow2 r9.2 Images repo | Note: There are no public repos for this kernel |
To make sure that the VM does accidentally update beyond what is expected for the development of a forked version the developer needs to PIN the repo to a VAULT or LTS. This will ensure that on any accidental dnf update that the developer does not have to rebuild their development / test VM.
This method PINs the repos to the vault of Rocky (RESF) or CentOS depending on the particular release being developed for.
You will want to add this to a cloud-init, anisble, etc setup script that runs BEFORE a dnf update. What this does is for every enabled mirrorlist so [repo] that is not commented out with a baseurl commented on the next line. This will comment out the mirrorlist line and remove comment from the baseurl line that is using the releasever and contentdir dnf variables set earlier to find the correct location.
# echo "<dist X.y version>" > /etc/dnf/vars/releasever
# echo "9.2" > /etc/dnf/vars/releasever
# echo "8.8" > /etc/dnf/vars/releasever
echo "8.6" > /etc/dnf/vars/releasever
echo "vault/rocky" > /etc/dnf/vars/contentdir
pushd /etc/yum.repos.d/
ls *.repo | while read line; do echo $line; awk -i inplace '{ if(/^mirrorlist/){print "#"$0; getline; print substr($0,2,length($0)-1)}else{print$0}}' $line; done
popd
dnf -y update
Snip from coud-init
3 - echo "8.6" > /etc/dnf/vars/releasever
2 - echo "vault/rocky" > /etc/dnf/vars/contentdir
1 - pushd /etc/yum.repos.d/
30 - ls *.repo | while read line; do echo $line; awk -i inplace '{ if(/^mirrorlist/){print "#"$0; getline; print substr($0,2,length($0)-1)}else{print$0}}' $line; done
1 - popd
2 - dnf -y update
Cloud-init console
[ 13.050019] cloud-init[2475]: tzdata noarch 2022f-1.el8 baseos 468 k
[ 13.051098] cloud-init[2475]: vim-minimal x86_64 2:8.0.1763-19.el8_6.4 baseos 574 k
[ 13.052167] cloud-init[2475]: zlib x86_64 1.2.11-19.el8_6 baseos 102 k
[ 13.053202] cloud-init[2475]: Installing dependencies:
[ 13.053684] cloud-init[2475]: grub2-tools-efi x86_64 1:2.02-123.el8_6.8.rocky.0.2 baseos 476 k
[ 13.054744] cloud-init[2475]: kernel-core x86_64 4.18.0-372.32.1.el8_6 baseos 40 M
[ 13.055810] cloud-init[2475]: kernel-modules x86_64 4.18.0-372.32.1.el8_6 baseos 32 M
[ 13.056914] cloud-init[2475]: linux-firmware noarch 20220210-108.git6342082c.el8_6 baseos 196 M
[ 13.058038] cloud-init[2475]: Transaction Summary
[ 13.058525] cloud-init[2475]: =================================================================================================
[ 13.059598] cloud-init[2475]: Install 5 Packages
[ 13.060067] cloud-init[2475]: Upgrade 79 Packages
[ 13.060521] cloud-init[2475]: Total download size: 406 M
[ 13.061006] cloud-init[2475]: Downloading Packages:
This is required for FIPS and have a VM that is as close as possible to the LTS being developed against. If you're apart of a company that has a Rocky LTS subscription please reach out to your leadership to figure out how to get access to the CIQ ROCKY LTS repos.
If you would like to gain your own LTS subscription for you or your organization please reach-out here: https://ciq.com/services/long-term-support/
Only do this if you're going to use the real time kernel (yes you can use it as a build server)
dnf config-manager --set-enabled rt
dnf install -y kernel-rt kernel-rt-devel
TBD, we have this is a bunch of internal cloud-init YMLs but need to validate that all the installs are correct and up to date.
With the kernel-src-tree accessible to your VM and a branch created off its HEAD then you should be ready to build.
In the following sections we're going to assume you have the code set up locally with the following structure
<workdir>/kernel-src-tree
<workdir>/kernel-dist-git
For kernel-dist-git do the following in <workdir>
git clone https://github.com/ciq-rocky-lts/kernel.git kernel-dist-git
From the kernel-src-git directory
BRANCH=$(git branch | grep \* | cut -d ' ' -f2)
make mrproper
ARCH=$(uname -m)
VERSION=$(uname -r | cut -d '-' -f1)
cp -v configs/kernel-${VERSION}-${ARCH}.config .config
sed -i_bak "s/CONFIG_LOCALVERSION=\"\"/CONFIG_LOCALVERSION=\"-${BRANCH}\"/g" .config
grep "CONFIG_LOCALVERSION=" .config
make olddefconfig
make -j$(nproc)
sudo INSTALL_MOD_STRIP=1 make modules_install
From here this is where you'll use the kernel-dist-git. Make sure to checkout the correct el-X.y branch that corresponds to the ciqltsX_y that the work is based.
Note: this step can be skipped for Real Time kernels on 8.6, 8.8, 8.10, 9.2
../kernel-dist-git/SOURCES/check-kabi -k ../kernel-dist-git/SOURCES/Module.kabi_${ARCH} -s Module.symvers
sudo make install
This is can be incredibly frustrating, we won't define the tools used here get to the system to boot a system.
This below is a section of a larger build and reboot script that we have been using internally since we've found normal actions sometimes don't do what we want so we set all the known ways of doing this.
GRUB_INFO=$(sudo grubby --info=ALL | grep -E "^kernel|^index")
AWK_RES=$(awk -F '=' -v INDEX=0 -v KERNEL="" -v FINAL_INDEX=0 -v BRANCH="${BRANCH}" \
'{if ($2 ~/^[0-9]+$/) {INDEX=$2}} {if ($2 ~BRANCH) {KERNEL=$2; FINAL_INDEX=INDEX}} END {print FINAL_INDEX" "KERNEL}' \
<<< "${GRUB_INFO}")
if [ $? -ne 0 ]; then
echo "Error: awk failed"
exit 1
fi
read -r INDEX KERNEL <<< "${AWK_RES}"
KERNEL=$(echo ${KERNEL} | sed 's/\"//g')
echo "Setting Default Kernel to ${KERNEL} and Index to ${INDEX}"
sudo grubby --set-default-index=${INDEX}
if [ $? -ne 0 ]; then
echo "Error: grubby failed"
exit 1
fi
sudo grubby --set-default=${KERNEL}
if [ $? -ne 0 ]; then
echo "Error: grubby failed"
exit 1
fi
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
if [ $? -ne 0 ]; then
echo "Error: grub2-mkconfig failed"
exit 1
fi
Please see this page for the current script, like mentioned previously we will be working to make a kernel-tools repo available to enable more consistency.
https://github.com/ctrliq/kernel-src-tree/wiki/Kernel-Make,-KABI,-Install,-and-Reboot-script
We have been making judicious use of kernel-selftests, however as it stands currently we do not have them integrated into github actions.
We request any Pull request include the evidence of their testing that they've shown due diligence on integration. We may ask for clarifications and additional testing methodology. Which we may ask if the contributor is willing to help integrate their testing into out actions for pull requests.
Example Pull Requests: