linux-kernel - Re: [PATCH] x86/sev: 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e15ccf9-1461-44b0-bc26-ede086bc4f25@amd.com>
Date: Tue, 2 Apr 2024 16:17:23 -0500
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: bp@...nel.org, thomas.lendacky@....com, linux-kernel@...r.kernel.org,
 linux-tip-commits@...r.kernel.org, michael.roth@....com, x86@...nel.org
Subject: Re: [PATCH] x86/sev: Apply RMP table fixups for kexec.


On 4/2/2024 4:00 PM, Kalra, Ashish wrote:
>
> On 4/2/2024 3:21 PM, Borislav Petkov wrote:
>> On Tue, Apr 02, 2024 at 02:33:44PM -0500, Kalra, Ashish wrote:
>>> And we can't do this in snp_rmptable_init() as e820_table_firmware 
>>> can't be
>>> fixed at that point and by that time this table has been mapped into 
>>> sysfs
>>> (/sys/firmware) which is used by kexec -c variant.
>> Well, you have to do something here because if snp_rmptable_init()
>> late-disables SNP, your RMP table fixups are moot and invalid.
>>
>> Which means, your RMP table fixups need to happen at the *very* *late*
>> step after we know that SNP is enabled and won't get disabled anymore.
>>
>> I.e., in snp_rmptable_init().
>
> The main issue with doing that in snp_rmptable_init() is that there is 
> no e820 API interfaces available to update the e820_table_kexec and 
> e820_table_firmware and e820_table_firmware has already been exposed 
> to sysfs.
>
> The e820 API only exports e820__range_update() which *only* fixes 
> e820_table.
>
> The important point to note here is that in most cases BIOS would have 
> reserved RMP table start and end aligned to 2M boundary and setup the 
> e820 table which the BIOS passes to the kernel as such, so even if the 
> kernel does not enable SNP or disables SNP later, these reservations 
> will remain aligned as such. So what we are doing here in-kernel 
> fixups is doing the same alignment fixups which the BIOS would have 
> done. The summary here is that e820 table adjustments for RMP table 
> done either by BIOS and/or kernel will exist/remain even if SNP is not 
> enabled by the kernel.
>
Again, to reiterate here, RMP table memory is reserved by BIOS 
regardless of the kernel enabling SNP (and also passed on the e820 map 
to ensure that kernel does not map anything in that memory), so any 
adjustments/fixups on top of that reserved memory should not matter, 
after all we don't free this reserved RMP table memory if kernel does 
not enable SNP.

Thanks, Ashish