linux-kernel - Re: [PATCH] kvm: x86: SRSO_USER_KERNEL

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] [day] [month] [year] [list]

Message-ID: <Z6JofqPQNkcfHFy1@google.com>
Date: Tue, 4 Feb 2025 11:20:30 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] kvm: x86: SRSO_USER_KERNEL_NO is not synthesized

On Tue, Feb 04, 2025, Paolo Bonzini wrote:
> SYNTHESIZED_F() generally is used together with setup_force_cpu_cap(),
> i.e. when it makes sense to present the feature even if cpuid does not
> have it *and* the VM is not able to see the difference.  For example,
> it can be used when mitigations on the host automatically protect
> the guest as well.
> 
> The "SYNTHESIZED_F(SRSO_USER_KERNEL_NO)" line came in as a conflict
> resolution between the CPUID overhaul from the KVM tree and support
> for the feature in the x86 tree.  Using it right now does not hurt,
> or make a difference for that matter, because there is no
> setup_force_cpu_cap(X86_FEATURE_SRSO_USER_KERNEL_NO).  However, it
> is a little less future proof in case such a setup_force_cpu_cap()
> appears later, for a case where the kernel somehow is not vulnerable
> but the guest would have to apply the mitigation.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
> ---

Reviewed-by: Sean Christopherson <seanjc@...gle.com>