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

Message-ID: <b582295c-6199-4eb2-a10c-4ee703b10f4d@amd.com>
Date: Fri, 15 Nov 2024 19:11:57 -0600
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Mike Rapoport <rppt@...nel.org>
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.

On 11/15/2024 6:52 PM, Mike Rapoport wrote:
> 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?
> 

Yes, we discovered an issue with SNP guests when trying to use one of 
these pages and there was a fix pushed and merged to ensure that RMP
table fixups are (also) reserved for memblock.

Here is a detailed description from the patch: 

The RMP table fixups are done after the e820 ranges have been added to
memblock, allowing the fixup ranges to still be allocated and used by
the system. The problem is that this memory range is now marked reserved
in the e820 tables and during SNP initialization these reserved ranges
are made HV-Fixed. This means that the pages cannot be used by an SNP
guest, only by the hypervisor. However, the memory management subsystem
does not make this distinction and can allocate one of those pages to an
SNP guest. This will ultimately result in RMPUPDATE failures associated
with the guest, causing it to fail to start or terminate when accessing
the HV-Fixed page.

Link to the patch: 
https://lore.kernel.org/lkml/20240815221630.131133-1-Ashish.Kalra@amd.com/

Thanks,
Ashish

> -  
> Sincerely yours,
> Mike.