[ciq-6.18.y-next] Multiple patches tested (100 commits)#1385
Open
ciq-kernel-automation[bot] wants to merge 102 commits into
Open
[ciq-6.18.y-next] Multiple patches tested (100 commits)#1385ciq-kernel-automation[bot] wants to merge 102 commits into
ciq-kernel-automation[bot] wants to merge 102 commits into
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>
Requested by the lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Retquested by the lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
…ypically implemented after dh_is_pubkey_valid. Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
…the digest to be generated - it must be at least 112 bits. Requested by the lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Ensure this is initialized correctly based on system state and key length. Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Ensure this is initialized correctly based on system state and key length. Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Ensure this is initialized correctly based on system state and key length. Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Ensure this is initialized correctly based on system state and key length. Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Ensure this is initialized correctly based on system state and key length. Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
…ciq.6.18.20260531" Requested by lab. Will be changed for rpm builds. Signed-off-by: Jeremy Allison <jallison@ciq.com>
…E_128. Requested by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Adds a workflow that runs on PRs targeting ciq-*-next branches and checks whether new upstream commits touch FIPS protected directories. Posts a PR comment alerting reviewers if changes are found. Uses check_fips_changes.py from kernel-src-tree-tools to perform the check.
…ate between internal and external IV generation when AES-GCM encryption is performed. Required by lab. Signed-off-by: Jeremy Allison <jallison@ciq.com>
Catches *_ciq-6.18.y-no-ltp, *_ciq-6.18.y-pr-only, and other branch-name suffix variants used by the kernelCI skip-stages feature.
When FIPS mode is enabled (via fips=1), there is an absolute need for the
DRBG to be available. This is at odds with the fact that the DRBG can be
built as a module when in FIPS mode, leaving critical RNG functionality at
the whims of userspace.
Userspace could simply rmmod the DRBG module, or not provide it at all and
thus a different stdrng algorithm could be used without anyone noticing.
Additionally, when running a FIPS-enabled userspace, modprobe itself may
perform a getrandom() syscall _before_ loading a given module. As a result,
there's a possible deadlock scenario where the RNG core (crypto/rng.c)
initializes _before_ the DRBG, thereby installing its getrandom() override
without having an stdrng algorithm available. Then, when userspace calls
getrandom() which redirects to the override in crypto/rng.c,
crypto_alloc_rng("stdrng") invokes the UMH (modprobe) to load the DRBG
(which is aliased to stdrng). And *then* that modprobe invocation gets
stuck at getrandom() because there's no stdrng algorithm available!
There are too many risks that come with allowing the DRBG and RNG core to
be modular for FIPS mode. Therefore, make CRYPTO_FIPS require the DRBG to
be built-in, which in turn makes the DRBG require the RNG core to be
built-in. That way, it's guaranteed for these drivers to be built-in when
running in FIPS mode.
Also clean up the CRYPTO_FIPS option name and remove the CRYPTO_ANSI_CPRNG
dependency since it's obsolete for FIPS now.
Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
It is technically a risk to permit extrng registration by modules after kernel init completes. Since there is only one user of the extrng interface and it is imperative that it is the _only_ registered extrng for FIPS compliance, restrict the extrng registration interface to only permit registration during kernel init and only from built-in drivers. This also eliminates the risks associated with the extrng interface itself being designed to solely accommodate a single registration, which would therefore permit the registered extrng to be overridden or even removed by an unrelated module. Signed-off-by: Sultan Alsawaf <sultan@ciq.com> Signed-off-by: Jonathan Maple <jmaple@ciq.com>
In FIPS mode, the DRBG must take precedence over all stdrng algorithms. The only problem standing in the way of this is that a different stdrng algorithm could get registered and utilized before the DRBG is registered, and since crypto_alloc_rng() only allocates an stdrng algorithm when there's no existing allocation, this means that it's possible for the wrong stdrng algorithm to remain in use indefinitely. This issue is also often impossible to observe from userspace; an RNG other than the DRBG could be used somewhere in the kernel and userspace would be none the wiser. To ensure this can never happen, only allow stdrng instances from the DRBG to be registered when running in FIPS mode. This works since the previous commit forces the DRBG to be built into the kernel when CONFIG_CRYPTO_FIPS is enabled, so the DRBG's presence is guaranteed when fips_enabled is true. Signed-off-by: Sultan Alsawaf <sultan@ciq.com> Signed-off-by: Jonathan Maple <jmaple@ciq.com>
The 6.18.y version of "crypto: rng - Implement fast per-CPU DRBG instances" picked up a few spots that use spaces where the ciqlts9_6 tree's version [1] uses tabs: the lock_default_rng() comment's numbered list, the line continuations in the unlock_local_rng() macro, and a brace in crypto_devrandom_read_iter(). A nearby block comment was also missing the space before its '*'. Fix them up. [1] b0c560a Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
The per-CPU DRBG instances used to be torn down by crypto_del_default_rng() under del_pcpu_rwsem, and the read path took that rwsem as a reader to keep an instance from being freed out from under it. That machinery only made sense back when the extrng override could be unregistered and the DRBG could be built as a module. That's no longer the case. extrng registration is now restricted to init time from built-in drivers, and FIPS mode requires the DRBG to be built-in, so the registered DRBG can't be unregistered or swapped out. As such, the per-CPU instances are never torn down, and the deletion rwsem just adds a lock to the hot read path for no reason. Drop the deletion rwsem and crypto_del_pcpu_rng(), and stop freeing the per-CPU instances in crypto_del_default_rng(). Since the instances are permanent now, allocate their pages once at init time with __GFP_NOFAIL and ditch free_pcpu_inst() along with the failure paths in crypto_rng_init(); failing to install the RNG override in FIPS mode would be catastrophic, so the setup isn't allowed to fail anyway. This brings the per-CPU DRBG implementation in line with the ciqlts9_6 tree's version of "crypto: rng - Implement fast per-CPU DRBG instances" [1]. [1] b0c560a Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
The fast per-CPU DRBG path computes its initial user destination address
straight from the iov_iter. For an ITER_IOVEC iter it reads iter_iov_addr()
and iter_iov_len() of the current segment, but when the iovec leads with
one or more zero-length segments, the current segment is one of those empty
entries. iter_iov_addr() then hands back the base of an empty segment,
which is whatever userspace put there: its base can be NULL or some other
unwritable address, since a zero-length segment is never actually touched.
Right after the setup, that address is prefaulted, and on a bogus base it
fails. A failed prefault on the very first address is treated as fatal, so
the whole read bails out to -EFAULT even though there are perfectly good
non-empty segments later in the iovec. This is reachable with something as
simple as readv() on /dev/urandom where the first iovec entry is {NULL, 0}.
Fix it by advancing the iterator by zero before reading the first address.
The iovec advance loop walks past every leading empty segment and stops at
the first non-empty one, and there's guaranteed to be such a segment
because iov_iter_count() is nonzero at this point. Empty segments that crop
up mid-stream are already skipped by the per-copy advance, so this only
needs to run once during setup.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
While GUP pinning makes it possible to pin the page _backing_ a user address, it *doesn't* pin the page table entry (PTE) for that mapping. This means the pinned physical page can be separated from the user address it was backing, and even back a _different_ user address within the same process. PTE zapping naturally happens during memory reclaim when memory pressure is elevated, and can even be done directly by userspace via madvise(MADV_DONTNEED). Since the optimized per-CPU DRBG loop assumes copy_to_user_nofault() will always succeed on a GUP-pinned page, it immediately bails out when the nofault copy actually *does* fail for the reasons described above. This results in either fewer than requested random bytes copied or, more seriously, a spurious EFAULT returned to userspace when no random bytes were copied. As it turns out, there's no way to pin a PTE. That means it's not possible to guarantee a 100% success rate for the copy_to_user_nofault() attempt. Fix this by handling copy_to_user_nofault() errors correctly with a fall back to a faultable copy attempt outside of the RNG lock. In order to guarantee forward progress for the caller, an on-stack bounce buffer is used to copy up to 256 bytes of the generated random bytes whenever this happens rather than discarding the whole thing. There's no need to use GUP pinning anymore since there's no use for having a page pinned without pinning a PTE to go along with that page, hence the page pinning is eliminated which saves a software page table walk that was performed for _at least_ every destination page. Reported-by: Kun Yi <kunyi@google.com> Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
This reverts commit ef467f3. This helper is no longer used by the FIPS-mode RNG, which was the motivation for reintroducing it. Remove it. Signed-off-by: Sultan Alsawaf <sultan@ciq.com>
ciq-kernel-automation
Bot
added
the
created-by-kernelci
Author
✅ FIPS Check: No Protected Directory ChangesNo FIPS protected directories were modified in the new upstream commits. |
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
11 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
✅ LTP Results
🤖 This PR was automatically generated by GitHub Actions
Run ID: 28264575329