From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, taylor.d.beebe@gmail.com,
Gerd Hoffmann <kraxel@redhat.com>,
Ard Biesheuvel <ardb@kernel.org>
Cc: Jian J Wang <jian.j.wang@intel.com>,
Liming Gao <gaoliming@byosoft.com.cn>,
Nhi Pham <nhi@os.amperecomputing.com>,
Oliver Steffen <osteffen@redhat.com>
Subject: Re: [edk2-devel] [PATCH v4 20/28] MdeModulePkg: Add Additional Profiles to SetMemoryProtectionsLib
Date: Thu, 5 Oct 2023 10:20:51 +0200 [thread overview]
Message-ID: <8ae346cc-36c0-55da-e939-bdf22ff5b7f4@redhat.com> (raw)
In-Reply-To: <f4f37bb4-c93c-4a00-9d17-d68a83cf80d0@gmail.com>
On 10/4/23 18:31, Taylor Beebe wrote:
>
> On 10/4/23 1:46 AM, Gerd Hoffmann wrote:
>> On Fri, Sep 29, 2023 at 12:52:35PM -0700, Taylor Beebe wrote:
>>> I can also update ArmVirtPkg to disable execution protection
>>> for EfiLoaderData by default until fw_cfg parsing
>>> support is added to ArmVirtPkg. Let me know if you think
>>> this is necessary.
>> With MemoryProtectionConfigLib adding fw_cfg parsing support to
>> ArmVirtPkg should be easy, so maybe just do that?
>
> From what I see, the QemuFwCfgLib instance compatible with Arm requires
> UefiBootServicesTableLib so fw_cfg cannot be parsed early enough to set
> the memory protection policy on ArmVirt.
QemuFwCfgLibMmio is DXE_DRIVER and UEFI_DRIVER only; it depends on (a)
the FDT client protocol, (b) MMIO accesses (that is, page tables).
On x86, PEI can use IO ports (no page tables), but that's not available
on ARM. I don't recall off-hand where / when exactly page tables are set
up during ArmVirtQemu boot.
You'd probably have to do something similar to
"ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c" and
"ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c"
-- parse the FDT on every fw_cfg access for the MMIO registers, then use
those registers to fetch the profile name, and do all that early enough
to configure the page protections -- so possibly *before*, or as a part
of, creating the page tables in the first place.
> An Arm compatible PEIM instance of QemuFwCfgLib will need to be created.
> I'm happy to look into it, but I don't want to hang up this patch series on
> that addition. Instead, I'll set the protection policy for ArmVirtPkg to
> the equivalent of the new GrubCompat profile in this series.
Can you base the default policy (i.e., the one that takes effect in the
absence of fw_cfg) on a PCD?
Such a PCD could be fixed-at-build, but I think it might even be
DynamicHII (compare commit 7e5f1b673870,
"ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable
override", 2017-03-31). That would have the benefit that people could
set a default at build time, with the --pcd build option. With
DynamicHII, the default could be stored in a non-volatile UEFI variable,
and ArmVirtQemu does have PEI-time (read-only) variable access.
Well, one argument against DynamicHII is that you'd want to prevent
later phases of the firmware from overwriting that variable, so you'd
have to get into variable policy / locking whatnot. So I'd suggest
picking the default profile from a fixed-at-build PCD (impossible to
overwrite "from the inside", and still enables the build-time --pcd
switch, for setting the platform default), *plus* fw-cfg for dynamic
configuration.
(Sorry I don't know anything about your series; it's possible you
already set the platform default via PCDs.)
I think platform builders should have the choice of picking a default
profile at build time; neither the Release (?) nor the GrubCompat
profile will fit everyone. I agree the *DEC* default should be the
strictest, but --pcd should be able to override that at build time, even
if -fw_cfg will allow for totally dynamic configuration too.
Laszlo
> Please let me know if I'm missing an obvious route to PEI fw_cfg
> parsing on Arm.
>
>
> -Taylor
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109344): https://edk2.groups.io/g/devel/message/109344
Mute This Topic: https://groups.io/mt/101469960/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-10-05 8:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 0:57 [edk2-devel] [PATCH v4 00/28] Implement Dynamic Memory Protection Settings Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 01/28] MdeModulePkg: Add DXE and MM Memory Protection Settings Definitions Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 02/28] MdeModulePkg: Define SetMemoryProtectionsLib and GetMemoryProtectionsLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 03/28] MdeModulePkg: Add NULL Instances for Get/SetMemoryProtectionsLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 04/28] MdeModulePkg: Implement SetMemoryProtectionsLib and GetMemoryProtectionsLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 05/28] MdeModulePkg: Copy PEI PCD Database Into New Buffer Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 06/28] MdeModulePkg: Apply Protections to the HOB List Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 07/28] MdeModulePkg: Check Print Level Before Dumping GCD Memory Map Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 08/28] UefiCpuPkg: Always Set Stack Guard in MpPei Init Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 09/28] ArmVirtPkg: Add Memory Protection Library Definitions to Platforms Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 10/28] OvmfPkg: " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 11/28] OvmfPkg: Apply Memory Protections via SetMemoryProtectionsLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 12/28] OvmfPkg: Update PeilessStartupLib to use SetMemoryProtectionsLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 13/28] UefiPayloadPkg: Update DXE Handoff " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 14/28] MdeModulePkg: " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 15/28] ArmPkg: Use GetMemoryProtectionsLib instead of Memory Protection PCDs Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 16/28] EmulatorPkg: " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 17/28] OvmfPkg: " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 18/28] UefiCpuPkg: " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 19/28] MdeModulePkg: " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 20/28] MdeModulePkg: Add Additional Profiles to SetMemoryProtectionsLib Taylor Beebe
2023-09-27 8:19 ` Gerd Hoffmann
2023-09-29 19:52 ` Taylor Beebe
2023-10-04 8:46 ` Gerd Hoffmann
2023-10-04 16:31 ` Taylor Beebe
2023-10-05 8:20 ` Laszlo Ersek [this message]
2023-10-05 9:29 ` Gerd Hoffmann
2023-10-05 10:23 ` Gerd Hoffmann
2023-10-05 12:57 ` Laszlo Ersek
2023-10-08 20:26 ` Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 21/28] OvmfPkg: Add QemuFwCfgParseString to QemuFwCfgSimpleParserLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 22/28] OvmfPkg: Add MemoryProtectionConfigLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 23/28] OvmfPkg: Enable Choosing Memory Protection Profile via QemuCfg Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 24/28] ArmVirtPkg: Apply Memory Protections via SetMemoryProtectionsLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 25/28] MdeModulePkg: Delete PCD Profile from SetMemoryProtectionsLib Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 26/28] OvmfPkg: Delete Memory Protection PCDs Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 27/28] ArmVirtPkg: " Taylor Beebe
2023-09-20 0:57 ` [edk2-devel] [PATCH v4 28/28] MdeModulePkg: " Taylor Beebe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ae346cc-36c0-55da-e939-bdf22ff5b7f4@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox