[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YjLlYTs+2ep80zoK@iki.fi>
Date: Thu, 17 Mar 2022 09:38:09 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Nayna <nayna@...ux.vnet.ibm.com>
Cc: Nageswara Sastry <rnsastry@...ux.ibm.com>,
Nayna Jain <nayna@...ux.ibm.com>,
linux-integrity@...r.kernel.org, keyrings@...r.kernel.org,
dhowells@...hat.com, zohar@...ux.ibm.com,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, dimitri.ledkov@...onical.com,
seth@...shee.me, Masahiro Yamada <masahiroy@...nel.org>
Subject: Re: [PATCH v11 0/4] integrity: support including firmware
".platform" keys at build time
On Fri, Mar 11, 2022 at 04:03:12PM -0500, Nayna wrote:
>
> On 3/11/22 11:42, Jarkko Sakkinen wrote:
> > On Fri, 2022-03-11 at 10:11 +0530, Nageswara Sastry wrote:
> > >
> > > On 11/03/22 3:14 am, Nayna Jain wrote:
> > > > Some firmware support secure boot by embedding static keys to verify the
> > > > Linux kernel during boot. However, these firmware do not expose an
> > > > interface for the kernel to load firmware keys onto the ".platform"
> > > > keyring, preventing the kernel from verifying the kexec kernel image
> > > > signature.
> > > >
> > > > This patchset exports load_certificate_list() and defines a new function
> > > > load_builtin_platform_cert() to load compiled in certificates onto the
> > > > ".platform" keyring.
> > > >
> > > > Changelog:
> > > > v11:
> > > > * Added a new patch to conditionally build extract-cert if
> > > > PLATFORM_KEYRING is enabled.
> > > >
> > > Tested the following four patches with and with out setting
> > > CONFIG_INTEGRITY_PLATFORM_KEYS
> > >
> > > Tested-by: Nageswara R Sastry <rnsastry@...ux.ibm.com>
> > OK, I added it:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git
>
> Thanks Jarkko. Masahiro Yamada would prefer to revert the original commit
> 340a02535ee785c64c62a9c45706597a0139e972 i.e. move extract-cert back to the
> scripts/ directory.
>
> I am just posting v12 which includes Masahiro feedback. Nageswara has
> already tested v12 version as well.
>
> I am fine either way 1.) Adding v11 and then separately handling of
> reverting of the commit or 2.) Adding v12 version which includes the revert.
> I leave the decision on you as to which one to upstream.
>
> Thanks & Regards,
>
> - Nayna
>
I already sent PR for v5.18. Too many late changes to include this, which
means that v12 is the way to go.
BR, Jarkko
Powered by blists - more mailing lists