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

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

I'm with you, but the question I would have is how much checking does
it end up doing?  In other words, how can a fake PKCS#7 be created in
a small amount of code that would make the guard happy enough to let
it through in setup mode?   I just don't see the point of even having
to create one when it is going to be ignored anyway?

Thanks.

On Tue, May 1, 2018 at 2:25 PM, Bill Paul <wpaul@windriver.com> wrote:
> Of all the gin joints in all the towns in all the world, David F. had to walk
> into mine at 14:13 on Tuesday 01 May 2018 and say:
>
>> 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), 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?
>>
>
> If I understand correctly, I think the issue is that the PK, KEK, db and dbx
> are always considered to be secure environment variables, which means when you
> try to update them with SetVariable(), you always have to include one of the
> authentication flags and a properly formated authentication header.
>
> The difference between variable updates in secure mode vs. setup/custom mode
> is that in setup/custom mode, the signature is not validated. It still has to
> be there, but the firmware doesn't care what it says. So the db update could
> be signed with a completely different KEK than the one loaded into the KEK
> variable, and it would still be accepted.
>
> -Bill
>
>
>
>> TIA!!
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> --
> =============================================================================
> -Bill Paul            (510) 749-2329 | Senior Member of Technical Staff,
>                  wpaul@windriver.com | Master of Unix-Fu - Wind River Systems
> =============================================================================
>    "I put a dollar in a change machine. Nothing changed." - George Carlin
> =============================================================================