All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.