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.web11.2181.1685643086425351552 for ; Thu, 01 Jun 2023 11:11:26 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hShtl9dt; 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 EDA746489D for ; Thu, 1 Jun 2023 18:11:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59931C433A1 for ; Thu, 1 Jun 2023 18:11:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1685643085; bh=ZH3MM7wZa2Q7XFzQ6ZQOqODVN6vtDXV1wvVvhsJeZnY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hShtl9dtpOD4KmtMUFwYViOGkjGrjknSbkL0prqlEA88qCVCldhI10aWlxFxwTdiB 59Nj4f5u6jWN1hMbzil44DnPge24+nBqxk5RWsZpDwol7RAPaLORPAzfdeoriOacNL jVRazxzNUx9ZHhF1ycW/ajN7FAJeZeLHQCPkijpEFBhBSBa2+3AHFVd6uwHoprQW/J 2dFGlmYwZHA3zcfBE8lpNeqLtiiHcIqRmPw8ai2xONrmouPuOwrVsivtz1rmYjeXKI 6gEuqrleFMvSyfWOd4YyY2Fi9sh5uJWmvFEeaY1PjxLQbvKCPcV++99bi7wTcefdtU /Dzm7kyiY7c/A== Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-4f122ff663eso1517470e87.2 for ; Thu, 01 Jun 2023 11:11:25 -0700 (PDT) X-Gm-Message-State: AC+VfDzghQ0mYvkmaXsaZemqV62Ice/H/SvF78J9H8feiQUaiBuQKAF/ j6A0KhQNa74DdminKHp48daA/CXKinEjx9zhYhQ= X-Google-Smtp-Source: ACHHUZ5G0qyga1/JiDrgZEBjCQoz/gIhTMJep+Ggvf1gJXomHIAuGcaU+UFldmbznmDAqa2e92UY5/EhD+L85Nr35gY= X-Received: by 2002:a19:ac43:0:b0:4f3:a485:919f with SMTP id r3-20020a19ac43000000b004f3a485919fmr483634lfc.32.1685643083354; Thu, 01 Jun 2023 11:11:23 -0700 (PDT) MIME-Version: 1.0 References: <20230529101705.2476949-1-ardb@kernel.org> <3dec8e6c-63ad-b235-008c-5f2ca05131e9@linux.microsoft.com> In-Reply-To: <3dec8e6c-63ad-b235-008c-5f2ca05131e9@linux.microsoft.com> From: "Ard Biesheuvel" Date: Thu, 1 Jun 2023 20:11:12 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [RFC PATCH 00/11] Permit DXE drivers to execute in place 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 , Michael Kubacki Content-Type: text/plain; charset="UTF-8" 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. > 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 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.