linux-kernel - Re: [PATCH] x86/bugs/multihit: Fix mitigation reporting when KVM is not in use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Jul 2020 07:57:53 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Tony Luck <tony.luck@...el.com>,
        "Gomez Iglesias, Antonio" <antonio.gomez.iglesias@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Anthony Steinhauser <asteinhauser@...gle.com>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Waiman Long <longman@...hat.com>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] x86/bugs/multihit: Fix mitigation reporting when KVM is
 not in use

On 7/13/20 6:45 PM, Sean Christopherson wrote:
> This is all kinds of backwards.  Virtualization being disabled in hardware
> is very, very different than KVM not being loaded.  One requires at the
> very least a kernel reboot to change, the other does not.

That's a very good point.

It's a pretty slippery slope if we go trying to figure out at runtime
what our vulnerabilities are.  We could, for instance, claim that we're
not vulnerable to Meltdown until we run non-root code, or something else
equally silly.

Let's stick to things which are at least static per reboot.  Checking
for X86_FEATURE_VMX or even CONFIG_KVM_INTEL seems like a good stopping
point.  "Could this kernel run a naughty guest?"  If so, report
"Vulnerable".  It's the same as Meltdown: "Could this kernel run
untrusted code?"  If so, report "Vulnerable".

I don't think we should care about random kernel modules flipping CR4
bits.  They can do much more harm than expose a system to an issue like
this.  If we care about reporting mitigation status once that happens,
maybe out-of-tree modules loads should just flip *all* these cpu bugs
from Mitigated->Vulerable. :)