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.2937.1687537634098896127 for ; Fri, 23 Jun 2023 09:27:14 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SctMkzMW; 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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7E6DB61AB6 for ; Fri, 23 Jun 2023 16:27:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E228C433CD for ; Fri, 23 Jun 2023 16:27:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687537632; bh=TsT1rckzLsiBma1wMNhmNurL5ZN+fVCrE6RQsOwFkW8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SctMkzMWLmZULU8rMafi72toXrfg1d4siJg6Rv+x/2rssGxfj228Mohn1uDmkcJwr MU7sPxO+0y9uoWuli4eKGYrB3UW3W8mgkS7R/A5wE6OcBiiKjxrFeqnS+fK+F3kVrG aZmlu6Kc3q0ZPXS31TtNZqWj9dK93wExXU+EwHWVZMLlbG31p7FVs/l5RgnXLL2uJ9 OC5vdalYMdS06iUqUWEY1Lq/lRkkiWD2b+7Fpt6d691Zzm8lVxOQ6ZyRl4TXJJKQ7x WegGOt7ZwGkHt/w62xuRmofFBM3AbT71KWYjYJZAQUIxzsjKO4UhKhXcyuaC3qa8C6 RQE55vnWPIvrw== Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-4f86a7a5499so1138065e87.2 for ; Fri, 23 Jun 2023 09:27:12 -0700 (PDT) X-Gm-Message-State: AC+VfDwGL71Zi7ttjmtEV2Tl5d324v1ff1UDcg3C3j64zr+l5uofErNf Rmqg6/SIsyGwx14NP1clcZACtCL63A9Zfo7SRJs= X-Google-Smtp-Source: ACHHUZ5bSYfBupoKAZ8/snr5oX9uuOLRZi9flHD/vrRPgx1+lMoLrgpefYlVznjc50rnaAakzR+LUotdsyfrSh7rvmU= X-Received: by 2002:a05:6512:31c7:b0:4f9:5cb9:5be6 with SMTP id j7-20020a05651231c700b004f95cb95be6mr6945005lfe.45.1687537630371; Fri, 23 Jun 2023 09:27:10 -0700 (PDT) MIME-Version: 1.0 References: <20230619203244.228933-1-osteffen@redhat.com> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 23 Jun 2023 18:26:59 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 1/1] ArmPkg: Add Pcd to disable EFI_MEMORY_ATTRIBUTE_PROTOCOL To: Sean Brogan Cc: devel@edk2.groups.io, kraxel@redhat.com, Oliver Steffen , Ard Biesheuvel , Daniel Schaefer , Eric Dong , Leif Lindholm , Liming Gao , Michael D Kinney , Rahul Kumar , Ray Ni , Sami Mujawar , Sunil V L , Zhiguang Liu , Taylor Beebe , Oliver Smith-Denny , Michael Kubacki Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 20 Jun 2023 at 19:07, Sean Brogan wrote: > > I don't think a MemoryAttributes2Protocol with a single API would have av= oided the errors. > > The programming pattern that triggered this would still need multiple cal= ls to any API and in the future where all memory is allocated as NX this po= ssibility would still exist. > > A short term effort to minimize the compatibility problem in the ecosyste= m is documented here Memory Protections: Document compatibility challenges = =C2=B7 Issue #18 =C2=B7 tianocore/projects (github.com) It does not addres= s (and i don't see any reason to try to) a loader that uses the protocol in= correctly. > > We have provided virtual reference platforms with these features enabled = (both arm and x86) and have been working with the relevant communities for = multiple years now. The UEFI CA for option roms already have compliance re= quirements (UPDATED: UEFI Signing Requirements - Microsoft Community Hub). = But there are and will continue to be compatibility challenges when enabli= ng a more restrictive execution environment in uefi and the uefi ecosystem.= The more things we make optional the longer this transition period will t= ake. "Memory Mitigations" were proposed and mostly coded over a decade a= go. The code changes are not that difficult. To change our vast and unwiel= dy ecosystem is the hard part. Please help to "stay the course" for this = very necessary industry change. If a production platform has requirements= that force such a configuration option that is understandable but it is co= unter productive in open-source industry standard reference Edk2 code. > Fair enough. But I will note that the only reason we are in this situation in the first place is because shim has to re-implement the PE loader, cert handling and all related crypto, and needs the memory attributes protocol to manipulate the RO/NX permissions. Now that we are taking these things seriously, wouldn't it be *much* better to get rid of all this cruft, and specify a method by which a loader can provide an ephemeral DB that the system firmware will authenticate against? That way, we can reduce shim to a single SetVariable() call that creates the ephemeral DB (and perhaps a call into the TPM code to measure it), which is arguably a lot easier to audit than the code we have today.