Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries
From:   Eric Snowberg <eric.snowberg@oracle.com>
In-Reply-To: <1360578.1607593748@warthog.procyon.org.uk>
Date:   Thu, 10 Dec 2020 11:56:58 -0700
Cc:     dwmw2@infradead.org,
        Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
        herbert@gondor.apana.org.au, davem@davemloft.net,
        jmorris@namei.org, serge@hallyn.com, nayna@linux.ibm.com,
        Mimi Zohar <zohar@linux.ibm.com>, erichte@linux.ibm.com,
        mpe@ellerman.id.au, keyrings@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        Eric Snowberg <eric.snowberg@oracle.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E090372C-06A3-4991-8FC3-F06A0DA60729@oracle.com>
References: <20200916004927.64276-1-eric.snowberg@oracle.com>
 <1360578.1607593748@warthog.procyon.org.uk>
To:     David Howells <dhowells@redhat.com>
Precedence: bulk


> On Dec 10, 2020, at 2:49 AM, David Howells <dhowells@redhat.com> =
wrote:
>=20
> Eric Snowberg <eric.snowberg@oracle.com> wrote:
>=20
>> 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.
>=20
> 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=20
the .platform keyring. I was under the impression we didn=E2=80=99t want =
to have=20
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=E2=80=99=
d like to=20
see it done, let me know and I=E2=80=99ll make the change.

> Also, what should happen if a revocation cert rejected by the =
blacklist?

I=E2=80=99m not sure I understand the question. How would it be =
rejected?

>> +int mark_key_revocationlisted(const char *data, size_t size)
>=20
> Hmmm...  The name looks wrong, but I can see the potential issue that =
kernel
> keys can actually be marked revoked as a separate concept.  How about
> add_key_to_revocation_list() and is_key_on_revocation_list().

I'll update the names in the next version.

Thanks.