linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Dave Young <dyoung@redhat.com>
Cc: tglx@linutronix.de, mingo@redhat.com,
	dave.hansen@linux.intel.com, rafael@kernel.org,
	peterz@infradead.org, adrian.hunter@intel.com,
	sathyanarayanan.kuppuswamy@linux.intel.com,
	elena.reshetova@intel.com, jun.nakajima@intel.com,
	rick.p.edgecombe@intel.com, thomas.lendacky@amd.com,
	seanjc@google.com, michael.roth@amd.com, kai.huang@intel.com,
	bhe@redhat.com, kexec@lists.infradead.org,
	linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org,
	kirill.shutemov@linux.intel.com, bdas@redhat.com,
	vkuznets@redhat.com, dionnaglaze@google.com, anisinha@redhat.com,
	jroedel@suse.de, Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH v2 1/3] efi/x86: skip efi_arch_mem_reserve() in case of kexec.
Date: Sun, 24 Mar 2024 17:32:43 -0500	[thread overview]
Message-ID: <6553627f-6b45-4555-81d6-69d12d2c068e@amd.com> (raw)
In-Reply-To: <ZfkNzyGl4J1ZxaGj@darkstar.users.ipa.redhat.com>

Hello,

On 3/18/2024 11:00 PM, Dave Young wrote:
> Hi,
>
> Added Ard in cc.
>
> On 03/18/24 at 07:02am, Ashish Kalra wrote:
>> From: Ashish Kalra <ashish.kalra@amd.com>
>>
>> For kexec use case, need to use and stick to the EFI memmap passed
>> from the first kernel via boot-params/setup data, hence,
>> skip efi_arch_mem_reserve() during kexec.
>>
>> Additionally during SNP guest kexec testing discovered that EFI memmap
>> is corrupted during chained kexec. kexec_enter_virtual_mode() during
>> late init will remap the efi_memmap physical pages allocated in
>> efi_arch_mem_reserve() via memboot & then subsequently cause random
>> EFI memmap corruption once memblock is freed/teared-down.
>>
>> Signed-off-by: Ashish Kalra <ashish.kalra@amd.com>
>> ---
>>   arch/x86/platform/efi/quirks.c | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
>> index f0cc00032751..d4562d074371 100644
>> --- a/arch/x86/platform/efi/quirks.c
>> +++ b/arch/x86/platform/efi/quirks.c
>> @@ -258,6 +258,16 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
>>   	int num_entries;
>>   	void *new;
>>   
>> +	/*
>> +	 * For kexec use case, we need to use the EFI memmap passed from the first
>> +	 * kernel via setup data, so we need to skip this.
>> +	 * Additionally kexec_enter_virtual_mode() during late init will remap
>> +	 * the efi_memmap physical pages allocated here via memboot & then
>> +	 * subsequently cause random EFI memmap corruption once memblock is freed.
> Can you elaborate a bit about the corruption, is it reproducible without
> SNP?

This is only reproducible on SNP.

This is the call-stack for the above function:

[    0.313377]  efi_arch_mem_reserve+0x64/0x220^M
[    0.314060]  ? memblock_add_range+0x2a0/0x2e0^M
[    0.314763]  efi_mem_reserve+0x36/0x60^M
[    0.315360]  efi_bgrt_init+0x17d/0x1a0^M
[    0.315959]  ? __pfx_acpi_parse_bgrt+0x10/0x10^M
[    0.316711]  acpi_parse_bgrt+0x12/0x20^M
[    0.317310]  acpi_table_parse+0x77/0xd0^M
[    0.317922]  acpi_boot_init+0x362/0x630^M
[    0.318535]  setup_arch+0xa4e/0xf90^M
[    0.319091]  start_kernel+0x68/0xa70^M
[    0.319664]  x86_64_start_reservations+0x1c/0x30^M
[    0.320431]  x86_64_start_kernel+0xbf/0x110^M
[    0.321099]  secondary_startup_64_no_verify+0x179/0x17b^M

This function efi_arch_mem_reserve() calls efi_memmap_alloc() which in 
turn calls __efi_memmap_alloc_early()  which does memblock_phys_alloc(), 
and later does efi_memmap_install() which does early_memremap() of the 
EFI memmap into this memblock allocated physical memory. So now EFI 
memmap gets re-mapped into the memblock allocated memory.

Later kexec_enter_virtual_mode() calls efi_memmap_init_late() which 
memremap()'s the EFI memmap into the above memblock allocated physical 
range.

Obviously, when memblocks are later freed during late init, this 
memblock allocated physical range will get freed and re-allocated which 
will eventually overwrite and corrupt the EFI memmap leading to 
subsequent kexec boot crash.

>> +	 */
>> +	if (efi_setup)
>> +		return;
>> +
> How about checking the md attribute instead of checking the efi_setup,
> personally I feel it a bit better, something like below:

I based the above on the following code checking for kexec boot:

void __init efi_enter_virtual_mode(void)
{
        ...

         if (efi_setup)
                 kexec_enter_virtual_mode();
         else
                 __efi_enter_virtual_mode();

But, i have tested with the code (you shared below) about checking the 
md attribute and it works, so i can resend my v2 patch based on this.

Thanks, Ashish

>
> diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
> index f0cc00032751..699332b075bb 100644
> --- a/arch/x86/platform/efi/quirks.c
> +++ b/arch/x86/platform/efi/quirks.c
> @@ -255,15 +255,24 @@ void __init efi_arch_mem_reserve(phys_addr_t addr, u64 size)
>   	struct efi_memory_map_data data = { 0 };
>   	struct efi_mem_range mr;
>   	efi_memory_desc_t md;
> -	int num_entries;
> +	int num_entries, ret;
>   	void *new;
>   
> -	if (efi_mem_desc_lookup(addr, &md) ||
> -	    md.type != EFI_BOOT_SERVICES_DATA) {
> +	ret = efi_mem_desc_lookup(addr, &md);
> +	if (ret) {
>   		pr_err("Failed to lookup EFI memory descriptor for %pa\n", &addr);
>   		return;
>   	}
>   
> +	if (md.type != EFI_BOOT_SERVICES_DATA) {
> +		pr_err("Skil reserving non EFI Boot Service Data memory for %pa\n", &addr);
> +		return;
> +	}
> +
> +	/* Kexec copied the efi memmap from the 1st kernel, thus skip the case. */
> +	if (md.attribute & EFI_MEMORY_RUNTIME)
> +		return;
> +
>   	if (addr + size > md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT)) {
>   		pr_err("Region spans EFI memory descriptors, %pa\n", &addr);
>   		return;
>
>

  reply	other threads:[~2024-03-24 22:32 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 21:24 [PATCHv8 00/17, CORRECTED] x86/tdx: Add kexec support Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 01/17] x86/acpi: Extract ACPI MADT wakeup code into a separate file Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 02/17] x86/apic: Mark acpi_mp_wake_* variables as __ro_after_init Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 03/17] cpu/hotplug: Add support for declaring CPU offlining not supported Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 04/17] cpu/hotplug, x86/acpi: Disable CPU offlining for ACPI MADT wakeup Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 05/17] x86/kexec: Keep CR4.MCE set during kexec for TDX guest Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 06/17] x86/mm: Make x86_platform.guest.enc_status_change_*() return errno Kirill A. Shutemov
2024-02-27 23:33   ` Huang, Kai
2024-02-27 21:24 ` [PATCHv8 07/17] x86/mm: Return correct level from lookup_address() if pte is none Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 08/17] x86/tdx: Account shared memory Kirill A. Shutemov
2024-02-27 23:12   ` Huang, Kai
2024-02-27 21:24 ` [PATCHv8 09/17] x86/mm: Adding callbacks to prepare encrypted memory for kexec Kirill A. Shutemov
2024-02-27 23:16   ` Huang, Kai
2024-02-27 21:24 ` [PATCHv8 10/17] x86/tdx: Convert shared memory back to private on kexec Kirill A. Shutemov
2024-02-27 23:30   ` Huang, Kai
2024-02-27 21:24 ` [PATCHv8 11/17] x86/mm: Make e820_end_ram_pfn() cover E820_TYPE_ACPI ranges Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 12/17] x86/acpi: Rename fields in acpi_madt_multiproc_wakeup structure Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 13/17] x86/acpi: Do not attempt to bring up secondary CPUs in kexec case Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 14/17] x86/smp: Add smp_ops.stop_this_cpu() callback Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 15/17] x86/mm: Introduce kernel_ident_mapping_free() Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 16/17] x86/acpi: Add support for CPU offlining for ACPI MADT wakeup method Kirill A. Shutemov
2024-02-27 21:24 ` [PATCHv8 17/17] ACPI: tables: Print MULTIPROC_WAKEUP when MADT is parsed Kirill A. Shutemov
2024-02-27 21:30   ` Kuppuswamy Sathyanarayanan
2024-02-27 22:08   ` Huang, Kai
2024-02-28 15:22     ` Kirill A. Shutemov
2024-02-28 21:19       ` Huang, Kai
2024-03-06 15:02 ` [PATCHv8 00/17, CORRECTED] x86/tdx: Add kexec support Kirill A. Shutemov
2024-03-07  6:57   ` Tao Liu
2024-03-18  7:02 ` [PATCH v2 0/3] x86/snp: " Ashish Kalra
2024-03-18  7:02   ` [PATCH v2 1/3] efi/x86: skip efi_arch_mem_reserve() in case of kexec Ashish Kalra
2024-03-19  4:00     ` Dave Young
2024-03-24 22:32       ` Kalra, Ashish [this message]
2024-03-18  7:02   ` [PATCH v2 2/3] x86/mm: Do not zap page table entries mapping unaccepted memory table during kdump Ashish Kalra
2024-03-21 14:58     ` Kirill A. Shutemov
2024-03-18  7:02   ` [PATCH v2 3/3] x86/snp: Convert shared memory back to private on kexec Ashish Kalra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6553627f-6b45-4555-81d6-69d12d2c068e@amd.com \
    --to=ashish.kalra@amd.com \
    --cc=adrian.hunter@intel.com \
    --cc=anisinha@redhat.com \
    --cc=ardb@kernel.org \
    --cc=bdas@redhat.com \
    --cc=bhe@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dionnaglaze@google.com \
    --cc=dyoung@redhat.com \
    --cc=elena.reshetova@intel.com \
    --cc=jroedel@suse.de \
    --cc=jun.nakajima@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=vkuznets@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).