Re: [PATCH 1/8] x86/fpu: Check for missing AVX and AVX-512 xstate bits
Borislav Petkov <[email protected]>
| Newsgroups | gmane.linux.raid,gmane.linux.kernel |
|---|---|
| Message-ID | <20260701004904.GBakRkAEzs5lGvERSZ@fat_crate.local> |
On Fri, Jun 26, 2026 at 05:00:37AM +0000, [email protected] wrote: > [Severity: Critical] > This is a pre-existing issue, but Memory Protection Keys (PKU) isolation > can be bypassed because we don't verify X86_FEATURE_PKU against the > presence of XFEATURE_PKRU in xstate here. > > If a hypervisor reports X86_FEATURE_PKU in CPUID but masks out the > XFEATURE_PKRU xstate component, the kernel's setup_pku() enables CR4.PKE > and forces X86_FEATURE_OSPKE. Because X86_FEATURE_OSPKE is artificially > forced, the feature is not cleared. > > CR4.PKE=1 permits userspace to use WRPKRU, but because XCR0.PKRU=0, > xsaves/xrstors silently ignore the PKRU register during task context > switches, leading to state leakage across tasks. > > Should we also validate PKU against missing xstate components in this > function to prevent isolation bypass? I *think* Sashiko means here our preexisting fpu__init_system_xstate() here but I'm not sure... > [Severity: High] > Does this logic get bypassed if XSAVE or FPU support is missing? > > Earlier in fpu__init_system_xstate(), there are early returns if > X86_FEATURE_FPU or X86_FEATURE_XSAVE are missing: > > if (!boot_cpu_has(X86_FEATURE_XSAVE)) { > pr_info("x86/fpu: x87 FPU will use %s\n", > boot_cpu_has(X86_FEATURE_FXSR) ? "FXSAVE" : "FSAVE"); > return; > } > > If a hypervisor natively enumerates AVX=1 but XSAVE=0 (such as QEMU > with -cpu host,-xsave), check_cpufeature_deps() only warns about unmet Yah, we don't care. We won't support non-sensical guest configs. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette