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.web11.9403.1672994680585169511 for ; Fri, 06 Jan 2023 00:44:40 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=XZ2cjTqS; 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=1672994679; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=txZ/UPUY62iSl3l4YN5dl22gTEncl9Lb4bZ8hsVLt4U=; b=XZ2cjTqSBGqo+u/LMZJLySfXk01NCxGSF/8kSBcPiwfHLFbNnIb8ZQKStebAtIDD4u2XRE SyUBaP1EjwThCD4ZGnQUkKHgzOtzUUiE37HhEO4qwAHIcDusEBw2HH+1d68C1YQnRHFOno +DWkoij6oe0XmhecBjkWK4DuYcckTkM= 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-364-BnQpNirPPMCuyttb2V6K1w-1; Fri, 06 Jan 2023 03:44:36 -0500 X-MC-Unique: BnQpNirPPMCuyttb2V6K1w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CE63880234E; Fri, 6 Jan 2023 08:44:35 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 46C2540C2064; Fri, 6 Jan 2023 08:44:35 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 738F21800081; Fri, 6 Jan 2023 09:44:33 +0100 (CET) Date: Fri, 6 Jan 2023 09:44:33 +0100 From: "Gerd Hoffmann" To: Sean Brogan Cc: devel@edk2.groups.io, Ard Biesheuvel , Alexander Graf , dann frazier , Leif Lindholm Subject: Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable Message-ID: <20230106084433.rlu7gzt7spgdktcn@sirius.home.kraxel.org> References: <20230105081127.muckhpcw6agfkfrs@sirius.home.kraxel.org> <3F97900D-3C85-4E10-BBC2-360CECFD2D39@csgraf.de> <20230105111929.wgjtafvbht5gl2x4@sirius.home.kraxel.org> <20230105151241.ljgxdtm7nqt3zp7q@sirius.home.kraxel.org> <20230105195836.hh3guyztbn2asyur@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi, > Hopefully sometime in the next few weeks we can prepare a comprehensive set > of patches and changes needed in edk2 to implement this strict environment.  > One of the relevant changes to this discussion and patch series is we > switched the configuration from PCD to hob > (mu_basecore/DxeMemoryProtectionSettings.h at release/202208 · > microsoft/mu_basecore (github.com) ). > This allows our platforms complete control of the config per boot. Why a HOB? I guess because dynamic PCDs are available too late in the boot process? > Some platforms have compatibility requirements and have implemented > code so that when a PF is triggered by incompatible software, it is > recorded and then the system rebooted.  On the next boot the platform > changes the HOB configuration to be in a more compatible mode (this > mode could be measured in a PCR and/or other hints to the user/system > of degraded security). Where is the configuration stored? > Anyway, rather than a patchwork of changes going into different platforms > and components of edk2 I would like to see alignment between x86/arm64 in > edk2 and a complete set of changes for edk2. Sure, it totally makes sense to have that as core edk2 feature instead of adding this to each platform individually. Looking forward to see the patches. take care, Gerd