linux-kernel - Re: question about 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: <8170fb75-821d-46fb-80e4-c7bd5635d65c@amd.com>
Date: Mon, 16 Sep 2024 13:39:07 -0500
From: "Kalra, Ashish" <ashish.kalra@....com>
To: Dave Young <dyoung@...hat.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kexec@...ts.infradead.org
Subject: Re: question about RMP table fixups for kexec

Hi Dave,

On 9/14/2024 6:08 AM, Dave Young wrote:
> Hi Ashish,
>
> I'm reading the code about E820 tables related code,  I noticed with
> below commit you updated all three e820 tabes including
> e820_table_kexec and e820_table_firmware.
> commit 400fea4b9651adf5d7ebd5d71e905f34f4e4e493
> Author: Ashish Kalra <ashish.kalra@....com>
> Date:   Fri Apr 26 00:43:18 2024 +0000
>
>     x86/sev: Add callback to apply RMP table fixups for kexec
>
> ...
>
> +       if (e820__mapped_any(pa, pa + PMD_SIZE, E820_TYPE_RAM)) {
> +               pr_info("Reserving start/end of RMP table on a 2MB
> boundary [0x%016llx]\n", pa);
> +               e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM,
> E820_TYPE_RESERVED);
> +               e820__range_update_table(e820_table_kexec, pa,
> PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +               e820__range_update_table(e820_table_firmware, pa,
> PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
> +       }
> +}
>
> A question here is, have you tried only updating e820_table and
> e820_table_firmware?
>
> I do not know much about SEV,  if you update e820_table, then the
> memory range will be reserved in resouces, and kexec will not load
> segments into the reserved ranges,  during the 2nd kernel bootup  your
> code will be run again so I assume it is not necessary to pre-reserve
> in e820_table_kexec and passing to 2nd kernel.
>
> Could you confirm this question?

Yes, that is true but e820_table_kexec is passed on to the incoming kexec kernel as part of the boot params, so that will be the initial e820 memory map for the incoming kernel and to be safe we also modify the e820_table_kexec.

We have already observed memblock allocating memory from the initial e820 map before the above fixups modifies e820 tables for the 1st kernel and then this memblock memory getting allocated to guest and causing RMPUPDATE issues, as from the issue reported and fixed below:

[PATCH] x86/sev: ensure that RMP table fixups are reserved for memblock - Ashish Kalra (kernel.org) <https://lore.kernel.org/lkml/20240815221630.131133-1-Ashish.Kalra@amd.com/>

Therefore, it should be safer to have the initial e820 memory map being passed to the incoming/2nd kernel already have the fixups in it.

Thanks, Ashish