[PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework
Mimi Zohar
zohar at linux.ibm.com
Wed Oct 21 03:21:00 UTC 2020
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
More information about the Linux-security-module-archive
mailing list