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 https://lists.01.org/mailman/listinfo/edk2-devel
