From: Mimi Zohar <zohar@linux.ibm.com> To: Sumit Garg <sumit.garg@linaro.org>, jarkko.sakkinen@linux.intel.com, jejb@linux.ibm.com Cc: dhowells@redhat.com, jens.wiklander@linaro.org, corbet@lwn.net, jmorris@namei.org, serge@hallyn.com, casey@schaufler-ca.com, janne.karhunen@gmail.com, daniel.thompson@linaro.org, Markus.Wamser@mixed-mode.de, lhinds@redhat.com, keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, op-tee@lists.trustedfirmware.org Subject: Re: [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework Date: Tue, 20 Oct 2020 23:21:00 -0400 [thread overview] Message-ID: <8e07f9401c9f7e18fb1453b7b290472c0049c6e6.camel@linux.ibm.com> (raw) In-Reply-To: <1602065268-26017-2-git-send-email-sumit.garg@linaro.org> On Wed, 2020-10-07 at 15:37 +0530, Sumit Garg wrote: > +/* > + * trusted_destroy - clear and free the key's payload > + */ > +static void trusted_destroy(struct key *key) > +{ > + kfree_sensitive(key->payload.data[0]); > +} > + > +struct key_type key_type_trusted = { > + .name = "trusted", > + .instantiate = trusted_instantiate, > + .update = trusted_update, > + .destroy = trusted_destroy, > + .describe = user_describe, > + .read = trusted_read, > +}; > +EXPORT_SYMBOL_GPL(key_type_trusted); > + > +static int __init init_trusted(void) > +{ > + int i, ret = 0; > + > + for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) { > + if (trusted_key_source && > + strncmp(trusted_key_source, trusted_key_sources[i].name, > + strlen(trusted_key_sources[i].name))) > + continue; > + > + trusted_key_ops = trusted_key_sources[i].ops; > + > + ret = trusted_key_ops->init(); > + if (!ret) > + break; > + } In the case when the module paramater isn't specified and both TPM and TEE are enabled, trusted_key_ops is set to the last source initialized. After patch 2/4, the last trusted source initialized is TEE. If the intention is to limit it to either TPM or TEE, then trusted_key_ops should have a default value, which could be overwritten at runtime. That would address Luke Hind's concerns of making the decision at compile time. trusted_key_ops should be defined as __ro_after_init, like is currently done for other LSM structures. > + > + /* > + * encrypted_keys.ko depends on successful load of this module even if > + * trusted key implementation is not found. > + */ > + if (ret == -ENODEV) > + return 0; > + > + return ret; > +} > + > +static void __exit cleanup_trusted(void) > +{ > + trusted_key_ops->exit(); If the intention is really to support both TPM and TEE trusted keys at the same time, as James suggested, then the same "for" loop as in init_trusted() is needed here and probably elsewhere. thanks, Mimi
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com> To: Sumit Garg <sumit.garg@linaro.org>, jarkko.sakkinen@linux.intel.com, jejb@linux.ibm.com Cc: linux-security-module@vger.kernel.org, daniel.thompson@linaro.org, op-tee@lists.trustedfirmware.org, corbet@lwn.net, janne.karhunen@gmail.com, linux-doc@vger.kernel.org, jmorris@namei.org, linux-kernel@vger.kernel.org, dhowells@redhat.com, lhinds@redhat.com, keyrings@vger.kernel.org, Markus.Wamser@mixed-mode.de, casey@schaufler-ca.com, linux-integrity@vger.kernel.org, jens.wiklander@linaro.org, linux-arm-kernel@lists.infradead.org, serge@hallyn.com Subject: Re: [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework Date: Tue, 20 Oct 2020 23:21:00 -0400 [thread overview] Message-ID: <8e07f9401c9f7e18fb1453b7b290472c0049c6e6.camel@linux.ibm.com> (raw) In-Reply-To: <1602065268-26017-2-git-send-email-sumit.garg@linaro.org> On Wed, 2020-10-07 at 15:37 +0530, Sumit Garg wrote: > +/* > + * trusted_destroy - clear and free the key's payload > + */ > +static void trusted_destroy(struct key *key) > +{ > + kfree_sensitive(key->payload.data[0]); > +} > + > +struct key_type key_type_trusted = { > + .name = "trusted", > + .instantiate = trusted_instantiate, > + .update = trusted_update, > + .destroy = trusted_destroy, > + .describe = user_describe, > + .read = trusted_read, > +}; > +EXPORT_SYMBOL_GPL(key_type_trusted); > + > +static int __init init_trusted(void) > +{ > + int i, ret = 0; > + > + for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) { > + if (trusted_key_source && > + strncmp(trusted_key_source, trusted_key_sources[i].name, > + strlen(trusted_key_sources[i].name))) > + continue; > + > + trusted_key_ops = trusted_key_sources[i].ops; > + > + ret = trusted_key_ops->init(); > + if (!ret) > + break; > + } In the case when the module paramater isn't specified and both TPM and TEE are enabled, trusted_key_ops is set to the last source initialized. After patch 2/4, the last trusted source initialized is TEE. If the intention is to limit it to either TPM or TEE, then trusted_key_ops should have a default value, which could be overwritten at runtime. That would address Luke Hind's concerns of making the decision at compile time. trusted_key_ops should be defined as __ro_after_init, like is currently done for other LSM structures. > + > + /* > + * encrypted_keys.ko depends on successful load of this module even if > + * trusted key implementation is not found. > + */ > + if (ret == -ENODEV) > + return 0; > + > + return ret; > +} > + > +static void __exit cleanup_trusted(void) > +{ > + trusted_key_ops->exit(); If the intention is really to support both TPM and TEE trusted keys at the same time, as James suggested, then the same "for" loop as in init_trusted() is needed here and probably elsewhere. thanks, Mimi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-10-21 3:21 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-07 10:07 [PATCH v7 0/4] Introduce TEE based Trusted Keys support Sumit Garg 2020-10-07 10:19 ` Sumit Garg 2020-10-07 10:07 ` Sumit Garg 2020-10-07 10:07 ` [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg 2020-10-07 10:19 ` Sumit Garg 2020-10-07 10:07 ` Sumit Garg 2020-10-13 1:43 ` Jarkko Sakkinen 2020-10-13 1:43 ` Jarkko Sakkinen 2020-10-13 1:43 ` Jarkko Sakkinen 2020-10-13 10:53 ` Sumit Garg 2020-10-13 10:53 ` Sumit Garg 2020-10-13 10:53 ` Sumit Garg 2020-10-13 11:59 ` Jarkko Sakkinen 2020-10-13 11:59 ` Jarkko Sakkinen 2020-10-13 11:59 ` Jarkko Sakkinen 2020-10-14 5:04 ` Sumit Garg 2020-10-14 5:16 ` Sumit Garg 2020-10-14 5:04 ` Sumit Garg 2020-10-21 3:21 ` Mimi Zohar [this message] 2020-10-21 3:21 ` Mimi Zohar 2020-10-21 5:46 ` Sumit Garg 2020-10-21 5:46 ` Sumit Garg 2020-10-21 12:25 ` Mimi Zohar 2020-10-21 12:25 ` Mimi Zohar 2020-10-22 11:40 ` Sumit Garg 2020-10-22 11:40 ` Sumit Garg 2020-10-07 10:07 ` [PATCH v7 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg 2020-10-07 10:19 ` Sumit Garg 2020-10-07 10:07 ` Sumit Garg 2020-10-13 1:52 ` Jarkko Sakkinen 2020-10-13 1:52 ` Jarkko Sakkinen 2020-10-13 1:52 ` Jarkko Sakkinen 2020-10-13 11:01 ` Sumit Garg 2020-10-13 11:13 ` Sumit Garg 2020-10-13 11:01 ` Sumit Garg 2020-10-07 10:07 ` [PATCH v7 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg 2020-10-07 10:19 ` Sumit Garg 2020-10-07 10:07 ` Sumit Garg 2020-10-07 10:07 ` [PATCH v7 4/4] MAINTAINERS: Add entry for TEE based Trusted Keys Sumit Garg 2020-10-07 10:19 ` Sumit Garg 2020-10-07 10:07 ` Sumit Garg 2020-10-13 2:21 ` Jarkko Sakkinen 2020-10-13 2:21 ` Jarkko Sakkinen 2020-10-13 2:21 ` Jarkko Sakkinen 2020-10-13 11:28 ` Sumit Garg 2020-10-13 11:40 ` Sumit Garg 2020-10-13 11:28 ` Sumit Garg 2020-10-13 13:40 ` Jarkko Sakkinen 2020-10-13 13:40 ` Jarkko Sakkinen 2020-10-13 13:40 ` Jarkko Sakkinen 2020-10-14 5:06 ` Sumit Garg 2020-10-14 5:18 ` Sumit Garg 2020-10-14 5:06 ` 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=8e07f9401c9f7e18fb1453b7b290472c0049c6e6.camel@linux.ibm.com \ --to=zohar@linux.ibm.com \ --cc=Markus.Wamser@mixed-mode.de \ --cc=casey@schaufler-ca.com \ --cc=corbet@lwn.net \ --cc=daniel.thompson@linaro.org \ --cc=dhowells@redhat.com \ --cc=janne.karhunen@gmail.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=jejb@linux.ibm.com \ --cc=jens.wiklander@linaro.org \ --cc=jmorris@namei.org \ --cc=keyrings@vger.kernel.org \ --cc=lhinds@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=op-tee@lists.trustedfirmware.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: linkBe 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.