linux-kernel - Re: [PATCH v2 02/18] x86/reboot: Expose VMCS crash hooks if and only if KVM

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]

Message-ID: <a0c9ce4bbd625ede0b566990dc497000d6d303e7.camel@intel.com>
Date:   Tue, 14 Mar 2023 01:19:51 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "Christopherson,, Sean" <seanjc@...gle.com>
CC:     "Gao, Chao" <chao.gao@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "bp@...en8.de" <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 02/18] x86/reboot: Expose VMCS crash hooks if and only
 if KVM_INTEL is enabled


> 
> > But I am not sure whether we want to do this (having CONFIG_KVM_INTEL around the
> > relevant code).  In later patches, you mentioned the case of out-of-tree
> > hypervisor, for instance, below in the changelog of patch 04:
> > 
> > 	There's no need to attempt VMXOFF if KVM (or some other out-of-treeï¿½
> > 	hypervisor) isn't loaded/active...
> > 
> > This means we want to do handle VMCLEAR+VMXOFF in case of out-of-tree hypervisor
> > too.  So, shouldn't the hooks always exist but not only available when KVM_INTEL
> > or KVM_AMD is on, so the out-of-tree hypervisor can register their callbacks?
> 
> Ah, I see how I confused things with that statement.  My intent was only to call
> out that, technically, a non-NULL callback doesn't mean KVM is loaded.  I didn't
> intend to sign the kernel up for going out of its way to support out-of-tree hypervisors.

I interpret this as:

Kernel doesn't officially support the out-of-tree hypervisor, but it provides a
callback which the out-of-tree hypervisor can utilize to handle emergency virt
disable.  But such callback is only available when KVM is turned on in the
Kconfig.

?

> 
> Does it read better if I add a "that piggybacked the callback" qualifier?
> 
>   There's no need to attempt VMXOFF if KVM (or some other out-of-tree hypervisor
>   that piggybacked the callback) isn't loaded/active, i.e. if the CPU can't
>   possibly be post-VMXON. 

I think so?

But overall I just think having to consider out-of-tree hypervisor (we are
talking about a loadable module, right) only makes thing more confusing.  I
guess we can either:

1) Don't mention out-of-tree hypervisor at all.  This means kernel doesn't
officially provide mechanisms to support out-of-tree hyperivisor (a module).  If
someone wants to do that, then someone takes the risk.

2) The kernel officially provide the callback to handle emergency virt disable
for out-of-tree hypervisor (module) to use.  But this callback should be
available when KVM is off.

?