From mboxrd@z Thu Jan 1 00:00:00 1970 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.3853.1689156310869645710 for ; Wed, 12 Jul 2023 03:05:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hChX/q2n; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689156310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IKOgON3AbwxIYWYqOnOIZ3WuZ/Mv+zLQLVLb/UcNv4o=; b=hChX/q2npg2WTgYVUrBX3yM22hsoGRLp3XNgMjUTlQbMUZddzyDD7f5OESTMl3kitPQKlv Al9A0lPlyS3k1KIyxrKsqWmK7ayLhX24znbdmWNg/D6Vd06P71cmyl3dB7zhMLCfAterl5 4XhKDYDU89cYhp4yEITam7zsmBT/1fY= 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-122-uSTtY9MAP7KfgC1kpZ9OJQ-1; Wed, 12 Jul 2023 06:05:06 -0400 X-MC-Unique: uSTtY9MAP7KfgC1kpZ9OJQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A32B886F121; Wed, 12 Jul 2023 10:05:05 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.252]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 260474028AB2; Wed, 12 Jul 2023 09:10:51 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A599D1800632; Wed, 12 Jul 2023 12:05:02 +0200 (CEST) Date: Wed, 12 Jul 2023 12:05:02 +0200 From: "Gerd Hoffmann" To: Taylor Beebe Cc: devel@edk2.groups.io, Jian J Wang , Liming Gao , Dandan Bi , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Leif Lindholm , Sami Mujawar , Andrew Fish , Ray Ni , Eric Dong , Rahul Kumar , Guo Dong , Sean Rhodes , James Lu , Gua Guo Subject: Re: [PATCH 00/14] Implement Dynamic Memory Protections Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 11, 2023 at 04:52:37PM -0700, Taylor Beebe wrote: > In the past, memory protection settings were configured via FixedAtBuild PCDs, > which resulted in a build-time configuration of memory mitigations. This > approach limited the flexibility of applying mitigations to the > system and made it difficult to update or adjust the settings post-build. Can we have both? Being able to adjust settings at runtime is great. But being able to set them at compile time on the command line (via build --pcd), without patching code, is very useful too. I'd suggest to keep the PCDs, create a profile from PCD settings and use that profile by default. At least for the transition phase and while we don't have good support (yet) to actually manage profiles. Speaking of profile management: What is the longer-term vision here? Have a configuration form in the uefi firmware setup (aka UiApp)? Try adapt settings automatically, for example pick a less strict profile in case an old/broken bootloader triggers a page fault due to using the wrong memory type for allocations? For virtual machine firmware it a good idea to allow picking up the profile configuration from the host. For qemu that can use fw_cfg, similar to the PcdSetNxForStack option we have today. > This patch series also increases the memory protection level for OvmfPkg and > ArmVirtPkg. Not a good idea, especially not using the 'debug' profile (which turns on all guard bits) because that slows down firmware boot alot. take care, Gerd