linux-kernel - Re: [PATCH v7 1/3] efi/x86: Fix EFI memory map corruption with 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]

Message-ID: <CALu+AoQ2jNjb+5MZfFtpT_Y=2gJRWwqEeWTpQkwNt0-U5fpO_w@mail.gmail.com>
Date: Wed, 5 Jun 2024 10:28:18 +0800
From: Dave Young <dyoung@...hat.com>
To: "Kalra, Ashish" <ashish.kalra@....com>
Cc: Borislav Petkov <bp@...en8.de>, Mike Rapoport <rppt@...nel.org>, tglx@...utronix.de, mingo@...hat.com, 
	dave.hansen@...ux.intel.com, x86@...nel.org, rafael@...nel.org, hpa@...or.com, 
	peterz@...radead.org, adrian.hunter@...el.com, 
	sathyanarayanan.kuppuswamy@...ux.intel.com, jun.nakajima@...el.com, 
	rick.p.edgecombe@...el.com, thomas.lendacky@....com, michael.roth@....com, 
	seanjc@...gle.com, kai.huang@...el.com, bhe@...hat.com, 
	kirill.shutemov@...ux.intel.com, bdas@...hat.com, vkuznets@...hat.com, 
	dionnaglaze@...gle.com, anisinha@...hat.com, jroedel@...e.de, ardb@...nel.org, 
	kexec@...ts.infradead.org, linux-coco@...ts.linux.dev, 
	linux-kernel@...r.kernel.org, dan.j.williams@...el.com
Subject: Re: [PATCH v7 1/3] efi/x86: Fix EFI memory map corruption with kexec

On Wed, 5 Jun 2024 at 10:09, Kalra, Ashish <ashish.kalra@....com> wrote:
>
> Hello Dave,
>
> On 6/4/2024 8:58 PM, Dave Young wrote:
> > On Wed, 5 Jun 2024 at 09:52, Dave Young <dyoung@...hat.com> wrote:
> >>>>         ...
> >>>>         if (efi.memmap.flags & (EFI_MEMMAP_MEMBLOCK | EFI_MEMMAP_SLAB)) {
> >>>>                 __efi_memmap_free(efi.memmap.phys_map,
> >>>>                                 efi.memmap.desc_size * efi.memmap.nr_map, efi.memmap.flags);
> >>>>         }
> >>> From your debugging the memmap should not be freed.  This piece of
> >>> code was added in below commit,  added Dan Williams in cc list:
> >>> commit f0ef6523475f18ccd213e22ee593dfd131a2c5ea
> >>> Author: Dan Williams <dan.j.williams@...el.com>
> >>> Date:   Mon Jan 13 18:22:44 2020 +0100
> >>>
> >>>     efi: Fix efi_memmap_alloc() leaks
> >>>
> >>>     With efi_fake_memmap() and efi_arch_mem_reserve() the efi table may be
> >>>     updated and replaced multiple times. When that happens a previous
> >>>     dynamically allocated efi memory map can be garbage collected. Use the
> >>>     new EFI_MEMMAP_{SLAB,MEMBLOCK} flags to detect when a dynamically
> >>>     allocated memory map is being replaced.
> >>>
> >> Dan, probably those regions should be freed only for "fake" memmap?
> > Ashish, can you comment out the __efi_memmap_free see if it works for
> > you just confirm about the behavior.
>
> Yes, i have already tried and tested that, if i avoid __efi_memmap_free(), then i don't see this memory map corruption.

Ok, thanks!  I think the right way is creating two patches,  one to
remove the __efi_memmap_free, another is  skip efi_arch_mem_reserve
when the EFI_MEMORY_RUNTIME bit was set already.  But the first one
should be the fix for the root cause.

efi fake mem is only for debugging purposes,  the "memleak" mentioned
in commit 0f96a99dab36 should be solved in another way if needed (are
they really leaked? or just not useful anymore)

Anyway this is my opinion, please wait for x86 and efi reviewer's inputs.

>
> Thanks, Ashish
>