linux-kernel - Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR

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: <20241216173142.GDZ2Bj_uPBG3TTPYd_@fat_crate.local>
Date: Mon, 16 Dec 2024 18:31:42 +0100
From: Borislav Petkov <bp@...en8.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Borislav Petkov <bp@...nel.org>, X86 ML <x86@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	KVM <kvm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] x86/bugs: KVM: Add support for SRSO_MSR_FIX

On Wed, Dec 11, 2024 at 02:27:42PM -0800, Sean Christopherson wrote:
> How much cost are we talking?

Likely 1-2%.

That's why I'm simply enabling it by default.

> IIUC, this magic bit reduces how much the CPU is allowed to speculate in order
> to mitigate potential VM=>host attacks, and that reducing speculation also reduces
> overall performance.
> 
> If that's correct, then enabling the magic bit needs to be gated by an appropriate
> mitagation being enabled, not forced on automatically just because the CPU supports
> X86_FEATURE_SRSO_MSR_FIX.

Well, in  the default case we have safe-RET - the default - but since it is
not needed anymore, it falls back to this thing which is needed when the
mitigation is enabled.

That's why it also is in the SRSO_CMD_IBPB_ON_VMEXIT case as it is part of the
spec_rstack_overflow=ibpb-vmexit mitigation option.

So it kinda already does that. When you disable the mitigation, this one won't
get enabled either.

> And depending on the cost, it might also make sense to set the bit on-demand, and
> then clean up when KVM disables virtualization.  E.g. wait to set the bit until
> entry to a guest is imminent.

So the "when to set that bit" discussion kinda remained unfinished the last
time. Here's gist:

You:

| "It's not strictly KVM module load, it's when KVM enables virtualization.  E.g.
| if userspace clears enable_virt_at_load, the MSR will be toggled every time the
| number of VMs goes from 0=>1 and 1=>0.
| 
| But why do this in KVM?  E.g. why not set-and-forget in init_amd_zen4()?"

I:

| "Because there's no need to impose an unnecessary - albeit small - perf impact
| on users who don't do virt.
| 
| I'm currently gravitating towards the MSR toggling thing, i.e., only when the
| VMs number goes 0=>1 but I'm not sure. If udev rules *always* load kvm.ko then
| yes, the toggling thing sounds better. I.e., set it only when really needed."

So to answer your current question, it sounds like the user can control the
on-demand thing with enable_virt_at_load=0, right?

Or do you mean something else different?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette