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]
Date: Tue, 2 Apr 2024 16:00:03 -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 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.

Thanks, Ashish


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ