From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:400e:c05::236; helo=mail-pg0-x236.google.com; envelope-from=df7729@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CA3EE20985980 for ; Sun, 20 May 2018 12:54:23 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id n9-v6so5413315pgq.5 for ; Sun, 20 May 2018 12:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Px9UUL1MGQzk89uIf7lbVQ2NETzAMJsh0x58qvqIomE=; b=gGN7XwvvCD5AgILAHxee9w8WnsfQfexL23SiHILospN34dBj7nGrWZZdNiQ1RLVf4r /ZhZSXRvZOOQSJKLD2G127OHmeCK4JXYdJwwj/0YZYMBaS+KtrZ26ZSMFTtKjJYCVSsf v8g68ZOLc0v9/1fc/UTpkQb+ilULeryF8jmlzfa2rwagSIalKYCT7e9onBXX62yMXric 9qwzusoQlVsdN25wkGThm1PAqdSOVCH3ZB/ETgd/Y7UQbeeVMGIedDcUozBma9RNfxcK 1LEer9gT51GFmY2FjvcewFT9+mucYHhckwGrBN8eE8+q+pcJ5cW4aU7S9xQoKDg8p+ON KpYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Px9UUL1MGQzk89uIf7lbVQ2NETzAMJsh0x58qvqIomE=; b=iGbrd7P/21E2/g+Tc5dv176pustRaR+20TXn9qdu8uPYZHJjsUbTMigbFiytazs4MG OUOKE6EYrZECZ3QTDoA3Y03Ght3Z/MzF5aEi44L+ssnii7gM5hROSek0zWpXSQPLx58g r1R2dD12//f0zXNOmztXy9Xvt8XWuarsjm9kQMSCFgIFjnS4UCQd9Wp6HQ5arRj+gcoD S9jRrcSOuQm+SCrlmL3wTlIebqyuGLCwwhzf6HIN2HBI98Ow8x0zOQ6PwdMqtJ4S/R0+ xIXUIhaUNaP8OZY+fWAKwiN1/RSgh4o2vrcGmW/OGtOPs0SV0CUJUnUU1+QF88VxxRrH 35LA== X-Gm-Message-State: ALKqPwcK0zWuOmo4uO+6PBdkxr9qPwT/m+EOV6fMpEn4hT31M2j7Qjwb ab1Ex0oZ4mENReYV9N39uHFvrn2By3eZ6wvfhto= X-Google-Smtp-Source: AB8JxZrhtGVYLL+jVILlz2hs0VoS0WsqXoc2aoYt7m2D10X5yJwZ/hmJZheYQn3XS31NSmksvISvsGB61JIh2eCbQ6M= X-Received: by 2002:a62:883:: with SMTP id 3-v6mr17586562pfi.154.1526846063225; Sun, 20 May 2018 12:54:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9202:0:0:0:0 with HTTP; Sun, 20 May 2018 12:54:22 -0700 (PDT) In-Reply-To: References: From: "David F." Date: Sun, 20 May 2018 12:54:22 -0700 Message-ID: To: "Long, Qin" Cc: Laszlo Ersek , edk2 developers list 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: Sun, 20 May 2018 19:54:24 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >Do you mean this code snippet can succeed to enroll KEK, but fail to enroll DB data? Correct. > What=E2=80=99s the returned errcode value? (And one reminder is that KEK = and DB are binding with different vendor GUID: gEfiGlobalVariableGuid, and gEfiImageSecurityDatabaseGuid). It was a access denied type of error code (I'd have to enable it again to test the exact code). Yes, the GUID was set different for the database (wasn't able to save anything using the database guid). On Wed, May 2, 2018 at 8:09 PM, Long, Qin wrote: > Hi, David, > > > > Yes, in Setup / Custom mode, no need to generate the AuthData for > verification. It=E2=80=99s good enough to create the AUTH_2 descriptor / = headers > without CertData 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=E2=80=99s the = returned > errcode value? (And one reminder is that KEK and DB are binding with > different vendor GUID: gEfiGlobalVariableGuid, and > gEfiImageSecurityDatabaseGuid). > > > > > > Best Regards & Thanks, > > LONG, Qin > > > > *From:* edk2-devel [mailto:edk2-devel-bounces@lists.01.org] *On Behalf Of > *David 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 > requires 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_GU= ID, > 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_DA= TA, > SignatureData); > // > // setup EFI_SIGNATURE_DATA (no owner) > // > EFI_SIGNATURE_DATA *efisigdata=3D(EFI_SIGNATURE_DATA *) > ((BYTE*)efisiglist+sizeof(EFI_SIGNATURE_LIST)+efisiglist-> > SignatureHeaderSize); > certdata=3Defisigdata->SignatureData; > } > // Read file to buffer > if ((errcode=3DFSOpenReadCloseFile(openpath, certdata, 0, ffinfo.FileSi= ze, > 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). No= w > > > 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, dwLengt= h > > 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 a= s > > 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? S= o > > > 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 > >