[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250913153821.GCaMWP7THDz6sL26bD@fat_crate.local>
Date: Sat, 13 Sep 2025 17:38:21 +0200
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: Michael Roth <michael.roth@....com>, linux-kernel@...r.kernel.org,
x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>, stable@...nel.org
Subject: Re: [PATCH] x86/sev: Guard sev_evict_cache() with
CONFIG_AMD_MEM_ENCRYPT
On Sat, Sep 13, 2025 at 09:29:47AM -0500, Tom Lendacky wrote:
> On 9/12/25 16:02, Borislav Petkov wrote:
> > On Fri, Sep 12, 2025 at 03:49:29PM -0500, Michael Roth wrote:
> >> I think that's actually the concerning thing. If someone built a guest
> >> kernel with CONFIG_KVM_AMD_SEV=y they might be under the impression that
> >> this is performing evictions when it's actually just a stub function.
> >
> > That sooo needs to be in the commit message...
>
> I can send a v2 or if you want to modify the commit message with the
> following:
>
> The sev_evict_cache() is guest-related code and should be guarded by
> CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV.
>
> CONFIG_AMD_MEM_ENCRYPT=y is required for a guest to run properly as an
> SEV-SNP guest, but a guest kernel built with CONFIG_KVM_AMD_SEV=n would
> get the stub function of sev_evict_cache() instead of the version that
> performs the actual eviction. Move the function declarations under the
> appropriate #ifdef.
>
> Let me know.
Right, I had fixed it up locally already like this:
The sev_evict_cache() is guest-related code and should be guarded by
CONFIG_AMD_MEM_ENCRYPT, not CONFIG_KVM_AMD_SEV. Move the function
declarations under the appropriate #ifdef otherwise a guest kernel built
with CONFIG_KVM_AMD_SEV=n won't be doing proper evicting.
but you can send me your version on Monday.
When you do, can you pls rebase it ontop of -rc6 which Linus would have
released by then because this one needs to go up now and doesn't need to be
based ontop of tip/master and be against the x86/sev changes there.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists