linux-kernel - Re: [PATCH v2 11/49] KVM: x86: Disallow KVM_CAP_X86_DISABLE

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: <ZoxBV6Ihub8eaVAy@google.com>
Date: Mon, 8 Jul 2024 19:43:19 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Maxim Levitsky <mlevitsk@...hat.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Vitaly Kuznetsov <vkuznets@...hat.com>, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Hou Wenlong <houwenlong.hwl@...group.com>, 
	Kechen Lu <kechenl@...dia.com>, Oliver Upton <oliver.upton@...ux.dev>, 
	Binbin Wu <binbin.wu@...ux.intel.com>, Yang Weijiang <weijiang.yang@...el.com>, 
	Robert Hoo <robert.hoo.linux@...il.com>
Subject: Re: [PATCH v2 11/49] KVM: x86: Disallow KVM_CAP_X86_DISABLE_EXITS
 after vCPU creation

On Thu, Jul 04, 2024, Maxim Levitsky wrote:
> On Fri, 2024-05-17 at 10:38 -0700, Sean Christopherson wrote:
> > Reject KVM_CAP_X86_DISABLE_EXITS if vCPUs have been created, as disabling
> > PAUSE/MWAIT/HLT exits after vCPUs have been created is broken and useless,
> > e.g. except for PAUSE on SVM, the relevant intercepts aren't updated after
> > vCPU creation.  vCPUs may also end up with an inconsistent configuration
> > if exits are disabled between creation of multiple vCPUs.
> 
> Hi,
> 
> I am not sure that PAUSE intercepts are updated either, I wasn't able to find a code
> that does this.
> 
> I agree with this change, but note that there was some talk on the mailing
> list to allow to selectively disable VM exits (e.g PAUSE, MWAIT, ...) only on
> some vCPUs, based on the claim that some vCPUs might run RT tasks, while some
> might be housekeeping.  I haven't followed those discussions closely.

This change is actually pulled from that series[*].  IIRC, v1 of that series
didn't close the VM-scoped hole, and the overall code was much more complex as
a result.

[*] https://lore.kernel.org/all/20230121020738.2973-2-kechenl@nvidia.com