feat(kernel): enable GTM multicast kernel opts (amd64) — 6.18.34-ct6#4
Conversation
…TED_KEYS) The custom AMT kernel (kernel:<ver>-amt → installer:<ver>-amt) shipped a stock keyring trusting ONLY the Sidero build-time throw-away key, so a Blockcast-signed amt.ko is rejected under module.sig_enforce=1 (`key was rejected by service`), verified on a freshly-imaged Talos node (.builtin_trusted_keys held only the Sidero key). The signed-kernel design (.planning 2026-06-17) never wired the kernel-trust half. Embed the Blockcast module-signing public cert in the kernel's builtin trusted keyring: - add kernel/build/certs/blockcast-modsign.crt (public cert; CN "Blockcast AMT Module Signing Key"; private key held as org secret BLOCKCAST_MODULE_SIGNING_KEY) - set CONFIG_SYSTEM_TRUSTED_KEYS="certs/blockcast-modsign.crt" (amd64+arm64) kernel/build/pkg.yaml already `cp /pkg/certs/* certs/`, so the cert lands at certs/blockcast-modsign.crt in the kernel tree. The throw-away CONFIG_MODULE_SIG_KEY is unchanged (Talos's own modules still verify); this only ADDS the Blockcast key. Pairs with re-enabling signing in linux-amt's amt-kmod build using the same key. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pin the kernel to Linux 6.18.34 (Pkgfile version + sha256/sha512) and regenerate config-amd64 to match. Add CONFIG_STATIC_USERMODEHELPER and CONFIG_PAGE_TABLE_CHECK_ENFORCED to filter-hardened-check IGNORE_VIOLATIONS since the deployed Sidero stock kernel runs without them and enabling is unproven on these Talos VMs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
GTM BGP-MVPN IR leaves receive replicated multicast as a single-label MPLS frame (the leaf's own advertised I-PMSI label, PHP'd transport). Enable the kernel disposition path (CONFIG_MPLS_ROUTING) so the node pops it natively via 'ip -f mpls route add <label> dev lo' instead of an XDP program; CONFIG_MPLS_IPTUNNEL for the encap direction. Both =y (builtin) to sidestep the Talos imager module-curation trap that bit amt.ko. CONFIG_MPLS/NET_MPLS_GSO were already =y; LWTUNNEL=y satisfies the iptunnel dependency. BLO-8371. Signed-off-by: Omar Ramadan <omar@blockcast.net>
cdn.kernel.org evicted the linux-6.18.34.tar.xz release tarball (superseded by 6.18.35), 404ing the pinned source. Staying on 6.18.34 is deliberate: the deployed amt-kmod extension is built and signed for 6.18.34-talos, and this branch's ct-lineage kernel is the one proven under module.sig_enforce=1. Switch the source to the git.kernel.org stable snapshot of the v6.18.34 tag (content-verified: Makefile VERSION/PATCHLEVEL/SUBLEVEL = 6.18.34) and re-pin its hashes. NOTE: snapshot tarballs are generated on demand and their hashes can rotate with kernel.org infra changes — if this pin ever mismatches, re-verify content and re-pin. BLO-8371. Signed-off-by: Omar Ramadan <omar@blockcast.net>
CONFIG_IPV6_PIMSM_V2=y so pim6d's MRT6_PIM upcall registration succeeds. Without it the kernel returns ENOPROTOOPT and FRR disables the entire v6 mroute socket at startup (fd=-1), leaving pim6d without a v6 multicast data plane and exercising failure paths in every MFC update. The v4 side (CONFIG_IP_PIMSM_V2) has always been enabled; this brings v6 to parity for the BGP-MVPN GTM receiver nodes. Compile-time bool (no module option), builtin like the MPLS options — no imager module-curation impact. Signed-off-by: Omar Ramadan <omar@blockcast.net>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
![allyblockcast[bot]](https://avatars.githubusercontent.com/u/57363972?s=60&v=4){kind=small}
There was a problem hiding this comment.
Ally — Consolidated PR Review
Lenses: pr-review-toolkit (code/tests/comments/errors/types — largely n/a for a binary kernel-config diff) + gstack/review (structural/scope) + native-codex (adversarial diff read, nested CLI unavailable in this runtime).
Critical Issues (2)
-
[native-codex]
Pkgfile:106,kernel/build/config-amd64(~130 changed lines) — The PR description says this is a single compile-time bool flip (CONFIG_IPV6_PIMSM_V2=y, "like the MPLS options"), but the actual diff is a full kernel-config rebase:linux_versionis downgraded 6.18.35 → 6.18.34, and dozens of unrelated subsystems change (ATM, X25, LAPB, PHONET, RDS,IP_NF_IPTABLES/IP6_NF_IPTABLES/BRIDGE_NF_EBTABLES, DVB drivers, and ~30 drivers flipped from loadable module (=m) to built-in (=y) — VMware/Xen/Hyper-V stacks, USB HCDs, storage, InfiniBand, etc.). None of this is mentioned, so reviewers approving on the stated scope have no visibility into a kernel downgrade or a large attack-surface/build-size change shipping to fleet GTM nodes alongside it.- Split the PIM-SM flag change from the config rebase, or make the rebase and its rationale explicit in the PR description (looks like a
/proc/config.gzboot-parity rebase against the deployed Sidero stock kernel — say so).
- Split the PIM-SM flag change from the config rebase, or make the rebase and its rationale explicit in the PR description (looks like a
-
[native-codex]
kernel/build/config-amd64:6915and:2092-2093—CONFIG_STATIC_USERMODEHELPERis disabled (wasywithPATH="/sbin/init") whileCONFIG_UEVENT_HELPERis simultaneously re-enabled with a writable legacy path (/sbin/hotplug). This pairing removes the pinned usermode-helper path and reinstates the legacy hotplug helper mechanism — a well-known local-privesc-relevant combination (arbitrary usermode-helper path can be repointed via/sys/module/*/uevent_helperor/proc/sys/kernel/hotplug). Both exemptions are added to the hardening gate in the same commit (kernel/build/scripts/filter-hardened-check.py:40-41, "unproven on these Talos VMs"), so the check that should catch this is being loosened at the same time, with no security review called out in the PR body.- Needs explicit sign-off that this hardening regression is intentional/accepted risk for the fleet, not an artifact of rebasing onto the stock config.
Important Issues (2)
- [gstack/review]
kernel/prepare/pkg.yaml:9— Kernel source fetch moved from a pinnedcdn.kernel.orgrelease tarball to agit.kernel.orggit-snapshot tarball (.../snapshot/linux-{{ .linux_version }}.tar.gz). Different provenance/generation semantics than the official release artifact; worth confirming this is deliberate (and that hashes were re-pinned against the new source, which they were) rather than an incidental side effect of whatever produced the version downgrade above. - [native-codex]
kernel/build/certs/blockcast-modsign.crt(new) is wired intokernel/build/config-arm64'sCONFIG_SYSTEM_TRUSTED_KEYS, but amd64'sCONFIG_SYSTEM_TRUSTED_KEYSis untouched and still"". For a PR titled "(amd64)" that introduces a new Blockcast module-signing cert (and whose own description citesamt.kobeing "ct6-signed"), the amd64 kernel not embedding this trust anchor while arm64 does looks like a gap rather than a deliberate asymmetry — worth confirming amd64 doesn't need it, or wiring it up to match.
Strengths
- The committed cert (
blockcast-modsign.crt) is a public X.509 cert only — no private key material added to the repo. - The two new hardening-gate exemptions carry inline rationale comments (boot parity with the deployed Sidero v1.13.4 stock kernel) rather than being silent suppressions — good practice, it just needs to also be surfaced in the PR description itself.
Recommended Action
- Before merge: confirm the
linux_versiondowngrade and thecdn.kernel.org→git.kernel.orgsource change are both intentional, not rebase artifacts. - Get explicit security sign-off on disabling
CONFIG_STATIC_USERMODEHELPERwhile re-enablingCONFIG_UEVENT_HELPER, given this ships to GTM fleet nodes. - Reconcile the amd64/arm64
SYSTEM_TRUSTED_KEYSasymmetry for the new signing cert. - Update the PR description to reflect the true scope (config rebase + PIM-SM flag), or split into separate PRs so each can be reviewed on its own merits.
|
Added commit |
kkroo
changed the title
There was a problem hiding this comment.
Ally — Consolidated PR Review
Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
reviewed head: 94061a9
Critical Issues (1)
- [native-codex]
kernel/build/config-amd64:7239/kernel/build/config-arm64:9997— module-signing trust cert appears wired to the wrong architecture, breaking the exact "amt.ko ct6-signed" chain this PR's title/companion pipeline depends on.config-amd64now setsCONFIG_MODULE_SIG_KEY="certs/blockcast_signing_key.pem", but that file doesn't exist anywhere in this repo, andkernel/build/pkg.yaml'scp -v /pkg/certs/* certs/only stagesblockcast-modsign.crtandx509.genkeyintocerts/for both arches — so the amd64 build has noblockcast_signing_key.pemto satisfy that path (likely build failure, or at best silent fallback to an unintended key).- Meanwhile
config-amd64'sCONFIG_SYSTEM_TRUSTED_KEYSis left""(untouched by this PR), whileconfig-arm64— the only other change in that file, 1 line total — getsCONFIG_SYSTEM_TRUSTED_KEYS="certs/blockcast-modsign.crt". - Per
.github/workflows/compose-signed-installer.yml's own header comment, the kernel that must "TRUST the Blockcast module-signing cert" so the externally-signedamt.kodoesn'tEKEYREJECTEDis the amd64 installer base (--arch amd64), not arm64. arm64 isn't part of the AMT signed-installer pipeline at all, and nothing else in this PR touches arm64. - Net effect: the trust wiring landed on the architecture that doesn't need it, and the architecture that does need it (amd64) got a dangling key reference instead. If this PR's build/deploy claims in the description were validated on an earlier commit of this branch, they don't cover the current head — worth re-verifying the
compose-signed-installer+ amt.ko load path against this exact SHA before merge.
Important Issues (2)
-
[gstack/review]
kernel/build/config-amd64(LSM / hardening block, ~L911-951) — kernel hardening quietly weakened, undocumented in the PR description.CONFIG_STATIC_USERMODEHELPERandCONFIG_PAGE_TABLE_CHECK_ENFORCEDboth flip fromyto unset, andfilter-hardened-check.pywas updated in the same diff to suppress the corresponding hardening-checker warnings ("unproven on these Talos VMs" / "config rebased on /proc/config.gz for boot parity"). That rationale may be legitimate, but it's a real hardening regression riding along in a PR titled purely as an IPv6 PIM-SM enable — worth a one-line callout in the PR body so it isn't missed ingit log.- Separately,
CONFIG_SECURITY_SAFESETIDis disabled (y→ not set) butCONFIG_LSM=still listssafesetidby name, andloadpinis newly added to that same string even thoughCONFIG_SECURITY_LOADPINis (and was already) not set anywhere in this config. Neither LSM is actually compiled in, so the ordering string references two no-op entries — a sign the.configwasn't fully reconciled viamake oldconfig/listnewconfigagainst the new base, which also explains the scope issue below.
-
[pr-review-toolkit]
kernel/build/config-amd64— diff scope far exceeds the stated change. The PR title/description describe a single compile-time bool (CONFIG_IPV6_PIMSM_V2=y, matching the existingCONFIG_IP_PIMSM_V2pattern — that specific hunk, L1401-1402 in the diff, looks correct and mirrors v4). But the actual diff flips ~150+ unrelatedCONFIG_*options across ACPI, netfilter/nftables (new iptables/ip6tables/ebtables match & target modules), DVB tuner drivers, framebuffer/DRM (CONFIG_FBre-enabled with ~40 sub-options), USB host controllers, crypto userspace API, and dozens of=m→=ymodule-to-builtin conversions (Hyper-V, Xen, VirtIO, SCSI, etc.), plus a kernel patch-version downgrade (6.18.35→6.18.34inPkgfile/pkg.yaml, also switching the source tarball URL fromcdn.kernel.orgtogit.kernel.orgsnapshot). None of this is mentioned in the PR body. If it's an artifact of regenerating the config against a different base, please regenerate a minimal diff or explicitly call out and justify the version pin + collateral drift — builtin-vs-module changes affect boot image size and which drivers can be blacklisted/unloaded at runtime.
Suggestions (1)
- [pr-review-toolkit]
kernel/prepare/pkg.yaml— the kernel source is now fetched from agit.kernel.orgsnapshot tarball (linux.git/snapshot/linux-{version}.tar.gz) instead of the previouscdn.kernel.orgrelease tarball. Snapshot tarballs fromgit.kernel.orgare documented as not stability-guaranteed/reproducible (content can change for the same ref over time), unlike the numbered release tarballs on cdn.kernel.org. Worth confirming this is intentional and that the pinnedsha256/sha512are re-verified on each fetch (not just first ingestion), since a mutable upstream artifact undermines the pin's purpose.
Strengths
- The core stated change is correct and minimal in isolation:
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y+CONFIG_IPV6_PIMSM_V2=ycleanly mirrors the existing, already-enabled v4 pair (CONFIG_IP_MROUTE_MULTIPLE_TABLES/CONFIG_IP_PIMSM_V2), matching the PR's stated rationale for why v6 PIM-SM was silently disabled (MRT6_PIM→ENOPROTOOPT). - The
filter-hardened-check.pysuppressions include specific, dated rationale comments rather than blanket silencing.
Recommended Action
- Fix the module-signing trust-cert/key wiring before merge (Critical) — confirm which arch actually needs
SYSTEM_TRUSTED_KEYSpointing atblockcast-modsign.crt, and confirmblockcast_signing_key.pemeither exists in the amd64 build context or that reference is a leftover to remove. - Call out the hardening regressions and kernel-version downgrade explicitly in the PR description, or split them into a separate PR from the PIM-SM enable.
- Consider regenerating
config-amd64as a minimal diff against the intended base, or document why the wider drift is expected.
|
Status update from this pass:
Next unblock: add/grant |
|
Signed compose is now green after interactive gh auth + repo GH_PAT update.\n\nProof:\n- compose-signed-installer run: https://github.com/Blockcast/pkgs/actions/runs/29136475511\n- consumed base: ghcr.io/blockcast/installer:v1.13.4-amt-ct6-mroute\n- consumed extension: ghcr.io/blockcast/amt-kmod:v1.13.4\n- published deployable signed installer: ghcr.io/blockcast/installer:v1.13.4-amt-ct6-mroute-signed@sha256:efe53dc2b397a3eb3f13b8b31a0a4e20bbaccaac6a903894b28969fe224e616a\n\nThe only remaining PR rollup issue I see is the generic default job still queued on the pkgs runner path; the ct6 kernel/base/signed installer proof chain is green. |
1 participant
Problem
CT6/GTM nodes need the v6 multicast dataplane to match v4: without
CONFIG_IPV6_PIMSM_V2=y,MRT6_PIMreturnsENOPROTOOPTandpim6ddisables its v6 mroute socket. The CT6 DIMT path also needs multicast route-table steering enabled for both families.Changes
CONFIG_IPV6_PIMSM_V2=yCONFIG_IP_MROUTE_MULTIPLE_TABLES=yCONFIG_IPV6_MROUTE_MULTIPLE_TABLES=yCONFIG_NET_IPGRE_BROADCASTdisabled intentionally. Current Blockcast DIMT uses IPIP-in-FOU; the draft does not require GRE broadcast for this deployment path.BLOCKCAST_MODULE_SIGNING_KEY, validates it matchesblockcast-modsign.crt, and scrubs it after build.GH_PAT) for cross-repo privateamt-kmodpulls.Verification
build-ct6-mroute-kernelrun29131419459passed.6.18.34.ghcr.io/blockcast/kernel:v1.13.4-amt-ct6-mroute@sha256:e88d73108f1dd0575cbe6a229aa3f42ded20a8b7b1d6915db503fa2894c42228.DEPMODfor6.18.34-talos, includingip_gre.ko,ip6_gre.ko, andvport-gre.ko.build-amt-installerrun29134485069passed.ghcr.io/blockcast/installer:v1.13.4-amt-ct6-mroute.compose-signed-installerrun29136475511passed.ghcr.io/blockcast/amt-kmod:v1.13.4using the repoGH_PATpackage token.ghcr.io/blockcast/installer:v1.13.4-amt-ct6-mroute-signed@sha256:efe53dc2b397a3eb3f13b8b31a0a4e20bbaccaac6a903894b28969fe224e616a.Merge Gate
The ct6 custom proof chain is green. The PR rollup still shows the generic
defaultjob queued on thepkgsrunner path, so GitHub reports the PR asUNSTABLEuntil that queue clears or branch protection accepts the explicit ct6 proof runs above.