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

["David F." <df7729@gmail.com>]

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> 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
>