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: <aCI5B7Mz8mgP-V2o@google.com>
Date: Mon, 12 May 2025 11:08:07 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Jon Kohler <jon@...anix.com>
Cc: pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, 
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 03/18] KVM: x86: Add module parameter for Intel MBEC

On Thu, Mar 13, 2025, Jon Kohler wrote:
> Add 'enable_pt_guest_exec_control' module parameter to x86 code, with
> default value false.

...

> +bool __read_mostly enable_pt_guest_exec_control;
> +EXPORT_SYMBOL_GPL(enable_pt_guest_exec_control);
> +module_param(enable_pt_guest_exec_control, bool, 0444);

The default value of a parameter doesn't prevent userspace from enabled the param.
I.e. the instant this patch lands, userspace can enable enable_pt_guest_exec_control,
which means MBEC needs to be 100% functional before this can be exposed to userspace.

The right way to do this is to simply omit the module param until KVM is ready to
let userspace enable the feature.

All that said, I don't see any reason to add a module param for this.  *KVM* isn't
using MBEC, the guest is using MBEC.  And unless host userspace is being extremely
careless with VMX MSRs, exposing MBEC to the guest will require additional VMM
enabling and/or user opt-in.

KVM provides module params to control features that KVM is using, generally when
there is no sane alternative to tell KVM not to use a particular feature, i.e.
when there is way for the user to disable a feature for testing/debug purposes.

Furthermore, how this series keys off the module param throughout KVM is completely
wrong.  The *only* input that ultimately matters is the control bit in vmcs12.
Whether or not KVM allows that bit to be set could be controlled by a module param,
but KVM shouldn't be looking at the module param outside of that particular check.

TL;DR: advertising and enabling MBEC should come along when KVM allows the bit to
       be set in vmcs12.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ