From: Jarkko Sakkinen <jarkko@kernel.org>
To: Sumit Garg <sumit.garg@linaro.org>
Cc: keyrings@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
stable@vger.kernel.org, James Bottomley <jejb@linux.ibm.com>,
Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"open list:KEYS-TRUSTED" <linux-integrity@vger.kernel.org>,
"open list:SECURITY SUBSYSTEM"
<linux-security-module@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KEYS: trusted: Rollback init_trusted() consistently
Date: Wed, 11 Oct 2023 13:12:02 +0300 [thread overview]
Message-ID: <186a4b62517ead88df8c3c0e9e9585e88f9a6fd8.camel@kernel.org> (raw)
In-Reply-To: <CAFA6WYMdrCfqMVExYBbhCK7vUSQffyUfSWpQO0=HeQc6Edz9OA@mail.gmail.com>
On Wed, 2023-10-11 at 11:27 +0530, Sumit Garg wrote:
> On Wed, 11 Oct 2023 at 04:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > Do bind neither static calls nor trusted_key_exit() before a successful
> > init, in order to maintain a consistent state. In addition, depart the
> > init_trusted() in the case of a real error (i.e. getting back something
> > else than -ENODEV).
> >
> > Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Closes: https://lore.kernel.org/linux-integrity/CAHk-=whOPoLaWM8S8GgoOPT7a2+nMH5h3TLKtn=R_3w4R1_Uvg@mail.gmail.com/
> > Cc: stable@vger.kernel.org # v5.13+
> > Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework")
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > security/keys/trusted-keys/trusted_core.c | 20 ++++++++++----------
> > 1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> > index 85fb5c22529a..fee1ab2c734d 100644
> > --- a/security/keys/trusted-keys/trusted_core.c
> > +++ b/security/keys/trusted-keys/trusted_core.c
> > @@ -358,17 +358,17 @@ static int __init init_trusted(void)
> > if (!get_random)
> > get_random = kernel_get_random;
> >
> > - static_call_update(trusted_key_seal,
> > - trusted_key_sources[i].ops->seal);
> > - static_call_update(trusted_key_unseal,
> > - trusted_key_sources[i].ops->unseal);
> > - static_call_update(trusted_key_get_random,
> > - get_random);
> > - trusted_key_exit = trusted_key_sources[i].ops->exit;
> > - migratable = trusted_key_sources[i].ops->migratable;
> > -
> > ret = trusted_key_sources[i].ops->init();
> > - if (!ret)
> > + if (!ret) {
> > + static_call_update(trusted_key_seal, trusted_key_sources[i].ops->seal);
> > + static_call_update(trusted_key_unseal, trusted_key_sources[i].ops->unseal);
> > + static_call_update(trusted_key_get_random, get_random);
> > +
> > + trusted_key_exit = trusted_key_sources[i].ops->exit;
> > + migratable = trusted_key_sources[i].ops->migratable;
> > + }
> > +
> > + if (!ret || ret != -ENODEV)
>
> As mentioned in the other thread, we should allow other trust sources
> to be initialized if the primary one fails.
I sent the patch before I received that response but here's what you
wrote:
"We should give other trust sources a chance to register for trusted
keys if the primary one fails."
1. This condition is lacking an inline comment.
2. Neither this response or the one that you pointed out has any
explanation why for any system failure the process should
continue.
You should really know the situations (e.g. list of posix error
code) when the process can continue and "allow list" those. This
way way too abstract. It cannot be let all possible system failures
pass.
Can you e.g. explain a legit use case when something else is
returned than -ENODEV but it is cool and we can continue in
some real world use case?
BR, Jarkko
next prev parent reply other threads:[~2023-10-11 10:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 23:16 [PATCH] KEYS: trusted: Rollback init_trusted() consistently Jarkko Sakkinen
2023-10-11 5:57 ` Sumit Garg
2023-10-11 10:12 ` Jarkko Sakkinen [this message]
2023-10-11 10:34 ` Jarkko Sakkinen
2023-10-11 12:17 ` Sumit Garg
2023-10-11 12:36 ` Jarkko Sakkinen
2023-10-11 12:55 ` Sumit Garg
2023-10-11 13:06 ` Jarkko Sakkinen
2023-10-11 13:07 ` Jarkko Sakkinen
2023-10-11 13:42 ` Sumit Garg
2023-10-11 13:55 ` Jarkko Sakkinen
2023-10-11 14:05 ` Jarkko Sakkinen
2023-10-12 7:41 ` Sumit Garg
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=186a4b62517ead88df8c3c0e9e9585e88f9a6fd8.camel@kernel.org \
--to=jarkko@kernel.org \
--cc=dhowells@redhat.com \
--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=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=stable@vger.kernel.org \
--cc=sumit.garg@linaro.org \
--cc=torvalds@linux-foundation.org \
--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 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).