[ciq-6.18.y-next] Multiple patches tested (40 commits)#1112
Open
ciq-kernel-automation[bot] wants to merge 40 commits intociq-6.18.y-nextfrom
Open
[ciq-6.18.y-next] Multiple patches tested (40 commits)#1112ciq-kernel-automation[bot] wants to merge 40 commits intociq-6.18.y-nextfrom
ciq-kernel-automation[bot] wants to merge 40 commits intociq-6.18.y-nextfrom
Conversation
Adding configs based of Fedora-ARK default config from 6.18.2.
We are modifying these with the following configs where available CONFIG_MODIFY_LDT_SYSCALL=n CONFIG_LEGACY_VSYSCALL_NONE=n These options are for old software support which adds performance overhead and potential attack surfaces with go against the CIQ LT kernels priority of performance and security. CONFIG_LIVEPATCH=n We do not have Live patching on for any road-map CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y This should be enabled, it often improves performance funnily enough CONFIG_PREEMPT_VOLUNTARY=y CONFIG_HZ=100 These are set to increase throughput CONFIG_PREEMPT_VOLUNTARY=y (default Fedora config) but CONFIG_HZ=100 for higher throughput over the x86_64 default of CONFIG_HZ=1000 which provides lower latency. After modification 'make CROSS_COMPILE=./scripts/dummy-tools/' was run
Setting up the default build configs to ensure everything builds when we update and rebase.
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. Add a kernel configuration option to lock down the kernel, to restrict userspace's ability to modify the running kernel when UEFI Secure Boot is enabled. Based on the x86 patch by Matthew Garrett. Determine the state of Secure Boot in the EFI stub and pass this to the kernel using the FDT. Signed-off-by: Linn Crosetto <linn@hpe.com> [bwh: Forward-ported to 4.10: adjust context] [Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream] [bwh: Forward-ported to 4.15 and lockdown patch set: - Pass result of efi_get_secureboot() in stub through to efi_set_secure_boot() in main kernel - Use lockdown API and naming] [bwh: Forward-ported to 4.19.3: adjust context in update_fdt()] [dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection] [bwh: Drop call to init_lockdown(), as efi_set_secure_boot() now calls this] [bwh: Forward-ported to 5.6: efi_get_secureboot() no longer takes a sys_table parameter] [bwh: Forward-ported to 5.7: EFI initialisation from FDT was rewritten, so: - Add Secure Boot mode to the parameter enumeration in fdtparams.c - Add a parameter to efi_get_fdt_params() to return the Secure Boot mode - Since Xen does not have a property name defined for Secure Boot mode, change efi_get_fdt_prop() to handle a missing property name by clearing the output variable] [Salvatore Bonaccorso: Forward-ported to 5.10: f30f242 ("efi: Rename arm-init to efi-init common for all arch") renamed arm-init.c to efi-init.c] Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. UEFI machines can be booted in Secure Boot mode. Add an EFI_SECURE_BOOT flag that can be passed to efi_enabled() to find out whether secure boot is enabled. Move the switch-statement in x86's setup_arch() that inteprets the secure_boot boot parameter to generic code and set the bit there. Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> cc: linux-efi@vger.kernel.org [rperier: Forward-ported to 5.5: - Use pr_warn() - Adjust context] [bwh: Forward-ported to 5.6: adjust context] [bwh: Forward-ported to 5.7: - Use the next available bit in efi.flags - Adjust context] Signed-off-by: Jonathan Maple <jmaple@ciq.com> Revert "efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode" This reverts commit 4047f887e98539d07d664eaa6699d9c8fb6c0ca4.
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. Based on an earlier patch by David Howells, who wrote the following description: > UEFI Secure Boot provides a mechanism for ensuring that the firmware will > only load signed bootloaders and kernels. Certain use cases may also > require that all kernel modules also be signed. Add a configuration option > that to lock down the kernel - which includes requiring validly signed > modules - if the kernel is secure-booted. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> [Salvatore Bonaccorso: After fixing https://bugs.debian.org/956197 the help text for LOCK_DOWN_IN_EFI_SECURE_BOOT was adjusted to mention that lockdown is triggered in integrity mode (https://bugs.debian.org/1025417)] Signed-off-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2629 feature Additional SecureBoot patches for dynamic lockdown commit b24fbd012b781b752cc51d6ef1fe1c6d5875ae87 commit-source https://salsa.debian.org/kernel-team/linux.git commit-patch-path debian/patches/features/all/lockdown commit-info Checkout the commit sha above and move to the directory listed above to find Debian patches matching this commits summary line. These drivers allow mapping arbitrary memory ranges as MTD devices. This should be disabled to preserve the kernel's integrity when it is locked down. * Add the HWPARAM flag to the module parameters * When slram is built-in, it uses __setup() to read kernel parameters, so add an explicit check security_locked_down() check Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Matthew Garrett <mjg59@google.com> Cc: David Howells <dhowells@redhat.com> Cc: Joern Engel <joern@lazybastard.org> Cc: linux-mtd@lists.infradead.org Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira LE-2629 feature Fedora EFI status status ommit 7a60169d168d6aae70aca10b7b71070666068529 commit-source https://gitlab.com/cki-project/kernel-ark/ This adds efi_status_to_str() for use when printing efi_status_t messages, and reworks efi_status_to_err() so that the two use a common list of errors. Upstream Status: RHEL only Signed-off-by: Peter Jones <pjones@redhat.com> Signed-off-by: Jonathan Maple <jmaple@ciq.com>
CONFIG_SPI_MICROCHIP_CORE is no longer a valid config option in 6.18.3 spi: microchip: rename driver file and internal identifiers Upstream 71c814e
Upstream commit 5ba2f0a (mm: introduce deferred freeing for kernel page tables) was backported which adds new config option ASYNC_KERNEL_PGTABLE_FREE. Then upsteam commit e37d5a2 (iommu/sva: invalidate stale IOTLB entries for kernel address space) was backported which selects it by default for x86 configs that have selected IOMMU_SVA (which our x86_64 configs have) iommu/sva: invalidate stale IOTLB entries for kernel address space Upstream e37d5a2
The config dependency on DEVICE_PRIVATE for DRM_GPUSVM was removed, causing it to be selected by default for configs with DRM_XE (like ours). Because DRM_GPUSVM is now enabled, DRM_XE_USERPTR_INVAL_INJECT is valid, but not selected by default. drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATE Upstrea: bdcdf96 upstream.
ATH9K_AHB now depends on OF to be selected by default. x86_64 configs do not have OF. This is fine since ahb bus is arm only. wifi: ath9k: add OF dependency to AHB upstream: 125e7b3
There are customers that will need this enabled by default
This matches the 6.12 spec
We are defining the product as clk so if we ever need to revoke or deny the cert we can target this specific product
by design, kernel-ark blacklists all modules in modules-extra that have a module alias. Now that qdiscs have their module alias [1], some of them became blacklisted even if we didn't really intend to: move them back to kernel-modules to preserve feature parity with other qdiscs (and previous releases). [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=241a94abcf465ba9363d93168da5ddd47002930f
We don't have that
And define pkgrelease using buildid. .1.1.0.0 is excessive
This comes from kernel-ark and is part of their solution for a kernel variant that should supplant the factory kernel. Since thats not what we want, remove this to avoid any confusion.
Adds Provides and Conflicts tags to kernel-clk6.18-* packages that cannot be parallel installed with stock Rocky kernel packages: - kernel-doc - kernel-headers - kernel-cross-headers - kernel-debuginfo-common - kernel-tools - kernel-tools-libs - kernel-tools-libs-devel - kernel-selftests-internal This allows these packages to satisfy dependencies for stock kernel packages while preventing simultaneous installation.
Introduce %{pkg_suffix} macro (clk%{patchversion}) and use it for:
- package_name: kernel-%{pkg_suffix}
- tool packages: perf, python3-perf, libperf, rtla, rv
Tool packages now named:
- perf-%{pkg_suffix}
- python3-perf-%{pkg_suffix}
- libperf-%{pkg_suffix}
- libperf-%{pkg_suffix}-devel
- rtla-%{pkg_suffix}
- rv-%{pkg_suffix}
- *-debuginfo variants
Each tool package includes:
- Provides: <original-name> = %{specrpmversion}-%{release}
- Conflicts: <original-name>
This prevents parallel installation with stock Rocky kernel tools
while satisfying dependencies for the original package names.
Switch Module.symvers compression from the dynamic %compression macro (xz) to hardcoded gzip -c9, matching the upstream kernel spec. Also fixes the ghost file permissions from 0644 to 0600. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
Inject +%{pkg_suffix} into KVERREL and the shell-level equivalents
(KernelVer, DevelDir, EXTRAVERSION) so that uname -r shows the CLK
kernel identity, e.g. 6.18.19-1.1.el9_ciq.x86_64+clk6.18.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
…g boot default Reduce duplicated version numbers in the spec to single sources of truth: - kernel_major_minor, kernel_patch, and buildid are the base defines - specversion, kversion, patchlevel, pkgrelease, specrelease, and tarfile_release are all derived from them - Remove specrpmversion (identical to specversion) - Add el_version for tarball naming Export GRUB_NON_STANDARD_KERNEL=true in the posttrans before calling kernel-install so that 20-grub.install respects DEFAULTKERNEL in /etc/sysconfig/kernel. When DEFAULTKERNEL=kernel-core, the CLK kernel will no longer take over as the boot default on upgrade. Update generate_tarball.sh to extract the base defines and compute derived values rather than reading the now-derived tarfile_release directly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
Move -default subpackage out of %if %{with_tools} guard so it exists
independently of the tools build flag. Add Requires(posttrans) on
-core to guarantee vmlinuz is installed before grubby runs. Add
Provides/Conflicts on kernel-provider(default) for mutual exclusion.
Replace the simple %post sed approach with proper %pre/%postun/%posttrans
scriptlets that back up the original /etc/sysconfig/kernel, restore it
on uninstall, and use grubby to set the boot default.
Convert tools subpackages from -n %{package_name}-tools to %package tools
(short form) matching the convention used by all other subpackages.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
The bindgen tool required for kernel Rust support is not packaged in Rocky Linux 9.6. Replace the bindgen BuildRequires with a bundled bindgen-cli crate built from vendored source during the RPM build. Add bundle_bindgen.sh helper script to download, vendor, and tar the bindgen-cli source for inclusion as Source5000. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Jonathan Dieter <jdieter@ciq.com>
We've picked up a source code change to fix a kallsym issue and a spec file change to address noarch builds while secure boot signing
Signed-off-by: Brett Mastbergen <bmastbergen@ciq.com>
ciq-kernel-automation
bot
added
the
created-by-kernelci
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR has been automatically created after successful completion of all CI stages.
Commit Message(s)
Test Results
✅ Build Stage
✅ Boot Verification
✅ Kernel Selftests
Test Comparison
x86_64:
aarch64:
🤖 This PR was automatically generated by GitHub Actions
Run ID: 24302759008