From: Bill Paul <wpaul@windriver.com>
To: <edk2-devel@lists.01.org>
Subject: Re: Set "db" variable in secure boot setup mode still requires generating PKCS#7?
Date: Tue, 1 May 2018 14:25:23 -0700 [thread overview]
Message-ID: <201805011425.24074.wpaul@windriver.com> (raw)
In-Reply-To: <CAGRSmLsfL7REVS9EtJD7FwNbHp-ZvP2-jOB3SWw-rX9axxf08w@mail.gmail.com>
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
=============================================================================
next prev parent reply other threads:[~2018-05-01 21:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-01 21:13 Set "db" variable in secure boot setup mode still requires generating PKCS#7? David F.
2018-05-01 21:25 ` Bill Paul [this message]
2018-05-02 2:23 ` David F.
2018-05-02 10:21 ` Laszlo Ersek
2018-05-02 16:26 ` David F.
2018-05-03 3:09 ` Long, Qin
2018-05-20 19:54 ` David F.
2018-05-21 1:46 ` Zhang, Chao B
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201805011425.24074.wpaul@windriver.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox