From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id D5D5AD810B3 for ; Thu, 5 Oct 2023 08:20:59 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=C8Hq9iPwPqUlR/OxvOVZkX/IKkDGlLiYI833yFJEON0=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1696494058; v=1; b=pCVoBuJAE/ZTCnHn2kVQexl+/Kont1wqXqtNNe5eB+FoUDryQ0tziSrVMIGgnGWVphOj3ZGw se4b/MI0WgvwmtmpgF5E5aKUgeRrsI4e9aDxaYBtQMU4EcjtXCzdYx/qQk3y8TLvECaRz7KSyvq ffxOPT/5Hbo02cmem/EZWW1s= X-Received: by 127.0.0.2 with SMTP id 2iqkYY7687511x4VyUW7zZtx; Thu, 05 Oct 2023 01:20:58 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.10619.1696494057786574701 for ; Thu, 05 Oct 2023 01:20:57 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-78-uPU3PHYgNJ6G7tUmBzkcqg-1; Thu, 05 Oct 2023 04:20:54 -0400 X-MC-Unique: uPU3PHYgNJ6G7tUmBzkcqg-1 X-Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CFCFB81163A; Thu, 5 Oct 2023 08:20:53 +0000 (UTC) X-Received: from [10.39.193.139] (unknown [10.39.193.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E797C15BB8; Thu, 5 Oct 2023 08:20:52 +0000 (UTC) Message-ID: <8ae346cc-36c0-55da-e939-bdf22ff5b7f4@redhat.com> Date: Thu, 5 Oct 2023 10:20:51 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH v4 20/28] MdeModulePkg: Add Additional Profiles to SetMemoryProtectionsLib To: devel@edk2.groups.io, taylor.d.beebe@gmail.com, Gerd Hoffmann , Ard Biesheuvel Cc: Jian J Wang , Liming Gao , Nhi Pham , Oliver Steffen References: <20230920005752.2041-1-taylor.d.beebe@gmail.com> <20230920005752.2041-21-taylor.d.beebe@gmail.com> <2390fe7b-d994-4aed-8b45-97bf028b2cb3@gmail.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 7VnZ90nvT4wHqhJmY0ojLtjPx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=pCVoBuJA; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) On 10/4/23 18:31, Taylor Beebe wrote: >=20 > 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? >=20 > 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. >=20 >=20 > -Taylor >=20 >=20 >=20 >=20 >=20 >=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 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/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-