To: Sumit Garg <firstname.lastname@example.org>,
Ahmad Fatoum <email@example.com>
Cc: James Bottomley <firstname.lastname@example.org>,
Jarkko Sakkinen <email@example.com>,
Mimi Zohar <firstname.lastname@example.org>,
David Howells <email@example.com>,
James Morris <firstname.lastname@example.org>,
"Serge E . Hallyn" <email@example.com>,
"open list:ASYMMETRIC KEYS" <firstname.lastname@example.org>,
"open list:SECURITY SUBSYSTEM"
Linux Kernel Mailing List <email@example.com>,
Pengutronix Kernel Team <firstname.lastname@example.org>
Subject: Re: [PATCH] KEYS: trusted: Fix trusted key backends when building as module
Date: Mon, 19 Jul 2021 11:13:35 +0200 [thread overview]
Message-ID: <20210719091335.vwfebcpkf4pag3wm@wrt> (raw)
On 13:36 19.07.21, Sumit Garg wrote:
> On Mon, 19 Jul 2021 at 12:40, Ahmad Fatoum <email@example.com> wrote:
> > Hello Andreas,
> > On 16.07.21 10:17, Andreas Rammhold wrote:
> > > Before this commit the kernel could end up with no trusted key sources
> > > even thought both of the currently supported backends (tpm & tee) were
> > > compoiled as modules. This manifested in the trusted key type not being
> > > registered at all.
> > I assume (TPM) trusted key module use worked before the TEE rework? If so,
> > an appropriate Fixes: Tag would then be in order.
> > > 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_ENABLE(…) macro we to test for both cases.
> > It looks to me like you could now provoke a link error if TEE is a module
> > and built-in trusted key core tries to link against trusted_key_tee_ops.
> That's true.
> > One solution for that IS_REACHABLE(). Another is to address the root cause,
> > which is the inflexible trusted keys Kconfig description:
> > - Trusted keys despite TEE support can still only be built when TCG_TPM is enabled
> > - There is no support to have TEE or TPM enabled without using those for
> > enabled trusted keys as well
> > - As you noticed, module build of the backend has issues
> > I addressed these three issues in a patch, a month ago, but have yet to
> > receive feedback.
> That's an oversight on my part since this patch was part of the new
> CAAM trust source patch-set. Although I do admit that it was on my
> TODO list. So I have provided some feedback on that patch. Can you
> post the next version as an independent fix patch?
Thank you both for the feedback. In light of thes feedback and the
patchset that Ahmad posted I'll not address the issue and not send a v2
I'll try to squeeze in some time to test the other patch and provide
next prev parent reply other threads:[~2021-07-19 9:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-16 8:17 [PATCH] KEYS: trusted: Fix trusted key backends when building as module Andreas Rammhold
2021-07-19 6:26 ` Sumit Garg
2021-07-19 7:10 ` Ahmad Fatoum
2021-07-19 8:06 ` Sumit Garg
2021-07-19 9:13 ` andreas [this message]
2021-07-27 2:57 ` Jarkko Sakkinen
2021-07-27 2:55 ` Jarkko Sakkinen
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).