linux-kernel - Re: [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups for kexec.

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: <Zzfst1FwR/DJqtGg@kernel.org>
Date: Fri, 15 Nov 2024 16:52:07 -0800
From: Mike Rapoport <rppt@...nel.org>
To: "Kalra, Ashish" <ashish.kalra@....com>
Cc: Borislav Petkov <bp@...en8.de>, thomas.lendacky@....com,
	michael.roth@....com, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] x86/sev: Add callback to apply RMP table fixups
 for kexec.

Hi,

(sorry for jumping really late, I've just found this accidentally)

On Fri, Apr 26, 2024 at 09:56:25AM -0500, Kalra, Ashish wrote:
> On 4/26/2024 7:58 AM, Borislav Petkov wrote:
> 
> > On Wed, Apr 24, 2024 at 06:48:08PM -0500, Kalra, Ashish wrote:
> > > This callback needs to be invoked as part of setup_arch() as it needs e820
> > > table to be setup in e820__memory_setup() before the callback is invoked and
> > > snp_init() is called from sme_enable() in kernel/head_64.S (startup_64),
> > > which is much before start_kernel() -> setup_arch() is invoked.
> > So?
> > 
> > snp_init() still runs before e820__memory_setup(). So what's stopping
> > you?
> 
> As i have already explained above, snp_init() runs before
> e820__memory_setup() so we can't invoke this callback in snp_init() as e820
> tables have still not been setup. Again to summarize, the e820 tables are
> setup in e820__memory_setup() which runs after snp_init().

I agree that snp_fixup_e820_tables() should run after e820__memory_setup(),
but I wonder if it's ok for it to run *after* e820__memblock_setup().

At the very least making changes to e820 table after they were translated
to memblock creates inconsistency between the e820 and core mm views of the
memory. 

So I wonder what would happen if the memory from the problematic chunk was
allocated by kernel rather than by kexec? Couldn't it cause RMP fault?

-  
Sincerely yours,
Mike.