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.web11.412.1685644212474875136 for ; Thu, 01 Jun 2023 11:30:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=FbGEL67x; 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 D0BA220FC4F8; Thu, 1 Jun 2023 11:30:11 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com D0BA220FC4F8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1685644212; bh=TFBXdVbG0PE8O6sQffzh1eUoXkOZ8mZdlBIqIqwOfPo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=FbGEL67xvmeytfemSa/P4mcsCNL9GRKHiEnY/bO9u3MnzlOCUITJ8RTUspCHdd9ai 6T5GfMxOIWJZzE4hRZiD1mEBhA6Fy8Ka3IRC2CoTirHA+ZgcjMOvYQNb2SPKkJUatG lSjzjAdlyZhAKRZ9v1mSZ1HgvREMaJAgZBfivaMY= Message-ID: <7f6d7c14-34fa-baaa-7911-85cd828b8f62@linux.microsoft.com> Date: Thu, 1 Jun 2023 11:30:11 -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> <3dec8e6c-63ad-b235-008c-5f2ca05131e9@linux.microsoft.com> From: "Oliver Smith-Denny" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/1/2023 11:11 AM, Ard Biesheuvel wrote: > On Thu, 1 Jun 2023 at 16:53, Oliver Smith-Denny > wrote: >> >> 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. >> > > The use case of guard pages did not really occur to me, to be honest, > and this is obviously something that doesn't work either before the > CPU arch protocol is dispatched > > I still think it would be preferable to add the ability to manage > memory mapping permissions to the DXE core itself, and separate it > from the CPU arch protocol. > > Note that clumping everything together does not really help in this > respect either: if the memory permission manipulation logically > remains a part of the CPU arch protocol, which cannot be installed > until its dependencies are satisfied, we are still in a situation > where dispatching those dependencies may result in page allocations > being created before we can unmap the guard pages. > I agree. I think that the ability for DXE Core to manage the memory attributes itself is the central simplification that could go a long ways towards cleaning up the existing interfaces and making the code more maintainable with less potential pitfalls (that we currently see hit frequently). I think the memory attribute management can be split apart from CpuDxe without bringing all of CpuDxe into Dxe Core and certainly if that is the better path towards tackling the problem we face, I support it. >> 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. >> > > Hopefully, we'll be able to do something at the library/driver level > here (AllocatePages in the DMA or PCI layer). > > Another thing we might entertain (which maps really well onto the WXN > thing we have on ARM) is to add a GCD memory region capability that > makes memory XP unless it is RO. But I haven't really experimented > with that yet - I'll keep you posted on that. > This is definitely interesting to me as well. I would love this capability :). I've been doing some investigations in this area, but not specifically towards ARM's WXN, that seems a great place to intersect. Thanks, Oliver >> This patchset would move all properly aligned DXE drivers to be XIP, >> correct? > > Yes. > >> 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? >> > > Exactly. > > > >