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 12:11:03 -0500
From: "Kalra, Ashish" <ashish.kalra@....com>
To: bp@...nel.org, thomas.lendacky@....com
Cc: bp@...en8.de, 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 12:06 PM, Kalra, Ashish wrote:
> On 4/2/2024 11:34 AM, bp@...nel.org wrote:
>
>> From: Borislav Petkov <bp@...en8.de>
>>
>> On Tue, Apr 02, 2024 at 10:54:50AM -0500, Tom Lendacky wrote:
>>> There's no requirement from a hardware/RMP usage perspective that 
>>> requires a
>>> 2MB alignment, so BIOS is not doing anything wrong. The problem occurs
>>> because kexec is initially using 2MB mappings that overlap the start 
>>> and/or
>>> end of the RMP which then results in an RMP fault when memory within 
>>> one of
>>> those 2MB mappings, that is not part of the RMP, is referenced.
>> Then this explanation is misleading. And that whole bla about alignment
>> is nonsense either.
>>
>>> Additionally, we have BIOSes out there since Milan that don't do 
>>> this 2MB
>>> alignment. And do you really trust that BIOS will do this properly 
>>> all the
>>> time?
>> I don't trust the BIOS to do anything properly.
>>
>> So why isn't the fix for this simply to reserve the space for the RMP
>> table to start at 2M page - even if it doesn't - and to cover the last
>> chunk *also* with a 2M page and be done with it?
>
> But, it is the BIOS which reserves the space for the RMP table.
>
> And if you mean the reservation in the kernel page tables (directmap) 
> then that will not help as kexec uses it's own identity mapped page 
> tables.
>
>>
>> Not this silly overriding dance.
>
> This overriding dance is required to fixup all the three kexec tables, 
> as there is no interface/API available to do modifications/fixups in 
> all the three possible kexec tables.
>
I meant the three e820 tables out of which two are used for kexec, the 
e820_table_firmware and e820_table_kexec.

Thanks, Ashish

>
>> Thx.
>>