From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 10 Jul 2019 10:04:22 -0700 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6E3783091740; Wed, 10 Jul 2019 17:04:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-153.ams2.redhat.com [10.36.117.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1368210190A1; Wed, 10 Jul 2019 17:04:19 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode To: devel@edk2.groups.io, jian.j.wang@intel.com, "Zhang, Chao B" , Derek Lin , Cinnamon Shia References: <7564.1562045108414671150@groups.io> From: "Laszlo Ersek" Message-ID: <8d43a917-2a24-9db0-548c-2774db1e52a0@redhat.com> Date: Wed, 10 Jul 2019 19:04:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 10 Jul 2019 17:04:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, On 07/10/19 10:50, Wang, Jian J wrote: > Hi Derek, >=20 > Please file a Bugzilla for this issue. With it addressed, >=20 > Reviewed-by: Jian J Wang jian.j.wang@intel.com I saw this patch as soon as it was posted, and I've been hoping for a deeper discussion on the list. (I didn't ask my questions immediately because I felt they might have been somewhat naive.) So I guess I have to ask them now :) (1) What is the exact failure (or spec non-conformance) scenario? Is it the problem that, currently, even if SetupMode is 1, CustomMode also needs to be set, for enrolling a self-signed PK? (Looking at the patch itself, it looks like the subcondition that is *not* the CustomMode check is relaxed; so that seems to support my question.) (2) Can we please confirm that the code will continue to enforce self-signedness? I checked the spec, and I'm a bit worried about the spec language proper. Page 246 in UEFI-2.8 says, 3. If the variable SetupMode=3D=3D1, and the variable is a secure boot policy variable, then the firmware implementation shall consider the checks in the following steps 4 and 5 to have passed, and proceed with updating the variable value as outlined below. 4. Verify the signature by: =E2=80=94 extracting the EFI_VARIABLE_AUTHENTICATION_2 descriptor fro= m the Data buffer; =E2=80=94 using the descriptor contents and other parameters to (a) construct the input to the digest algorithm; (b) computing the digest; and (c) comparing the digest with the result of applying the signer=E2=80=99s public key to the signature. In other words, step#4 seems to stand for verifying self-signedness, and step#3 appears to require that *not even* self-signedness be enforced, when in SetupMode. Honestly, I think that step#4 should never be skipped. In other words, self-signedness should be unconditional. A certificate is basically a signed statement that a particular public key belongs to a particular entity (such as "FooBar"). If *not even* FooBar signs that statement, then the statement has *zero* credibility. So why should we accept it for any purpose at all? Speaking in terms of "PK" (UEFI Platform Key), specifically: what good would a platform vendor be that failed to sign its own PK? So, I'd like to understand: (2a) whether skipping step#4 in SetupMode is a bug in the spec -- because, I think it is; (2b) whether the edk2 code would continue enforcing self-signedness on X509 certificates, if the proposed patch were applied. Thanks! Laszlo > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Zh= ang, Chao B > Sent: Tuesday, July 09, 2019 11:39 PM > To: devel@edk2.groups.io; derek.lin2@hpe.com > Subject: Re: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled= PK in setup mode >=20 > Hi Derek: > The patch is good to me. > Reviewed-by : Chao Zhang > >=20 > From: devel@edk2.groups.io [mailto:devel@ed= k2.groups.io] On Behalf Of derek.lin2@hpe.com > Sent: Tuesday, July 2, 2019 1:25 PM > To: devel@edk2.groups.io > Subject: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK = in setup mode >=20 > Patch is attached from group.io. > Since ECR785, which is added UEFI 2.3.1 errata A, enrolling a PK in setu= p mode doesn't need to verify the PK. > Below is the sentence about it in UEFI spec > ``` > 3. If the firmware is in setup mode and the variable is one of: > - The global PK variable; > - The global KEK variable; > - The "db" variable with GUID EFI_IMAGE_SECURITY_DATABASE_GUID; or > - The "dbx" variable with GUID EFI_IMAGE_SECURITY_DATABASE_GUID, > then the firmware implementation shall consider the checks in the follow= ing steps 4 and 5 to > have passed, and proceed with updating the variable value as outlined be= low. > ``` > The step 4 is to verify the signature and the step 5 is to verify the ce= rt. >=20 > After this change, when system is in Setup mode, setting a PK does not r= equire authenticated variable descriptor. >=20 > Signed-off-by: Derek Lin > > Signed-off-by: cinnamon shia > >=20 >=20 >=20 >=20 >=20