Re: Set "db" variable in secure boot setup mode still requires generating PKCS#7?

["Long, Qin" <qin.long@intel.com>]

Hi, David,

Yes, in Setup / Custom mode, no need to generate the AuthData for verification. It's 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's 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 <lersek@redhat.com>
Cc: edk2 developers list <edk2-devel@lists.01.org>
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=0;
  siglisthdrsize=0;
}
else {
  authhdrsize=offsetof(EFI_VARIABLE_AUTHENTICATION_2,
AuthInfo)+offsetof(WIN_CERTIFICATE_UEFI_GUID, CertData);
  siglisthdrsize=sizeof(EFI_SIGNATURE_LIST)+offsetof(EFI_SIGNATURE_DATA,
SignatureData);
}
size_t tempbufsize=ffinfo.FileSize+authhdrsize+siglisthdrsize;

BYTE *tempbuf;
if ((tempbuf=new BYTE [tempbufsize])!=NULL) {
  // variable to determine where to read file
  BYTE *certdata=tempbuf;
  // 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=(EFI_VARIABLE_AUTHENTICATION_2 *) tempbuf;
    // setup time
    TimeTToUEFITimeGMT(time(NULL), &efivarauth2->TimeStamp);
    efivarauth2->TimeStamp.Nanosecond=0;
    // setup authinfo (without any CertData)
    efivarauth2->AuthInfo.Hdr.dwLength=offsetof(WIN_CERTIFICATE_UEFI_GUID,
CertData);
    efivarauth2->AuthInfo.Hdr.wRevision=0x200;
    efivarauth2->AuthInfo.Hdr.wCertificateType=WIN_CERT_TYPE_EFI_GUID;
    efivarauth2->AuthInfo.CertType=gEfiCertPkcs7Guid;
    //
    // setup EFI_SIGNATURE_LIST
    //
    EFI_SIGNATURE_LIST *efisiglist=(EFI_SIGNATURE_LIST *)
(tempbuf+authhdrsize);
    efisiglist->SignatureType=gEfiCertX509Guid;

efisiglist->SignatureListSize=(uint32_t)(ffinfo.FileSize+siglisthdrsize);
    efisiglist->SignatureHeaderSize=0;
    efisiglist->SignatureSize=ffinfo.FileSize+offsetof(EFI_SIGNATURE_DATA,
SignatureData);
    //
    // setup EFI_SIGNATURE_DATA  (no owner)
    //
    EFI_SIGNATURE_DATA *efisigdata=(EFI_SIGNATURE_DATA *)
((BYTE*)efisiglist+sizeof(EFI_SIGNATURE_LIST)+efisiglist->SignatureHeaderSize);
    certdata=efisigdata->SignatureData;
  }
  // Read file to buffer
  if ((errcode=FSOpenReadCloseFile(openpath, certdata, 0, ffinfo.FileSize,
NULL, filesys))==ERROR_NONE) {
    // have the data, now write it to the correct variable
    uint32_t varattr=EFI_VARIABLE_NON_VOLATILE|
                     EFI_VARIABLE_BOOTSERVICE_ACCESS|
                     EFI_VARIABLE_RUNTIME_ACCESS|
                     EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS;
    if (!rparam) {
      varattr|=EFI_VARIABLE_APPEND_WRITE;
    }

    // update variable
    errcode=UEFISetVariable(varname, guidstr, tempbuf, tempbufsize,
varattr);
  }
  // clean up
  delete[] tempbuf;
}


On Wed, May 2, 2018 at 3:21 AM, Laszlo Ersek <lersek@redhat.com<mailto:lersek@redhat.com>> 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         = 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<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel