[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7265798627defd6111af4e3a863b8525b07c511d.camel@linux.ibm.com>
Date: Mon, 28 Mar 2022 09:28:14 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: joeyli <jlee@...e.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Sven Schnelle <svens@...ux.ibm.com>,
Philipp Rudo <prudo@...hat.com>, Baoquan He <bhe@...hat.com>,
Alexander Egorenkov <egorenar@...ux.ibm.com>,
AKASHI Takahiro <takahiro.akashi@...aro.org>,
James Morse <james.morse@....com>,
Dave Young <dyoung@...hat.com>,
Kairui Song <kasong@...hat.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-s390@...r.kernel.org, linux-modules@...r.kernel.org,
keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
stable@...nel.org, Eric Snowberg <eric.snowberg@...cle.com>,
Michal Suchánek <msuchanek@...e.de>,
Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for
signature verification
On Mon, 2022-03-28 at 18:15 +0800, joeyli wrote:
Hi Joey,
> Hi Mimi,
>
> Sorry for bother you for this old topic.
Cc'ing Luis the kernel modules maintainer.
>
> On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
> > Hello,
> >
> > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > [Cc'ing Eric Snowberg]
> > >
> > > Hi Michal,
> > >
> > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > adds support for use of platform keyring in kexec verification but
> > > > support for modules is missing.
> > > >
> > > > Add support for verification of modules with keys from platform keyring
> > > > as well.
> > >
> > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > using them is limited to verifying the kexec kernel image, nothing
> > > else.
> >
> > Why is the platform keyring limited to kexec, and nothing else?
> >
> > It should either be used for everything or for nothing. You have the
> > option to compile it in and then it should be used, and the option to
> > not compile it in and then it cannot be used.
> >
> > There are two basic use cases:
> >
> > (1) there is a vendor key which is very hard to use so you sign
> > something small and simple like shim with the vendor key, and sign your
> > kernel and modules with your own key that's typically enrolled with shim
> > MOK, and built into the kernel.
> >
> > (2) you import your key into the firmware, and possibly disable the
> > vendor key. You can load the kernel directly without shim, and then your
> > signing key is typically in the platform keyring and built into the
> > kernel.
> >
>
> In the second use case, if user can enroll their own key to db either before
> or after hardware shipping. And they don't need shim because they removed
> Microsoft or OEM/ODM keys. Why kernel can not provide a Kconfig option to
> them for trusting db keys for verifying kernel module, or for IMA (using CA
> in db)?
>
> In the above use case for distro, partner doesn't need to re-compiler distro
> kernel. They just need to re-sign distro kernel and modules. Which means
> that the partner trusted distro. Then the partner's key in db can be used to
> verify kernel image and also kernel module without shim involve.
>From what I understand, distros don't want customers resigning their
kernels. If they did, then they could have enabled the
CONFIG_SYSTEM_EXTRA_CERTIFICATE, which would load the keys onto the
"builtin" keyring, and anything signed by those keys could be loaded
onto the secondary keyring. (Of course CONFIG_SYSTEM_EXTRA_CERTIFICATE
would need to be fixed/updated.)
We've gone through "what if" scenarios before. My response then, as
now, is post it as a patch with the real motivation for such a change.
thanks,
Mimi
Powered by blists - more mailing lists