From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.2251.1685050200944413262 for ; Thu, 25 May 2023 14:30:01 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=dx3mVFBB; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5E16D64B49 for ; Thu, 25 May 2023 21:30:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5FFDC4339B for ; Thu, 25 May 2023 21:29:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685050199; bh=f4tbIUChGfX9hryhu5F8kirBUshyNW7SX+7ftOTbMyI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dx3mVFBBXAawYGI9LVpVNqWFHqrZSO5o84NE6PP0IsxOuTvepPMGkQIIj8ZEKU+5r CDWxJR5zKWJi+GkWYMCn92aDddZocRN+EX6B2p14g9PSO5SxwVnEgy40GFccZl7PXS yTCDaa1RFp+/2yYZv18gansaLRzANrk5/1PlxCXYUrcJTdojA4vAM7pm5XHE+Qv1a2 4A8829hyvQlwpu7hwVuwirC+xRIo+t9C+7VQId24pzsJ+D1hl7uysxk1Ipa9XJNFXX Rq2Kg+fz6QouoL/Y/yOG1tyQYfcKq6nBrjG5QehMD0ce7pgVHzpfNy9/Mk5TeTX5Jp cOQ4rw/kNYPkw== Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2af316b4515so326231fa.1 for ; Thu, 25 May 2023 14:29:59 -0700 (PDT) X-Gm-Message-State: AC+VfDzy2clCYdvK7tPsqio/uloYcj8cw/IQWoKyG8cHDUgV4TcpDZu1 +pFee0ApGxEPuFpKn8DhHAGxnGULjFNJ6XMbS10= X-Google-Smtp-Source: ACHHUZ7weFVDD8XEDhz5fAjuNHiSR2sW9VYVCjgGBOjnACNW7KRkMBuEGC9I7YAhcU/tRSU7X7lpRkmjg+ubM4jskW4= X-Received: by 2002:a2e:b177:0:b0:2b0:2976:172d with SMTP id a23-20020a2eb177000000b002b02976172dmr1511497ljm.9.1685050197718; Thu, 25 May 2023 14:29:57 -0700 (PDT) MIME-Version: 1.0 References: <20230525143041.1172989-1-ardb@kernel.org> <20230525143041.1172989-8-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Thu, 25 May 2023 23:29:46 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC PATCH 07/10] MdeModulePkg/PeiCore: Apply restricted permissions in image loader To: Oliver Smith-Denny Cc: devel@edk2.groups.io, Ray Ni , Jiewen Yao , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny , Dandan Bi , Liming Gao , "Kinney, Michael D" , Leif Lindholm , Sunil V L , Andrei Warkentin Content-Type: text/plain; charset="UTF-8" On Thu, 25 May 2023 at 19:21, Oliver Smith-Denny wrote: > > On 5/25/2023 7:30 AM, Ard Biesheuvel wrote: > > Add a notification callback to the PEI core to grab a reference to the > > memory attributes PPI as soon as it is registered, and use it in the > > image loader to set restricted memory permissions after loading the > > image if the image was loaded into memory. > > > > There are two use cases for this: > > - when the DXE IPL loads the DXE core using the PEI image services, its > > mappings will be set according to the PE section permission attributes > > if the image was built with 4k section alignment; this means DXE core > > will never run with mappings that are both writable and executable. > > - when PEIMs are shadowed to memory, they will not only be mapped > > read-only, but any non-exec permissions will also be removed. (Note > > that this requires the component that installs PEI permanent memory to > > depex on the memory attributes PPI, to ensure that it is available to > > manage permissions on permanent memory before it is used to load > > images) > > > > With this logic in place *, there is no longer a need for system memory > > to be mapped with both write and execute permissions out of reset. > > Instead, all memory can be mapped with non-executable permissions by > > default, which means that the stack and other allocations used in PEI or > > early in DXE will no longer need to be mapped non-exec explicitly. > > > > * the DXE core will also need its own method for clearing non-exec > > permissions on memory ranges, but this is being addressed in a > > separate series. > > > > Signed-off-by: Ard Biesheuvel > > --- > > MdeModulePkg/Core/Pei/Image/Image.c | 160 ++++++++++++++++++++ > > MdeModulePkg/Core/Pei/PeiMain.h | 6 + > > MdeModulePkg/Core/Pei/PeiMain.inf | 1 + > > 3 files changed, 167 insertions(+) > > > > diff --git a/MdeModulePkg/Core/Pei/Image/Image.c b/MdeModulePkg/Core/Pei/Image/Image.c > > index cee9f09c6ea61e31..3a7de45014b8f772 100644 > > --- a/MdeModulePkg/Core/Pei/Image/Image.c > > +++ b/MdeModulePkg/Core/Pei/Image/Image.c > > @@ -18,6 +18,50 @@ EFI_PEI_PPI_DESCRIPTOR gPpiLoadFilePpiList = { > > &mPeiLoadImagePpi > > > > }; > > > > > > > > +/** > > > > + Provide a callback for when the memory attributes PPI is installed. > > > > + > > > > + @param PeiServices An indirect pointer to the EFI_PEI_SERVICES table > > > > + published by the PEI Foundation. > > > > + @param NotifyDescriptor The descriptor for the notification event. > > > > + @param Ppi Pointer to the PPI in question. > > > > + > > > > + @return Always success > > > > + > > > > +**/ > > > > +STATIC > > > > +EFI_STATUS > > > > +EFIAPI > > > > +MemoryAttributePpiNotifyCallback ( > > > > + IN EFI_PEI_SERVICES **PeiServices, > > > > + IN EFI_PEI_NOTIFY_DESCRIPTOR *NotifyDescriptor, > > > > + IN VOID *Ppi > > > > + ) > > > > +{ > > > > + PEI_CORE_INSTANCE *PrivateData; > > > > + > > > > + // > > > > + // Get PEI Core private data > > > > + // > > > > + PrivateData = PEI_CORE_INSTANCE_FROM_PS_THIS (PeiServices); > > > > + > > > > + // > > > > + // If there isn't a memory attribute PPI installed, use the one from > > > > + // notification > > > > + // > > > > + if (PrivateData->MemoryAttributePpi == NULL) { > > > > + PrivateData->MemoryAttributePpi = (EDKII_MEMORY_ATTRIBUTE_PPI *)Ppi; > > > > + } > > > > + > > > > + return EFI_SUCCESS; > > > > +} > > > > + > > > > +STATIC CONST EFI_PEI_NOTIFY_DESCRIPTOR mNotifyList = { > > > > + EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST, > > > > + &gEdkiiMemoryAttributePpiGuid, > > > > + MemoryAttributePpiNotifyCallback > > > > +}; > > > > + > > > > /** > > > > > > > > Support routine for the PE/COFF Loader that reads a buffer from a PE/COFF file. > > > > @@ -243,6 +287,106 @@ GetPeCoffImageFixLoadingAssignedAddress ( > > return Status; > > > > } > > > > > > > > +/** > > > > + Remap the memory region covering a loaded image so it can be executed. > > > > + > > > > + @param ImageContext Pointer to the image context structure that describes the > > > > + PE/COFF image that needs to be examined by this function. > > > > + @param FileType The FFS file type of the image > > > > + @param ImageAddress The start of the memory region covering the image > > > > + @param ImageSize The size of the memory region covering the image > > > > + > > > > + @retval EFI_SUCCESS The image is ready to be executed > > > > + @retval EFI_OUT_OF_RESOURCES Not enough memory available to update the memory > > > > + mapping > > > > + > > > > +**/ > > > > +STATIC > > > > +EFI_STATUS > > > > +RemapLoadedImageForExecution ( > > > > + IN CONST PE_COFF_LOADER_IMAGE_CONTEXT *ImageContext, > > > > + IN EFI_FV_FILETYPE FileType, > > > > + IN PHYSICAL_ADDRESS ImageAddress, > > > > + IN UINT64 ImageSize > > > > + ) > > > > +{ > > > > + PEI_CORE_INSTANCE *Private; > > > > + EFI_IMAGE_OPTIONAL_HEADER_PTR_UNION Hdr; > > > > + EFI_IMAGE_SECTION_HEADER *Section; > > > > + PHYSICAL_ADDRESS SectionAddress; > > > > + EFI_STATUS Status; > > > > + UINT64 Permissions; > > > > + UINTN Index; > > > > + > > > > + Private = PEI_CORE_INSTANCE_FROM_PS_THIS (GetPeiServicesTablePointer ()); > > > > + > > > > + if (Private->MemoryAttributePpi == NULL) { > > > > + return EFI_SUCCESS; > > We will have a gap here before the MemoryAttributePpi is installed, > obviously, when CpuPei is installed. Is the expectation that only > dependencies for CpuPei will be launched before and everything else > will have a dependency on CpuPei? > > Or, is it that shadowed PEIMs won't happen before CpuPei? I am curious > how big or small of a gap this really is. > There are two different cases to consider here: - First, there is the DxeIpl, which will rely on the PPI (via the image loader and directly) to map the DXE core and the NX stack. The DxeIpl will not proceed with that until all PEIMs are dispatched, so if the PPI is going to be exposed, it will be available by that time. - Then there are the shadowed PEIMs, and given that shadowed PEIMs implicitly depend on PEI permanent memory having been installed, the only requirement here is that, if the platform needs/wants this for shadowed PEIMs as well, the PEIM that installs the PEI permanent memory should depex on the PPI. > > > > + } > > > > + > > > > + // > > > > + // PEI phase executables must be able to execute in place from read-only NOR > > > > + // flash, and so they can be mapped read-only in their entirety. > > > > + // > > > > + if ((FileType == EFI_FV_FILETYPE_PEI_CORE) || > > > > + (FileType == EFI_FV_FILETYPE_PEIM) || > > > > + (FileType == EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER)) > > > > + { > > We are calling this from PEI Core, will we have more images of type > PEI Core? I understand if this is for completeness, but just making > sure I understand the flow. > PEI core itself may be shadowed as well, and will be mapped read-only as well if it is included here. -- Ard.