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 <devel@edk2.groups.io>;
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 <devel@edk2.groups.io>; Fri, 23 Jun 2023 16:27:13 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E228C433CD
for <devel@edk2.groups.io>; 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 <devel@edk2.groups.io>; 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> <rkq7clawcm537wzel4s3rcfas7zxycjlgsbdd4pw6sohj5qjlh@c54vs6opt55h>
<CAMj1kXFeWJuE93=dLwRNjQyRGXc0vUmd=yZ3aXMHQm-3zEk=Tg@mail.gmail.com>
<v54pf2wnethhj643uobs33bll4wbli2qgontscx37od3d6pwsz@n66ojub3tcj2> <BY3PR19MB4900475B45F5FCA20A31C71EC85CA@BY3PR19MB4900.namprd19.prod.outlook.com>
In-Reply-To: <BY3PR19MB4900475B45F5FCA20A31C71EC85CA@BY3PR19MB4900.namprd19.prod.outlook.com>
From: "Ard Biesheuvel" <ardb@kernel.org>
Date: Fri, 23 Jun 2023 18:26:59 +0200
X-Gmail-Original-Message-ID: <CAMj1kXGxpX6FCgFwO69sSi3jW8bhm_r7dM_u6LEd3MfX-bo5EA@mail.gmail.com>
Message-ID: <CAMj1kXGxpX6FCgFwO69sSi3jW8bhm_r7dM_u6LEd3MfX-bo5EA@mail.gmail.com>
Subject: Re: [edk2-devel] [PATCH 1/1] ArmPkg: Add Pcd to disable EFI_MEMORY_ATTRIBUTE_PROTOCOL
To: Sean Brogan <spbrogan@outlook.com>
Cc: devel@edk2.groups.io, kraxel@redhat.com,
Oliver Steffen <osteffen@redhat.com>, Ard Biesheuvel <ardb+tianocore@kernel.org>,
Daniel Schaefer <git@danielschaefer.me>, Eric Dong <eric.dong@intel.com>,
Leif Lindholm <quic_llindhol@quicinc.com>, Liming Gao <gaoliming@byosoft.com.cn>,
Michael D Kinney <michael.d.kinney@intel.com>, Rahul Kumar <rahul1.kumar@intel.com>,
Ray Ni <ray.ni@intel.com>, Sami Mujawar <sami.mujawar@arm.com>,
Sunil V L <sunilvl@ventanamicro.com>, Zhiguang Liu <zhiguang.liu@intel.com>,
Taylor Beebe <t@taylorbeebe.com>, Oliver Smith-Denny <osd@smith-denny.com>,
Michael Kubacki <mikuback@linux.microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, 20 Jun 2023 at 19:07, Sean Brogan <spbrogan@outlook.com> 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.