Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: > > On Dec 10, 2020, at 2:49 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > > > > Eric Snowberg <eric.snowberg@xxxxxxxxxx> wrote: > > > >> Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID > >> is found, it is added as an asymmetrical key to the .blacklist keyring. > >> Anytime the .platform keyring is used, the keys in the .blacklist keyring > >> are referenced, if a matching key is found, the key will be rejected. > > > > Ummm... Why this way and not as a blacklist key which takes up less space? > > I'm guessing that you're using the key chain matching logic. We really only > > need to blacklist the key IDs. > > I implemented it this way so that certs in the dbx would only impact > the .platform keyring. I was under the impression we didn’t want to have > Secure Boot UEFI db/dbx certs dictate keyring functionality within the kernel > itself. Meaning if we have a matching dbx cert in any other keyring (builtin, > secondary, ima, etc.), it would be allowed. If that is not how you’d like to > see it done, let me know and I’ll make the change. I wonder if that is that the right thing to do. I guess this is a policy decision and may depend on the particular user. > > Also, what should happen if a revocation cert rejected by the blacklist? > > I’m not sure I understand the question. How would it be rejected? The SHA256 of a revocation cert being loaded could match an already-blacklisted SHA256 sum, either compiled in or already loaded from UEFI. David
