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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ