From: Jarkko Sakkinen <jarkko@kernel.org>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
linux-integrity <linux-integrity@vger.kernel.org>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
dwmw2@infradead.org, herbert@gondor.apana.org.au,
davem@davemloft.net, jmorris@namei.org, serge@hallyn.com,
nayna@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,
James.Bottomley@hansenpartnership.com
Subject: Re: [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries
Date: Sat, 30 Jan 2021 12:24:40 +0200 [thread overview]
Message-ID: <YBUz6Cbx/ckG8Zjj@kernel.org> (raw)
In-Reply-To: <86CE3924-E36F-44FD-A259-3CC7E69D3EAC@oracle.com>
On Wed, Jan 27, 2021 at 08:41:29AM -0700, Eric Snowberg wrote:
>
> > On Jan 27, 2021, at 7:03 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > [Cc'ing linux-integrity]
> >
> > On Wed, 2021-01-27 at 11:46 +0000, David Howells wrote:
> >> Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>
> >>>> I suppose a user space tool could be created. But wouldn’t what is
> >>>> currently done in the kernel in this area need to be removed?
> >>>
> >>> Right. I don't think this was a great idea in the first place to
> >>> do to the kernel but since it exists, I guess the patch does make
> >>> sense.
> >>
> >> This information needs to be loaded from the UEFI tables before the system
> >> starts loading any kernel modules or running any programs (if we do
> >> verification of such, which I think IMA can do).
> >
> > There needs to a clear distinction between the pre-boot and post-boot
> > keys. UEFI has its own trust model, which should be limited to UEFI.
> > The .platform keyring was upstreamed and limited to verifying the kexec
> > kernel image. Any other usage of the .platform keyring keys is
> > abusing its intended purpose.
> >
> > The cover letter says, "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." I don't have a problem with loading
> > the UEFI X509 dbx entries as long as its usage is limited to verifying
> > the kexec kernel image.
>
> Correct, with my patch, when EFI_CERT_X509_GUID entries are found in the
> dbx, they will only be used during kexec. I believe the latest dbx file on
> uefi.org contains three of these entires.
>
> Based on my understanding of why the platform keyring was introduced,
> I intentionally only used these for kexec. I do question the current
> upstream mainline code though. Currently, when EFI_CERT_X509_SHA256_GUID
> or EFI_CERT_SHA256_GUID entries are found in the dbx, they are applied
> everywhere. It seems like there should be a dbx revocation keyring
> equivalent to the current platform keyring that is only used for pre-boot.
>
> If that is a direction you would like to see this go in the future, let
> me know, I’d be happy to work on it.
I would tend to agree with this.
/Jarkko
next prev parent reply other threads:[~2021-01-30 10:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-16 0:49 [PATCH v4] certs: Add EFI_CERT_X509_GUID support for dbx entries Eric Snowberg
2020-09-16 0:49 ` Eric Snowberg
2020-09-16 18:09 ` Jarkko Sakkinen
2020-09-16 18:09 ` Jarkko Sakkinen
2020-12-10 9:49 ` David Howells
2020-12-10 18:56 ` Eric Snowberg
2021-01-12 14:57 ` David Howells
2021-01-13 20:41 ` Jarkko Sakkinen
2021-01-14 0:11 ` Eric Snowberg
2021-01-15 9:15 ` Jarkko Sakkinen
2021-01-15 16:49 ` Eric Snowberg
2021-01-20 11:26 ` Jarkko Sakkinen
2021-01-20 22:13 ` Eric Snowberg
2021-01-21 0:36 ` Jarkko Sakkinen
2021-01-27 11:46 ` David Howells
2021-01-27 14:03 ` Mimi Zohar
2021-01-27 15:41 ` Eric Snowberg
2021-01-28 4:13 ` Nayna
2021-01-30 10:24 ` Jarkko Sakkinen [this message]
2021-01-29 23:27 ` Jarkko Sakkinen
2021-01-12 17:10 ` David Howells
2021-01-12 19:13 ` Eric Snowberg
2021-01-15 17:21 ` James Bottomley
2021-01-15 23:01 ` Eric Snowberg
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-all 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=YBUz6Cbx/ckG8Zjj@kernel.org \
--to=jarkko@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=eric.snowberg@oracle.com \
--cc=erichte@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jmorris@namei.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=nayna@linux.ibm.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.