Skip to content

feat(profiles): validate newest Ubuntu kernels via in-guest kernel-sweep#91

Merged
ErenAri merged 1 commit into
mainfrom
chore/ubuntu-kernel-sweep
Jul 21, 2026
Merged

feat(profiles): validate newest Ubuntu kernels via in-guest kernel-sweep#91
ErenAri merged 1 commit into
mainfrom
chore/ubuntu-kernel-sweep

Conversation

@ErenAri

@ErenAri ErenAri commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

What

Adds kernel-sweep profiles pinning the newest shipping kernel for each Ubuntu series, and validates every one for real — each boots the stock cloud image, installs its kernel from the archive pool, reboots into it, and runs the validator.

Profile Kernel proven
ubuntu-18.04 4.15.0-213
ubuntu-20.04 5.4.0-218
ubuntu-22.04 5.15.0-186
ubuntu-22.04-lockdown 5.15.0-186
ubuntu-24.04 6.8.0-136
ubuntu-25.10 6.17.0-41
ubuntu-25.10-minimal 6.17.0-41

All 7 pass. Also records ubuntu-22.04-5.15-k5.15.0-181 (previously unvalidated) and refreshes its package URLs to the mirror kernel-crawler now publishes (same 5.15.0-181.191 build, validated with the new URLs).

This is coverage, not a freshness fix

Worth being explicit: sweep emits derived profiles (<base>-k<release>), so these land as new baseline entries. The base profiles stay flagged stale, because a stock cloud image cannot ship a kernel newer than itself while the oracle compares against the newest package. Stale count is unchanged at 11 (of 39 profiles, up from 31).

The real fix is to make the oracle family-aware — treat a series as covered when any profile in the family validated the newest kernel. We now literally have ubuntu-22.04-5.15-k5.15.0-186 proving 5.15.0-186 works on jammy while ubuntu-22.04-5.15 still reports stale. Filed as a follow-up rather than bolted on here.

Known limitation found

Sweeping to a release the base image already ships fails on a dpkg conflict (unsigned vs installed signed linux-image) — hit with jammy 5.15.0-185, which the current image already carries. Such targets are redundant (the base profile already covers that kernel), so the generated -185 profile was dropped rather than shipped broken. kernel-sweep could skip image-shipped releases; noted in the follow-up.

Also

README now records that the upstream falcosecurity/libs lane's first scheduled run passed on every kernel in the matrix.

Verification

go test ./internal/vm -run 'TestAllProfileYAMLLoadAndValidate|TestProfileExecutionTransportSupport' passes; all 7 sweep targets validated on real KVM boots with kernels confirmed from in-guest uname -r.

Adds kernel-sweep profiles pinning the newest shipping kernel for each
Ubuntu series and validates them for real: each boots the stock cloud
image, installs its kernel from the archive pool, reboots into it, and
runs the validator. All pass:

  ubuntu-18.04           4.15.0-213
  ubuntu-20.04           5.4.0-218
  ubuntu-22.04           5.15.0-186
  ubuntu-22.04-lockdown  5.15.0-186
  ubuntu-24.04           6.8.0-136
  ubuntu-25.10           6.17.0-41
  ubuntu-25.10-minimal   6.17.0-41

This is coverage, not a freshness fix: sweep emits derived profiles
(<base>-k<release>), so these are new baseline entries and the base
profiles stay flagged stale by the image-vs-package lag (a stock image
cannot ship a kernel newer than itself). Making the oracle family-aware
-- treating a series as covered when any profile in the family
validated the newest kernel -- would be the real fix; filed separately.

Also records ubuntu-22.04-5.15-k5.15.0-181 (previously unvalidated) and
refreshes its package URLs to the mirror kernel-crawler now publishes
(same 5.15.0-181.191 build; validated with the new URLs).

Known limitation found: sweeping to a release the base image already
ships fails on a dpkg conflict (unsigned vs installed signed
linux-image), e.g. jammy 5.15.0-185. Such targets are redundant -- the
base profile already covers that kernel.

README: record that the upstream falcosecurity/libs lane's first
scheduled run passed on every kernel in the matrix.

Signed-off-by: ErenAri <erenari27@gmail.com>
Copilot AI review requested due to automatic review settings July 21, 2026 00:27

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@ErenAri
ErenAri merged commit b820dee into main Jul 21, 2026
8 of 9 checks passed
@ErenAri
ErenAri deleted the chore/ubuntu-kernel-sweep branch July 21, 2026 00:30
ErenAri added a commit that referenced this pull request Jul 21, 2026
…nt (#93)

A stock cloud image can never ship a kernel newer than itself, while
kernel-crawler tracks the newest package, so image-based profiles were
flagged stale permanently no matter how much validation existed. After
#91 we had ubuntu-22.04-5.15-k5.15.0-186 proving 5.15.0-186 loads on
jammy, yet ubuntu-22.04-5.15 still reported stale -- the oracle was
asking 'did this exact profile boot the newest kernel?' instead of 'has
the newest kernel for this series been validated at all?'.

Add a 'covered' status: when a kernel-sweep profile in the same family
(<base>-k<release>) has validated a kernel at least as new as the
newest shipping one, the base profile reports covered, names the
profile that proves it (covered_by), and is excluded from StaleCount.

Family matching keys off the full '<base>-k' prefix and requires a
digit after it, so sibling variants stay independent
(ubuntu-22.04-5.15-lockdown is only covered by its own -lockdown-k
derivatives) and ids that merely contain '-k' cannot match.

Against the committed baselines this takes stale 11 -> 6 without
weakening the signal: the remaining 6 are genuinely unvalidated on
their newest kernel (RHEL-family, which kernel-sweep does not support,
plus oracle-linux-9-uek7 and rhel-8).

Closes #92.

Signed-off-by: ErenAri <erenari27@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants