Received: by 2002:a89:413:0:b0:1fd:dba5:e537 with SMTP id m19csp441076lqs; Thu, 13 Jun 2024 15:02:51 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWJ566XJawuLbVwqaYSwpEGmBu6kT0nwcHvMpt/oQxwRmysrfWfF7St4l71jME4k/PNIf1l9C1NP4sFC2BPjV8XPeEwn4DbHbvSQNE3iA== X-Google-Smtp-Source: AGHT+IFc5ckRDQormqBMm5v2WnbBkjnSuxkNZd4y6KD30kKZT/9kRmEFPSEjrpwcA4cNkJ/Uum+b X-Received: by 2002:a05:6e02:1389:b0:375:9362:6752 with SMTP id e9e14a558f8ab-375e0c58e4cmr11221035ab.0.1718316170892; Thu, 13 Jun 2024 15:02:50 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718316170; cv=pass; d=google.com; s=arc-20160816; b=dpglq0+y/OVbeoSTgN84TuY6WVHO/kf9FB/wA2Y+K/Z5NISCPGbz7lFwGyKKkQcQoS SoJrueNs9p2SExtBaFNqN6OkTyKcoHqRGCbhlaYvtaB9mswZQdlkkpsX7Q7+gsjazlcE dYfbff9XtfdoKB/AkfxAuwyeg6jXOzF52oIvHolFfog3vi/IYDvVl+7rLkDQl4TSkwLA /hf9PlX++wbMCKDRwcEuCt6dSQBy+8lODgME4A9b5wa0Q803gn/H+eet/eWn+T1yuOPF wzJ46rEIoHuyQsWJ6tIz/gKhdEiu8caCn49WGhM0yH61lbLX2vqXYlbRtEml5GmtJfcD EOXQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=IFl5Ad0MUiUGC+43DeIY0elRXhtLQdP4scO/5JcurfI=; fh=BzgGL3m75SDcTdntxjG9iG0jWVmIuwzV1ZmMcHLdEhs=; b=u/jvf5iLBL14ExlhyfhuK23UsoVB0GhUFHwllfdkmaLE4g6g/hOGIMFE9a0Pd3DJSF /y8suPlmDyilt9YGfT5eeW3z0OezzNADxcrt/cAn0U0rngEgGwJYbWuH+0NrDQI+BqE0 8h+DAjmM08mHivlaKyWyAS56rbs+1z9iUqICJCUfjpBEcWba2/pW+ZXqfla8bccxiW7m 8oQW/SoYATngR6vdBkigTY0SZyqjgI5D21nu54PPwoSnLHZYeh7WjY0uDdP4A83Jgefc moLdJ2ktMfpg8HnR/iaPipiKmZflcu0EK8zqAXhuH1n4nIDVxKrw+Cb41C+kj8O4L5U1 blYA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="c1/96HME"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-214046-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-214046-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id 41be03b00d2f7-6fedd4f3ea6si2126755a12.180.2024.06.13.15.02.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jun 2024 15:02:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-214046-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="c1/96HME"; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-214046-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-214046-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 79104285601 for ; Thu, 13 Jun 2024 22:02:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9B7BB14A4F8; Thu, 13 Jun 2024 22:02:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c1/96HME" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 985FF1369A1; Thu, 13 Jun 2024 22:02:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718316154; cv=none; b=gz4zZFgUaPoLrkJY7QFSfUMMJKE6kLPzu8Qj6/ShNQMvv1zoWixau4q/TKnQR73qACN4AJDW3TTIplQ+tu4IMxb5xw6J4D42RyouxQofCwAGjl1FdtVJsSNkLDeYuYAXGgBEm24eLYX8bbLJeNKfEtTPhXq9qYv+MxdcLFKUh7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718316154; c=relaxed/simple; bh=J6SgO+1w7jrwaSaaaWIqgKZRKOQa8blXxyttDPlg7FI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CoC/xPD5iHmhDecfc3ugrma2HnE+9CvowQM4LzPmFVijyuA6l2YcAhqe0LihK1iUHVgU9MwwO8YZRe344h2Rpa+/z3HKwZpgGRQVZ9TMuJre91w4gmYuRbqGl82TCl/SRZ8mn2wOnVzAy2f7WmbAVe9s/awan1F7y+o6df/1w8Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c1/96HME; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23F2FC4AF1C; Thu, 13 Jun 2024 22:02:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718316154; bh=J6SgO+1w7jrwaSaaaWIqgKZRKOQa8blXxyttDPlg7FI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=c1/96HMEu7XsnkdUyT+aApIPDv0Djo0wHSrz19JNCVrb356AC/umj0OXtTdYju4sU GdGf6c+bw/5FLeXfQoduvnDCwTsRN5rhAEqdMOeJxQ1QgYnpg5ufJJT3Pf+UJywLAO mV8qiYTTnXlTjgt+/pSm35gsokKmx/4tB8cOkJeX4awX7IKkSDgFaWbVKoXOCF+iKL ruvxJ0oMdzmHgLu6+yhcSVmCSrrrHbGwwzUXtjMGkyvOmS5zq5AQzqfCIokylKB+8K TuDx7Nyx5eCW/uCZSYdB+p2YTN/COqw5AGWyc+pJPEEyT1qUNPrplmEHvf/UbEarBe J3B2uVtGodiVA== Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-52ca342d6f3so1025295e87.2; Thu, 13 Jun 2024 15:02:34 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXpHBMFaO3Be0G61Hz3ImJeA0ekpk8rxfGtOK841nsu9mePMPUz/i9/GwXoCjHQhcMgh5IgNeI65bwWW8AmHDvFZRj428X1RiyJm/z4SDY6NVcstkgYh2Tuaf7YfT9n6m57/Ctz3zZ+ X-Gm-Message-State: AOJu0Yycq+lQjTyBI/oK3mRkll+0BT01FxXSRO4HGlp9GGe5qM9o/TRX ly2MQcGUBCo7l3x4IuiYF0lKnvonDIy/NBCyHqjcHd+hOlPftAkGANxDYsGMDI3UxUne1crygIq CFPCYM84qcigHCtb6LpeHGNTHuIs= X-Received: by 2002:a19:f703:0:b0:51b:214c:5239 with SMTP id 2adb3069b0e04-52ca6e9f465mr582618e87.62.1718316152378; Thu, 13 Jun 2024 15:02:32 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240612135638.298882-2-ardb+git@google.com> <16131a10-b473-41cc-a96e-d71a4d930353@amd.com> In-Reply-To: <16131a10-b473-41cc-a96e-d71a4d930353@amd.com> From: Ard Biesheuvel Date: Fri, 14 Jun 2024 00:02:20 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] x86/efi: Free EFI memory map only when installing a new one. To: "Kalra, Ashish" Cc: Ard Biesheuvel , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Dave Young , Mike Rapoport , Borislav Petkov , Dan Williams Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 13 Jun 2024 at 22:05, Kalra, Ashish wrote: > > Hello Ard, > > On 6/12/2024 8:56 AM, Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > > > The logic in __efi_memmap_init() is shared between two different > > execution flows: > > - mapping the EFI memory map early or late into the kernel VA space, so > > that its entries can be accessed; > > - cloning the EFI memory map in order to insert new entries that are > > created as a result of creating a memory reservation > > (efi_arch_mem_reserve()) > > > > In the former case, the underlying memory containing the kernel's view > > of the EFI memory map (which may be heavily modified by the kernel > > itself on x86) is not modified at all, and the only thing that changes > > is the virtual mapping of this memory, which is different between early > > and late boot. > > > > In the latter case, an entirely new allocation is created that carries = a > > new, updated version of the kernel's view of the EFI memory map. When > > installing this new version, the old version will no longer be > > referenced, and if the memory was allocated by the kernel, it will leak > > unless it gets freed. > > > > The logic that implements this freeing currently lives on the code path > > that is shared between these two use cases, but it should only apply to > > the latter. So move it to the correct spot. > > > > While at it, move __efi_memmap_free() into its only caller, and drop th= e > > dummy definition for non-x86 architectures, as that is no longer needed= . > > > > Cc: Ashish Kalra > > Cc: Dave Young > > Cc: Mike Rapoport > > Cc: Borislav Petkov > > Cc: Dan Williams > > Fixes: f0ef6523475f ("efi: Fix efi_memmap_alloc() leaks") > > Link: https://lore.kernel.org/all/36ad5079-4326-45ed-85f6-928ff76483d3@= amd.com > > Signed-off-by: Ard Biesheuvel > > --- > > v3: > > - don't move __efi_memmap_free() into what turned out not to be its onl= y > > caller > > - drop another CPP #define related to the dummy definition > > > > v2: > > - free old memory map only after installing the new one succeeded > > - move __efi_memmap_free() into its only caller > > - drop obsolete dummy declaration from generic code > > > > arch/x86/include/asm/efi.h | 1 - > > arch/x86/platform/efi/memmap.c | 12 +++++++++++- > > drivers/firmware/efi/memmap.c | 9 --------- > > 3 files changed, 11 insertions(+), 11 deletions(-) > > > > diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h > > index 1dc600fa3ba5..481096177500 100644 > > --- a/arch/x86/include/asm/efi.h > > +++ b/arch/x86/include/asm/efi.h > > @@ -401,7 +401,6 @@ extern int __init efi_memmap_alloc(unsigned int num= _entries, > > struct efi_memory_map_data *data); > > extern void __efi_memmap_free(u64 phys, unsigned long size, > > unsigned long flags); > > -#define __efi_memmap_free __efi_memmap_free > > > > extern int __init efi_memmap_install(struct efi_memory_map_data *data)= ; > > extern int __init efi_memmap_split_count(efi_memory_desc_t *md, > > diff --git a/arch/x86/platform/efi/memmap.c b/arch/x86/platform/efi/mem= map.c > > index 4ef20b49eb5e..6ed1935504b9 100644 > > --- a/arch/x86/platform/efi/memmap.c > > +++ b/arch/x86/platform/efi/memmap.c > > @@ -92,12 +92,22 @@ int __init efi_memmap_alloc(unsigned int num_entrie= s, > > */ > > int __init efi_memmap_install(struct efi_memory_map_data *data) > > { > > + unsigned long size =3D efi.memmap.desc_size * efi.memmap.nr_map; > > + unsigned long flags =3D efi.memmap.flags; > > + u64 phys =3D efi.memmap.phys_map; > > + int ret; > > + > > efi_memmap_unmap(); > > > > if (efi_enabled(EFI_PARAVIRT)) > > return 0; > > > > - return __efi_memmap_init(data); > > + ret =3D __efi_memmap_init(data); > > + if (ret) > > + return ret; > > + > > + __efi_memmap_free(phys, size, flags); > > + return 0; > > } > > > > /** > > diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memma= p.c > > index 3365944f7965..34109fd86c55 100644 > > --- a/drivers/firmware/efi/memmap.c > > +++ b/drivers/firmware/efi/memmap.c > > @@ -15,10 +15,6 @@ > > #include > > #include > > > > -#ifndef __efi_memmap_free > > -#define __efi_memmap_free(phys, size, flags) do { } while (0) > > -#endif > > - > > /** > > * __efi_memmap_init - Common code for mapping the EFI memory map > > * @data: EFI memory map data > > @@ -51,11 +47,6 @@ int __init __efi_memmap_init(struct efi_memory_map_d= ata *data) > > return -ENOMEM; > > } > > > > - if (efi.memmap.flags & (EFI_MEMMAP_MEMBLOCK | EFI_MEMMAP_SLAB)) > > - __efi_memmap_free(efi.memmap.phys_map, > > - efi.memmap.desc_size * efi.memmap.nr_ma= p, > > - efi.memmap.flags); > > - > > map.phys_map =3D data->phys_map; > > map.nr_map =3D data->size / data->desc_size; > > map.map_end =3D map.map + data->size; > > Tested this patch with SNP guest kexec and i do not observe EFI memory ma= p corruption with SNP guest kexec with this patch applied. > > Tested-by: Ashish Kalra > Thanks! > I have another question related to the discussion on the following email = thread: > > Re: [PATCH v7 1/3] efi/x86: Fix EFI memory map corruption with kexec - Da= ve Young (kernel.org) > > Do we still want to create another patch for skipping efi_arch_mem_reserv= e() when the EFI_MEMORY_RUNTIME bit was set already ? > If it is not needed, let's not bother.