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: 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:31:30 -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:20 PM, Borislav Petkov wrote:
> On Tue, Apr 02, 2024 at 04:00:03PM -0500, Kalra, Ashish wrote:
>> 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.
> And?
>
> You can't change it later? Tried?
The main issue is there is no API interface available to do that, i will 
need to add new API interfaces to update the e820_table_kexec and 
e820_table_firmware and then will that be acceptable for a use case 
which can be handled via a platform specific quirk ?
>> 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 what was this "RMP table start and end physical range may not be
> aligned to 2MB" in your commit message?
> /me is completely confused now.
>
> Or does "most cases" mean that there can be cases where the RMP table
> placement in the BIOS is not 2M aligned and then the kexec kernel could
> try to allocate from within that chunk and there's RMP faults?

Yes exactly, that's what the above comment means.

  That's why the above commit message says "may".

>
> And you want to allocate those chunks up to the 2M boundary
> unconditionally, regardless of SNP enablement?

My point is that we always keep the RMP table memory reserved regardless 
of SNP enablement, so these are simply fixups/adjustments on top of that 
reservation.

Thanks, Ashish

> Now look at your original commit message and tell me how much of what
> came out on this thread, was in it?
>
> Not a lot, I'd say...
>