linux-kernel - Re: [PATCH v2] KVM: VMX: Enable Notify VM exit

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: <YTD7+v2t0dSZqVHF@google.com>
Date:   Thu, 2 Sep 2021 16:29:46 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Chenyi Qiang <chenyi.qiang@...el.com>
Cc:     Xiaoyao Li <xiaoyao.li@...el.com>, Tao Xu <tao3.xu@...el.com>,
        pbonzini@...hat.com, vkuznets@...hat.com, wanpengli@...cent.com,
        jmattson@...gle.com, joro@...tes.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, hpa@...or.com, x86@...nel.org,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] KVM: VMX: Enable Notify VM exit

On Thu, Sep 02, 2021, Chenyi Qiang wrote:
> On 8/3/2021 8:38 AM, Xiaoyao Li wrote:
> > On 8/2/2021 11:46 PM, Sean Christopherson wrote:
> > > IIRC, SGX instructions have a hard upper bound of 25k cycles before they
> > > have to check for pending interrupts, e.g. it's why EINIT is
> > > interruptible.  The 25k cycle limit is likely a good starting point for
> > > the combined minimum.  That's why I want to know the internal minimum; if
> > > the internal minimum is _guaranteed_ to be >25k, then KVM can be more
> > > aggressive with its default value.
> > 
> > OK. I will go internally to see if we can publish the internal threshold.
> > 
> 
> Hi Sean,
> 
> After syncing internally, we know that the internal threshold is not
> architectural but a model-specific value. It will be published in some place
> in future.

Any chance it will also be discoverable, e.g. via an MSR?  That would be ideal
as we could give the module param an "auto" mode where the combined threshold is
set to a minimum KVM-defined value, e.g.

	static int __read_mostly notify_window = -1;
	module_param(notify_window, int, 444);

	...

	rdmsrl_safe(MSR_NOTIFY_WINDOW_BUFFER, &buffer);
	if (notify_window == -1) {
		if (buffer < KVM_DEFAULT_NOTIFY_WINDOW)
			notify_window = 0;
		else
			notifiy_window = KVM_DEFAULT_NOTIFY_WINDOW - buffer;
	}
		
> On Sapphire Rapids platform, the threshold is 128k. With this in mind, is it
> appropriate to set 0 as the default value of notify_window?

Maybe?  That's still not a guarantee that _future_ CPUs will have an internal
threshold >25k.

On a related topic, this needs tests.  One thought would be to stop unconditionally
intercepting #AC if NOTIFY_WINDOW is enabled, and then have the test set up the
infinite #AC vectoring scenario.