All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Andreas Rammhold <andreas@rammhold.de>
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>,
	James Bottomley <jejb@linux.ibm.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	David Howells <dhowells@redhat.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Sumit Garg <sumit.garg@linaro.org>,
	linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] KEYS: trusted: Fix trusted key backends when building as module
Date: Mon, 27 Sep 2021 17:31:09 -0400	[thread overview]
Message-ID: <81602197662f3e6d032103bd1ac3690342544b7e.camel@linux.ibm.com> (raw)
In-Reply-To: <20210927205521.7c4psu4vz5eoyfnf@wrt>

On Mon, 2021-09-27 at 22:55 +0200, Andreas Rammhold wrote:
> On 16:33 27.09.21, Mimi Zohar wrote:
> > On Mon, 2021-09-27 at 22:08 +0200, Andreas Rammhold wrote:
> > > On 07:27 27.09.21, Mimi Zohar wrote:
> > > > On Mon, 2021-09-27 at 10:51 +0200, Andreas Rammhold wrote:
> > > > > On 09:47 13.09.21, Ahmad Fatoum wrote:
> > > > > > Dear trusted key maintainers,
> > > > > > 
> > > > > > On 30.07.21 03:28, Andreas Rammhold wrote:
> > > > > > > Before this commit the kernel could end up with no trusted key sources
> > > > > > > even though both of the currently supported backends (TPM and TEE) were
> > > > > > > compiled as modules. This manifested in the trusted key type not being
> > > > > > > registered at all.
> > > > > > > 
> > > > > > > When checking if a CONFIG_… preprocessor variable is defined we only
> > > > > > > test for the builtin (=y) case and not the module (=m) case. By using
> > > > > > > the IS_REACHABLE() macro we do test for both cases.
> > > > > > > 
> > > > > > > Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> > > > > > > Signed-off-by: Andreas Rammhold <andreas@rammhold.de>
> > > > > > > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> > > > > > Does anyone intend to pick this up?
> > > > > 
> > > > > Did this end up in any tree by now? I am wondering if I should resend
> > > > > the patch instead. Perhaps it was just overlooked?
> > > > 
> > > > For EVM environments only using trusted and encrypted keys, not file
> > > > signatures, the trusted key is needed to decrypt the "master" key in
> > > > order to verify kernel modules.
> > > 
> > > So what you are saying is that right now (before this patch & after this
> > > patch) you could compile a kernel that wouldn't be able to load any
> > > modules when the trusted keychain part is built as module?
> > 
> > Before this patch, trusted and encrypted keys are builtin, so verifying
> > kernel modules with security.evm containing an EVM hmac would succeed. 
> > Afterwards it would fail, as there's a dependency on the trusted key to
> > verify the integrity of the trusted key module.
> 
> But building with =m was a valid configuration which is the original
> reason for me submitting the patch. So perhaps this should not be
> allowed to be a module then?

My mistake.  Trusted and encrypted key types have always been defined
as tristate.  Only when EVM selects encrypted keys, and by extension
trusted keys, are they builtin.

Mimi


  reply	other threads:[~2021-09-27 21:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-30  1:28 [PATCH v3] KEYS: trusted: Fix trusted key backends when building as module Andreas Rammhold
2021-07-30  4:54 ` Sumit Garg
2021-07-30  6:14 ` Ahmad Fatoum
2021-09-13  7:47 ` Ahmad Fatoum
2021-09-27  8:51   ` Andreas Rammhold
2021-09-27 11:27     ` Mimi Zohar
2021-09-27 20:08       ` Andreas Rammhold
2021-09-27 20:33         ` Mimi Zohar
2021-09-27 20:55           ` Andreas Rammhold
2021-09-27 21:31             ` Mimi Zohar [this message]
2021-10-02 21:47               ` Andreas Rammhold
2021-10-11 10:19                 ` Ahmad Fatoum

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=81602197662f3e6d032103bd1ac3690342544b7e.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=a.fatoum@pengutronix.de \
    --cc=andreas@rammhold.de \
    --cc=dhowells@redhat.com \
    --cc=jarkko@kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=sumit.garg@linaro.org \
    /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.