https://bugzilla.suse.com/show_bug.cgi?id=1218231 Bug ID: 1218231 Summary: Hw virtualization enabled in BIOS of Intel Skylake i5-6200U, but lscpu says "VMX" disabled Classification: openSUSE Product: openSUSE Distribution Version: Leap 16.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: el@horse64.org QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- I boot with these kernel options for CPU security: "mitigations=auto,nosmt mds=full,nosmt", on a laptop with Skylake i5-6200U. However, in the BIOS/UEFI options I enabled all virtualization features of this CPU. This means VT-x/VMX should be available, since Skylake supports this according to product pages. The kernel's iTLB multihit mitigation documentation does NOT suggest that any mitigation option will ever disable VT-x/VMX fully. Therefore, I would strongly expect it to be enabled on this system with this configuration. Now here comes the problem: $ lscpu | grep VMX Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled $ cat /sys/devices/system/cpu/vulnerabilities/itlb_multihit KVM: Mitigation: VMX disabled Something seems to be wrong here. As a semi naive uninformed user, I am guessing the following possible options for what happened: Option A: VMX is actually disabled by the kernel through some mitigation option. In this case this is a documentation issue, since the kernel help explaining this "KVM: Mitigation: VMX disabled" text ( https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/multihit.html ) is written like no mitigation would actively disable it, suggesting "VMX disabled" is only meant to show when the BIOS/UEFI turned it off. So the help page should then say what may mess with VMX on a kernel level beyond BIOS/UEFI. Option B: VMX is actually enabled, and the iTLB mitigation is set to "Split huge pages" (this would as far as I can tell be the "correct" option for this system). In this case, there seems to be some mostly benign iTLB info output bug. Option C: VMS is actually enabled, and the iTLB mitigation is NOT active and the device is vulnerable. This potential outcome is why I marked this as SECURITY ISSUE until it can be ruled out, since if that is true then lscpu clearly tells me I'm safe while I'm actually not. So this outcome could trick admins into making expensive hardening missteps. Option D: Maybe I'm just not smart enough to use my BIOS/UEFI, lol, or I misunderstand VMX/VT-x fundamentally. I'm not a kernel developer, after all. Vaguely related, this server fault post suggests this may also happen on many distributions: https://serverfault.com/questions/1073247/if-kvm-is-working-why-does-vmx-sho... (Not entirely sure though if it's the same cause) First seen with Fedora's 5.13.15-200.fc34.x86_64, still present with OpenSUSE slowroll's 6.5.9-1-default. Steps to reproduce: 1. Boot an Intel Skylake computer with Fedora installed. Ensure all virtualization features are enabled in the UEFI/BIOS options. 2. Once Linux has booted, change /etc/default/grub to add in "mitigations=auto,nosmt mds=full,nosmt" and update your generated grub2 files, and reboot. 3. Once inside Linux again, check "lscpu" output and /sys/devices/system/cpu/vulnerabilities/itlb_multihit output. Expected output would be something else than "VMX disabled". -- You are receiving this mail because: You are the assignee for the bug.