From mboxrd@z Thu Jan  1 00:00:00 1970
Subject: Re: [edk2-devel] [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction
To: Kubacki, Michael A <michael.a.kubacki@intel.com>,devel@edk2.groups.io
From: "Johnson, Michael" <michael.johnson@intel.com>
X-Originating-Location: Portland, Oregon, US (134.134.139.73)
X-Originating-Platform: Windows Chrome 76
User-Agent: GROUPS.IO Web Poster
MIME-Version: 1.0
Date: Thu, 05 Sep 2019 13:59:23 -0700
References: <49AB4ACB9627B8468F29D589A27B745588AA4398@ORSMSX121.amr.corp.intel.com>
In-Reply-To: <49AB4ACB9627B8468F29D589A27B745588AA4398@ORSMSX121.amr.corp.intel.com>
Message-ID: <19024.1567717163471496842@groups.io>
Content-Type: multipart/alternative; boundary="mncEOkwNYdLljoACteto"

--mncEOkwNYdLljoACteto
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Your primary concern is my primary concern.=C2=A0 I can think of two scenar=
ios where a runtime memory varstore would hurt.

The less severe one is that any variables measured into a TPM could appear=
 to be modified when read back so that if/when some entity wants to verify =
or unseal something, they would be unable to match the TPM's PCR values and=
 unable to verify/unseal.=C2=A0 This turns access to runtime EFI memory int=
o a denial of service for TPM-based post-boot software.

The more worrying possibility is if somebody decides to use a read-modify-=
write pattern for some variable they have an interest in and thus end up de=
feating the security of the variable write method.=C2=A0 Today a read-modif=
y-write is safe, but after this change it would not be.

--mncEOkwNYdLljoACteto
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Your primary concern is my primary concern.&nbsp; I can think of two scenar=
ios where a runtime memory varstore would hurt.<br /><br />The less severe =
one is that any variables measured into a TPM could appear to be modified w=
hen read back so that if/when some entity wants to verify or unseal somethi=
ng, they would be unable to match the TPM's PCR values and unable to verify=
/unseal.&nbsp; This turns access to runtime EFI memory into a denial of ser=
vice for TPM-based post-boot software.<br /><br />The more worrying possibi=
lity is if somebody decides to use a read-modify-write pattern for some var=
iable they have an interest in and thus end up defeating the security of th=
e variable write method.&nbsp; Today a read-modify-write is safe, but after=
 this change it would not be.

--mncEOkwNYdLljoACteto--