Guest Kernel 6.18 release preview#6013
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6013 +/- ##
=======================================
Coverage 82.85% 82.85%
=======================================
Files 277 277
Lines 30633 30633
=======================================
Hits 25381 25381
Misses 5252 5252
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
0c39310 to
4b475d0
Compare
Manciukic
left a comment
Manciukic
left a comment
There was a problem hiding this comment.
mostly lgtm, with a few clarifications required
1dfb25e to
6a7d47b
Compare
803cc82 to
d0c5c85
Compare
| and guest_kernel_version | ||
| and guest_kernel_version >= (6, 18) | ||
| ): | ||
| exception_dict["spectre_v2"] = "BHI: Vulnerable" |
There was a problem hiding this comment.
The way the exception is enforced is too broad: for files in the exception dict, the test only asserts the exception string appears somewhere — the normal "no Vulnerable" check is skipped entirely. Since spectre_v2 is one line that also carries the main mitigation status, a guest that lost eIBRS entirely (Vulnerable; IBPB: disabled; ... BHI: Vulnerable) would still pass. The commit message says the exception holds "as long as the main mitigation is still active", but nothing checks that. Suggest also requiring the file to start with Mitigation:.
There was a problem hiding this comment.
+1, this is a real gap. Two failure directions the current assert "BHI: Vulnerable" in stdout doesn't handle, both stemming from spectre_v2 being a single sysfs line that mixes the primary mitigation status with the BHI: sub-state:
-
Masking (the one you noted): if the main mitigation regresses, e.g.
Vulnerable; IBPB: disabled; ...; BHI: Vulnerable, the substring"BHI: Vulnerable"is still present, so the test passes even though eIBRS is gone. The"no Vulnerable"guard is skipped for the whole file. -
Spurious failure (the opposite direction): a no-eIBRS Intel guest doesn't necessarily print
BHI: Vulnerable.spectre_bhi_state()returnsBHI: Retpoline(retpoline +rrsba_disabled) orBHI: SW loopin other configs. That can happen for non-templated guests on an INTEL_CASCADELAKE host (no eIBRS) or T2S/T2CL templates presenting Skylake/Cascade-Lake — where the exact-match would then fail even though nothing regressed.
Suggest making the check assert both halves explicitly rather than a single substring: the line starts with Mitigation: (primary mitigation intact — covers #1) and the only Vulnerable token is the BHI: one (covers #2 without masking a real secondary regression). Roughly:
# spectre_v2: accept BHI being reported vulnerable (expected on >=6.18 guests, see above),
# but only if the primary mitigation is still active and BHI is the *only* vulnerable field.
def _spectre_v2_ok(stdout):
line = stdout.strip()
if not line.startswith("Mitigation:"):
return False
vulns = [f for f in line.split(";") if "Vulnerable" in f]
return vulns == [f for f in vulns if "BHI:" in f] # BHI is the sole vulnerable fieldThat keeps the exception scoped to the intended BHI case while preserving detection of both a lost primary mitigation and any other sub-component flipping to Vulnerable.
There was a problem hiding this comment.
Ty, the latest rebase introduced this error.
I reverted the code line:
- exception_dict["spectre_v2"] = "BHI: Vulnerable"
+ exception_dict["spectre_v2"] = "Mitigation"
This should be enough to re-establish proper security check. A more sophisticated check like the one proposed above it's redundant, in my opinion, given the justification of the exception:
# On kernel >= 6.18, the new attack vector control framework only enables BHI
# mitigation when CPU_MITIGATE_GUEST_HOST is active (i.e., the system runs VMs).
# https://github.com/amazonlinux/linux/blob/amazon-6.18.y/mainline/arch/x86/kernel/cpu/bugs.c#L2221
# https://github.com/amazonlinux/linux/blob/amazon-6.18.y/mainline/kernel/cpu.c#L3192
# Since Firecracker guests do not themselves run nested VMs, the guest kernel
# intentionally reports "BHI: Vulnerable" in the spectre_v2 sysfs file.
As a side note, this bug highlighted that the T2CL template is using Retpolines mitigation, instead of eIBRS. This is due to an anomalous interaction in MSR read between Firecracker's CPU templates and KVM, which is currently under investigation (but basically unrelated to this PR).
There was a problem hiding this comment.
Change of plan: i'm refactoring the test logic in order to accept regex matching and will pass the exception r"^Mitigation:.*BHI:.*" instead; This will ensure that the spectre v2 is mitigated, and that give better emphasis on the fact that we don't care about BHI (due to the CPU_MITIGATE_GUEST_HOST)
Add vmlinux-6.18 kernel parameters to the test framework artifacts module, including both regular and debug kernel variants, and add the 6.18 pattern to the supported kernels list. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
test_cpu_config_dump_vs_actual[vmlinux-6.18.33-PCI_OFF] fails with:
Mismatched MSR for 0x00000da0:
actual=0b...0001100000000000 vs dump=0b...0000000000000000
assert 6144 == 0
MSR_IA32_XSS (0xDA0) is a R/W MSR that the guest OS uses to enable
supervisor state components in XSAVES/XRSTORS. After boot, the guest
sets bits for supported supervisor states (e.g., CET supervisor states
at bits 11-12), causing the runtime value to differ from the initial
dump. Add it to the exception list since this divergence is expected
guest OS behavior.
Signed-off-by: Remo Andreoli <andrremo@amazon.com>
Add missing MSR baseline CSV files generated by the firecracker optional pr pipeline for custom CPU templates. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
Intel Cascade Lake CPU checks mutate the module-level sets with |= to adjust for invpcid_single for 5.10 and 6.1 guest kernels. Since this is done without .copy(), this fails the subsequent guest kernel 6.18 test. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
invpcid_single feature was dropped in Linux v6.6 (commit 54e3d943), so any host/guest combination running kernel 6.18 will fail the CPU feature check, unless both host and guest are running the 6.18. Refactor the Intel Sapphire/Granite Rapids, Intel Icelake, and AMD Milan/Genoa cases in host_vs_guest CPU features check test to handle invpcid_single "bidirectionally". Signed-off-by: Remo Andreoli <andrremo@amazon.com>
Since commit 78ce84b9e0a5 ("x86/cpufeatures: Flip the /proc/cpuinfo
appearance logic") in v6.11, the xtopology and debug_swap flags
gained a quoted name and are now reported in /proc/cpuinfo.
This commit handle both flags existance dynamically at test runtime,
mirroring the existing invpcid_single pattern.
Signed-off-by: Remo Andreoli <andrremo@amazon.com>
KVM advertises the ssbs feature to guests regardless of whether the host kernel applies the Neoverse N1/V1/V2 errata workaround. This means the guest always sees ssbs, independent of guest kernel version. This commit clarifies this in the code and add links to the relevant Amazon Linux backport commits. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
Allow for more precise exception patterns, and improved debuggability on failure. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
On kernel 6.18+, the new attack vector control framework only enables BHI mitigation when CPU_MITIGATE_GUEST_HOST is active. Since Firecracker guests do not run nested VMs, the guest kernel intentionally reports "BHI: Vulnerable" or "BHI: Retpotlines" (T2CL only). Add an exception in get_vuln_files_exception_dict() that accepts any BHI status for 6.18+ guests as long as the main mitigation (e.g., Enhanced IBRS) is still active. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
The spectre-meltdown-checker reports INCEPTION (CVE-2023-20569) as vulnerable inside 6.18 guests on AMD Milan/Genoa on older host kernels when no CPU template is applied. This is because the host is mitigated ("safe RET") but Firecracker does not expose the microcode version to the guest, so the checker cannot verify the mitigation. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
Add v6.18 to the guest kernel support table with v1.16.1 as the minimum Firecracker version and 2028-06-01 as the minimum end of support, per the 2-year minimum stated above the table. Signed-off-by: Remo Andreoli <andrremo@amazon.com>
3 participants
Changes
Test Fixes for 6.18 Compatibility
invpcid_singleremoval in Linux v6.6+ bidirectionally across Intel and AMD platformsxtopologyanddebug_swapuser-visibility changes since kernel v6.11 on AMD Milan/Genoassbscheck for 6.18 on Neoverse N1/V1/V2CI Tooling
Reason
This PR adds full support for running Linux 6.18 as a guest kernel in Firecracker microVMs. It is marked as "preview" due to a networking regression on m7i/m8i instances; merging it now allows us to monitor the regression through CI pipelines.
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.PR Checklist
tools/devtool checkbuild --allto verify that the PR passesbuild checks on all supported architectures.
tools/devtool checkstyleto verify that the PR passes theautomated style checks.
how they are solving the problem in a clear and encompassing way.
in the PR.
CHANGELOG.md.Runbook for Firecracker API changes.
integration tests.
TODO.rust-vmm.