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

[Laszlo Ersek <lersek@redhat.com>]

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