From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.24; helo=mga09.intel.com; envelope-from=qin.long@intel.com; receiver=edk2-devel@lists.01.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 611B42063E2E8 for ; Wed, 2 May 2018 20:09:48 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2018 20:09:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,356,1520924400"; d="scan'208,217";a="42649373" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga002.fm.intel.com with ESMTP; 02 May 2018 20:09:47 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 2 May 2018 20:09:47 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.210]) by shsmsx102.ccr.corp.intel.com ([169.254.2.79]) with mapi id 14.03.0319.002; Thu, 3 May 2018 11:09:45 +0800 From: "Long, Qin" To: David F. , Laszlo Ersek CC: edk2 developers list Thread-Topic: [edk2] Set "db" variable in secure boot setup mode still requires generating PKCS#7? Thread-Index: AQHT4ZE+4VlU7YLhEUGyML0OkyqTXaQbtWSAgABl/wCAATTPEA== Date: Thu, 3 May 2018 03:09:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzIyOWE2NTAtZmNkMi00ZjhiLTg2ODUtODUyNGUzMjQ5YTEwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJZQ1VabWQ0Tm9pb0tkN2pHXC9adTlidmJjaWJzTFwvUm90eWh1dTA0R1ZOMGRPWG5ucW03dW05UTFRdUFmUnRCOG0ifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.26 Subject: Re: Set "db" variable in secure boot setup mode still requires generating PKCS#7? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 03:09:48 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, David, Yes, in Setup / Custom mode, no need to generate the AuthData for verificat= ion. It's good enough to create the AUTH_2 descriptor / headers without Cer= tData as the parameter for SetVariable() call. Do you mean this code snippet can succeed to enroll KEK, but fail to enroll= DB data? The data initialization from code snippet looks good. What's the returned e= rrcode value? (And one reminder is that KEK and DB are binding with differe= nt vendor GUID: gEfiGlobalVariableGuid, and gEfiImageSecurityDatabaseGuid). Best Regards & Thanks, LONG, Qin From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Davi= d F. Sent: Thursday, May 3, 2018 12:26 AM To: Laszlo Ersek Cc: edk2 developers list Subject: Re: [edk2] Set "db" variable in secure boot setup mode still requi= res generating PKCS#7? This Intel mobo didn't like? This is the code snippet that builds it: // calc size of header (with no certdata) and crt file data to add size_t authhdrsize; size_t siglisthdrsize; if (applyrawdata) { authhdrsize=3D0; siglisthdrsize=3D0; } else { authhdrsize=3Doffsetof(EFI_VARIABLE_AUTHENTICATION_2, AuthInfo)+offsetof(WIN_CERTIFICATE_UEFI_GUID, CertData); siglisthdrsize=3Dsizeof(EFI_SIGNATURE_LIST)+offsetof(EFI_SIGNATURE_DATA, SignatureData); } size_t tempbufsize=3Dffinfo.FileSize+authhdrsize+siglisthdrsize; BYTE *tempbuf; if ((tempbuf=3Dnew BYTE [tempbufsize])!=3DNULL) { // variable to determine where to read file BYTE *certdata=3Dtempbuf; // determine if need to prefix .crt for kek/db entries if (!applyrawdata) { // zero header part of buffer so all are init to zero memset(tempbuf, 0, authhdrsize+siglisthdrsize); // // setup EFI_VARIABLE_AUTHENTICATION_2 header // EFI_VARIABLE_AUTHENTICATION_2 *efivarauth2=3D(EFI_VARIABLE_AUTHENTICATION_2 *) tempbuf; // setup time TimeTToUEFITimeGMT(time(NULL), &efivarauth2->TimeStamp); efivarauth2->TimeStamp.Nanosecond=3D0; // setup authinfo (without any CertData) efivarauth2->AuthInfo.Hdr.dwLength=3Doffsetof(WIN_CERTIFICATE_UEFI_GUID= , CertData); efivarauth2->AuthInfo.Hdr.wRevision=3D0x200; efivarauth2->AuthInfo.Hdr.wCertificateType=3DWIN_CERT_TYPE_EFI_GUID; efivarauth2->AuthInfo.CertType=3DgEfiCertPkcs7Guid; // // setup EFI_SIGNATURE_LIST // EFI_SIGNATURE_LIST *efisiglist=3D(EFI_SIGNATURE_LIST *) (tempbuf+authhdrsize); efisiglist->SignatureType=3DgEfiCertX509Guid; efisiglist->SignatureListSize=3D(uint32_t)(ffinfo.FileSize+siglisthdrsize); efisiglist->SignatureHeaderSize=3D0; efisiglist->SignatureSize=3Dffinfo.FileSize+offsetof(EFI_SIGNATURE_DATA= , SignatureData); // // setup EFI_SIGNATURE_DATA (no owner) // EFI_SIGNATURE_DATA *efisigdata=3D(EFI_SIGNATURE_DATA *) ((BYTE*)efisiglist+sizeof(EFI_SIGNATURE_LIST)+efisiglist->SignatureHeaderSi= ze); certdata=3Defisigdata->SignatureData; } // Read file to buffer if ((errcode=3DFSOpenReadCloseFile(openpath, certdata, 0, ffinfo.FileSize= , NULL, filesys))=3D=3DERROR_NONE) { // have the data, now write it to the correct variable uint32_t varattr=3DEFI_VARIABLE_NON_VOLATILE| EFI_VARIABLE_BOOTSERVICE_ACCESS| EFI_VARIABLE_RUNTIME_ACCESS| EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS; if (!rparam) { varattr|=3DEFI_VARIABLE_APPEND_WRITE; } // update variable errcode=3DUEFISetVariable(varname, guidstr, tempbuf, tempbufsize, varattr); } // clean up delete[] tempbuf; } On Wed, May 2, 2018 at 3:21 AM, Laszlo Ersek > wrote: > On 05/01/18 23:13, David F. wrote: > > Hi, > > > > Had a fairly simple task of wanting to install the latest MS .crt > > files for KEK, and their two files for the "db" (the Windows CA and > > UEFI CA) in a system placed in setup/custom mode. However, even > > though it seemed to take the KEK, it never took the "db", always had a > > problem on a DH77KC mobo (dumped data headers looked as expected). Now > > when I constructed it, I thought I could leave out any PKCS#7 data > > (set the expected CertType but in the Hdr dwLength only included > > CertType and not any CertData), > > Right, I've stumbled upon that too. According to the UEFI spec, dwLength > should include CertData too, but edk2 does *not* accept that. This can > be seen e.g. in > "SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/ > SecureBootConfigImpl.c", > function CreateTimeBasedPayload(): > > > // > > // In Setup mode or Custom mode, the variable does not need to be > signed but the > > // parameters to the SetVariable() call still need to be prepared as > authenticated > > // variable. So we create EFI_VARIABLE_AUTHENTICATED_2 descriptor > without certificate > > // data in it. > > // > > ... > > DescriptorData->AuthInfo.Hdr.dwLength =3D OFFSET_OF > (WIN_CERTIFICATE_UEFI_GUID, CertData); > > Back to your email: > > On 05/01/18 23:13, David F. wrote: > > but looking at the algo in UEFI Spec 2.6 page 245, it looks like we'd > > always have to generate the hash, sign it, create all the PKCS stuff > > even in setup mode? That would surely unnecessarily bloat any apps > > that really only need to update things in setup mode wouldn't it? So > > to confirm, that is a requirement even in setup mode? If so, why? > > It's not a requirement; see the code comment I quoted above. > > Thanks, > Laszlo > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel