From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web10.33662.1685631222122383060 for ; Thu, 01 Jun 2023 07:53:42 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=jhCSCOTN; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: osde@linux.microsoft.com) Received: from [10.137.194.171] (unknown [131.107.1.171]) by linux.microsoft.com (Postfix) with ESMTPSA id 8CD5A20FC4F8; Thu, 1 Jun 2023 07:53:41 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8CD5A20FC4F8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1685631221; bh=2yYpmHTk2Gx3q/1YxNhpC5JgaV5Z0Pbzx0zNji6gLBk=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=jhCSCOTNVOkfL+ISShnnO7nZ6znrPL9qLTlSe7Fph6pnSbU9zhVAjtzj37/q2Hhq+ cWWshzYuIjKkQcOEi8wkL7H5z8Wr4N5fXdlwsPWVNMoKtYAyMDsBwkBRav6i/w/nQE q0UEV79yJTgWE8UmmEnYATK4X8IBeKMv20Eie8J4= Message-ID: <3dec8e6c-63ad-b235-008c-5f2ca05131e9@linux.microsoft.com> Date: Thu, 1 Jun 2023 07:53:41 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [edk2-devel] [RFC PATCH 00/11] Permit DXE drivers to execute in place To: devel@edk2.groups.io, ardb@kernel.org Cc: Ray Ni , Jiewen Yao , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny , Dandan Bi , Liming Gao , "Kinney, Michael D" , Leif Lindholm , Michael Kubacki References: <20230529101705.2476949-1-ardb@kernel.org> From: "Oliver Smith-Denny" In-Reply-To: <20230529101705.2476949-1-ardb@kernel.org> Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/29/2023 3:16 AM, Ard Biesheuvel wrote: > TL;DR - allow DXE drivers to execute in place from the decompressed FV > > loaded into memory by DxeIpl so we can apply strict permissions before > > dispatching DXE core. > > > > Currently, executable images loaded from firmware volumes are copied at > > least three times: once in the firmware volume driver, once in the DXE > > core load image code, and finally when the PE sections are populated in > > memory based on the section descriptions in the file. > > > > At least two of these copies serve little purpose, given that most > > drivers are typically dispatched from a memory-mapped firmware volume > > that is loaded into DRAM by DxeIpl from a compressed image in the boot > > FV, and so we can take a short-cut in the DXE image loader so that the > > PE/COFF library that performs the load uses the image in the memory > > mapped FV as its source directly. This is implemented by the first 6 > > patches (where the first 3 are just cleanups) > > > > With this logic in place, we can go one step further, and actually > > dispatch the image in place (similar to how XIP PEIMs are dispatched), > > without over moving it out of the decompressed firmware volume. This > > requires the image to be aligned sufficiently inside the FV, but this is > > also the same logic that applies to XIP PEIMs, and this can be achieved > > trivially by tweaking some FDF image generation rules. (Note that this > > adds padding to the FV, but this generally compresses well, and we > > ultimately uses less memory at runtime by not making a copy of the > > image). > > > > This requires the DXE IPL (which is the component that decompresses the > > firmware volumes to memory) to iterate over the contents and relocate > > these drivers in place. Given that DXE IPL is already in charge of > > applying NX permissions to the stack and to other memory regions, we can > > trivially extend it to apply restricted permissions to the XIP DXE > > drivers after relocation. > > > > This means we enter DXE core with those DXE drivers ready to be > > dispatched, removing the need to perform manipulation of memory > > attributes before the CPU arch protocol is dispatched, which is a bit of > > a catch-22 otherwise. > > > > With these changes in place, the platform no longer needs to map memory > > writable and executable by default, and all DRAM can be mapped > > non-executable right out of reset. > > Hi Ard, Thanks for sending out this RFC, great to see more work on the memory protections front. A few questions and thoughts: This seems a good effort (in conjunction with your last RFC) to close the protection gap between DxeCore launch and CpuDxe launch for marking non-code regions NX. Do you see other protections (guard pages for example) fitting into this method? I believe for any dynamic protections during this timeframe we would need the ability to manipulate the page tables directly from DxeCore. Similarly, in order to lessen the complexity of the DXE driver usage of memory resources and avoiding sync issues (e.g. a driver allocates pages that are mapped NX by default, then it sets a cacheability attribute and accidentally clears NX), I think further work would be valuable to reduce that complexity. I think your new PPI that allows setting and preserving bits independently of what is passed in is a very good step towards reducing this complexity. This patchset would move all properly aligned DXE drivers to be XIP, correct? Because we are XIP in DRAM, this should not have any performance implications (other than a benefit from reducing the extra copies in your first few patches), aside from potential space differences, which as you note compression will likely do away with, right? Thanks, Oliver