* Re: [PATCH v2] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 23:25 UTC (permalink / raw)
To: linux-integrity
Cc: Eric Biggers, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, James Bottomley, Mimi Zohar,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <20251215231438.565522-1-jarkko@kernel.org>
On Tue, Dec 16, 2025 at 01:14:38AM +0200, Jarkko Sakkinen wrote:
> 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
> use should be pooled rather than directly used. This both reduces
> latency and improves its predictability.
>
> 2. Linux is better off overall if every subsystem uses the same source for
> generating the random numbers required.
>
> Thus, unset '.get_random', which causes fallback to kernel_get_random().
>
> One might argue that TPM RNG should be used so that generated trusted keys
> have the matching entropy with the TPM internally generated objects.
>
> This argument does some weight into it but as far cryptography goes, FIPS
> certification sets the exact bar, not which exact FIPS certified RNG will
> be used. Thus, the rational choice is obviously to pick the lowest latency
> path.
>
> Finally, there also some actual defence in depth benefits on using kernel
> RNG. E.g., it helps to mitigate TPM firmware bugs concerning RNG
> implementation, which do happen in the wild occasionally.
>
> Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
I noticed also some typos in the commit message.
I think I will also supplement this with a patch that unexports
tpm_get_random(), as the patch zeros the external call sites.
Full encapsulation to the driver is exactly should aim for in order to
make hwrng easier target for further optimizations.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 23:17 UTC (permalink / raw)
To: linux-integrity
Cc: Eric Biggers, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, James Bottomley, Mimi Zohar,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <20251215231438.565522-1-jarkko@kernel.org>
On Tue, Dec 16, 2025 at 01:14:38AM +0200, Jarkko Sakkinen wrote:
> 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
> use should be pooled rather than directly used. This both reduces
> latency and improves its predictability.
>
> 2. Linux is better off overall if every subsystem uses the same source for
> generating the random numbers required.
>
> Thus, unset '.get_random', which causes fallback to kernel_get_random().
>
> One might argue that TPM RNG should be used so that generated trusted keys
> have the matching entropy with the TPM internally generated objects.
>
> This argument does some weight into it but as far cryptography goes, FIPS
> certification sets the exact bar, not which exact FIPS certified RNG will
> be used. Thus, the rational choice is obviously to pick the lowest latency
> path.
>
> Finally, there also some actual defence in depth benefits on using kernel
> RNG. E.g., it helps to mitigate TPM firmware bugs concerning RNG
> implementation, which do happen in the wild occasionally.
>
> Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> ---
> v2:
> - Added Eric's reviewed-by tag.
> - Addressed concerns from James by writing more details to the commit
> message and documenting random number generation to the source
> code.
> ---
> security/keys/trusted-keys/trusted_tpm1.c | 6 ------
> security/keys/trusted-keys/trusted_tpm2.c | 9 +++++++++
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 636acb66a4f6..33b7739741c3 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -936,11 +936,6 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
> return ret;
> }
>
> -static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
> -{
> - return tpm_get_random(chip, key, key_len);
> -}
> -
> static int __init init_digests(void)
> {
> int i;
> @@ -992,6 +987,5 @@ struct trusted_key_ops trusted_key_tpm_ops = {
> .init = trusted_tpm_init,
> .seal = trusted_tpm_seal,
> .unseal = trusted_tpm_unseal,
> - .get_random = trusted_tpm_get_random,
> .exit = trusted_tpm_exit,
> };
> diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
> index a7ea4a1c3bed..d16be47f1305 100644
> --- a/security/keys/trusted-keys/trusted_tpm2.c
> +++ b/security/keys/trusted-keys/trusted_tpm2.c
> @@ -2,6 +2,15 @@
> /*
> * Copyright (C) 2004 IBM Corporation
> * Copyright (C) 2014 Intel Corporation
> +
> +/**
> + * DOC: Random Number Generation
> + *
> + * tpm_get_random() was previously used here as the RNG in order to have equal
> + * entropy with the objects fully inside the TPM. However, as far as goes,
> + * kernel RNG is equally fine, as long as long as it is FIPS certified. Also,
> + * using kernel RNG has the benefit of mitigating bugs in the TPM firmware
> + * associated with the RNG.
> */
Sorry, this should have gone to trusted_tpm1.c :-)
>
> #include <linux/asn1_encoder.h>
> --
> 2.39.5
>
BR, Jarkko
^ permalink raw reply
* [PATCH v2] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 23:14 UTC (permalink / raw)
To: linux-integrity
Cc: Jarkko Sakkinen, Eric Biggers, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, James Bottomley, Mimi Zohar,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM, open list
1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
use should be pooled rather than directly used. This both reduces
latency and improves its predictability.
2. Linux is better off overall if every subsystem uses the same source for
generating the random numbers required.
Thus, unset '.get_random', which causes fallback to kernel_get_random().
One might argue that TPM RNG should be used so that generated trusted keys
have the matching entropy with the TPM internally generated objects.
This argument does some weight into it but as far cryptography goes, FIPS
certification sets the exact bar, not which exact FIPS certified RNG will
be used. Thus, the rational choice is obviously to pick the lowest latency
path.
Finally, there also some actual defence in depth benefits on using kernel
RNG. E.g., it helps to mitigate TPM firmware bugs concerning RNG
implementation, which do happen in the wild occasionally.
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
v2:
- Added Eric's reviewed-by tag.
- Addressed concerns from James by writing more details to the commit
message and documenting random number generation to the source
code.
---
security/keys/trusted-keys/trusted_tpm1.c | 6 ------
security/keys/trusted-keys/trusted_tpm2.c | 9 +++++++++
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 636acb66a4f6..33b7739741c3 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -936,11 +936,6 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
return ret;
}
-static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
-{
- return tpm_get_random(chip, key, key_len);
-}
-
static int __init init_digests(void)
{
int i;
@@ -992,6 +987,5 @@ struct trusted_key_ops trusted_key_tpm_ops = {
.init = trusted_tpm_init,
.seal = trusted_tpm_seal,
.unseal = trusted_tpm_unseal,
- .get_random = trusted_tpm_get_random,
.exit = trusted_tpm_exit,
};
diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c
index a7ea4a1c3bed..d16be47f1305 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -2,6 +2,15 @@
/*
* Copyright (C) 2004 IBM Corporation
* Copyright (C) 2014 Intel Corporation
+
+/**
+ * DOC: Random Number Generation
+ *
+ * tpm_get_random() was previously used here as the RNG in order to have equal
+ * entropy with the objects fully inside the TPM. However, as far as goes,
+ * kernel RNG is equally fine, as long as long as it is FIPS certified. Also,
+ * using kernel RNG has the benefit of mitigating bugs in the TPM firmware
+ * associated with the RNG.
*/
#include <linux/asn1_encoder.h>
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2 17/17] tpm/tpm_ftpm_tee: Make use of tee bus methods
From: Jarkko Sakkinen @ 2025-12-15 22:53 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Peter Huewe, Jason Gunthorpe, Sumit Garg,
linux-integrity, op-tee, linux-kernel, Sumit Garg
In-Reply-To: <7bb98eeb8a478ca69344499f2e58016bbf787313.1765791463.git.u.kleine-koenig@baylibre.com>
On Mon, Dec 15, 2025 at 03:16:47PM +0100, Uwe Kleine-König wrote:
> The tee bus got dedicated callbacks for probe and remove.
nit: "TEE subsystem has implemented callbacks for probe() and remove()".
Or this what I presume has happened: someone has implemented new
callbacks to subsystem (vs randomly appearing from the divine
skies).
> Make use of these. This fixes a runtime warning about the driver needing
> to be converted to the bus methods.
>
> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> drivers/char/tpm/tpm_ftpm_tee.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
> index e5fbc70b0eca..20294d1953a3 100644
> --- a/drivers/char/tpm/tpm_ftpm_tee.c
> +++ b/drivers/char/tpm/tpm_ftpm_tee.c
> @@ -169,7 +169,7 @@ static int ftpm_tee_match(struct tee_ioctl_version_data *ver, const void *data)
> * Return:
> * On success, 0. On failure, -errno.
> */
> -static int ftpm_tee_probe(struct device *dev)
> +static int ftpm_tee_probe_generic(struct device *dev)
> {
> int rc;
> struct tpm_chip *chip;
> @@ -251,11 +251,18 @@ static int ftpm_tee_probe(struct device *dev)
> return rc;
> }
>
> +static int ftpm_tee_probe(struct tee_client_device *tcdev)
> +{
> + struct device *dev = &tcdev->dev;
> +
> + return ftpm_tee_probe_generic(dev);
> +}
> +
> static int ftpm_plat_tee_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> - return ftpm_tee_probe(dev);
> + return ftpm_tee_probe_generic(dev);
> }
>
> /**
> @@ -265,7 +272,7 @@ static int ftpm_plat_tee_probe(struct platform_device *pdev)
> * Return:
> * 0 always.
> */
> -static int ftpm_tee_remove(struct device *dev)
> +static void ftpm_tee_remove_generic(struct device *dev)
> {
> struct ftpm_tee_private *pvt_data = dev_get_drvdata(dev);
>
> @@ -285,15 +292,20 @@ static int ftpm_tee_remove(struct device *dev)
> tee_client_close_context(pvt_data->ctx);
>
> /* memory allocated with devm_kzalloc() is freed automatically */
> +}
>
> - return 0;
> +static void ftpm_tee_remove(struct tee_client_device *tcdev)
> +{
> + struct device *dev = &tcdev->dev;
> +
> + ftpm_tee_remove_generic(dev);
> }
>
> static void ftpm_plat_tee_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> - ftpm_tee_remove(dev);
> + ftpm_tee_remove_generic(dev);
> }
>
> /**
> @@ -335,11 +347,11 @@ static const struct tee_client_device_id optee_ftpm_id_table[] = {
> MODULE_DEVICE_TABLE(tee, optee_ftpm_id_table);
>
> static struct tee_client_driver ftpm_tee_driver = {
> + .probe = ftpm_tee_probe,
> + .remove = ftpm_tee_remove,
> .id_table = optee_ftpm_id_table,
> .driver = {
> .name = "optee-ftpm",
> - .probe = ftpm_tee_probe,
> - .remove = ftpm_tee_remove,
> },
> };
>
> --
> 2.47.3
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 16/17] tpm/tpm_ftpm_tee: Make use of tee specific driver registration
From: Jarkko Sakkinen @ 2025-12-15 22:48 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Peter Huewe, Jason Gunthorpe, Sumit Garg,
linux-integrity, op-tee, linux-kernel, Sumit Garg
In-Reply-To: <5c8d6d420338d0d028f785680520d375e8a49673.1765791463.git.u.kleine-koenig@baylibre.com>
On Mon, Dec 15, 2025 at 03:16:46PM +0100, Uwe Kleine-König wrote:
> tee_client_driver_register() is typed more strongly and cares about
> assigning the driver's bus. Similar for tee_client_driver_unregister().
>
> Make use of these functions.
>
> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> drivers/char/tpm/tpm_ftpm_tee.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
> index 4e63c30aeaf1..e5fbc70b0eca 100644
> --- a/drivers/char/tpm/tpm_ftpm_tee.c
> +++ b/drivers/char/tpm/tpm_ftpm_tee.c
> @@ -338,7 +338,6 @@ static struct tee_client_driver ftpm_tee_driver = {
> .id_table = optee_ftpm_id_table,
> .driver = {
> .name = "optee-ftpm",
> - .bus = &tee_bus_type,
> .probe = ftpm_tee_probe,
> .remove = ftpm_tee_remove,
> },
> @@ -352,7 +351,7 @@ static int __init ftpm_mod_init(void)
> if (rc)
> return rc;
>
> - rc = driver_register(&ftpm_tee_driver.driver);
> + rc = tee_client_driver_register(&ftpm_tee_driver);
> if (rc) {
> platform_driver_unregister(&ftpm_tee_plat_driver);
> return rc;
> @@ -364,7 +363,7 @@ static int __init ftpm_mod_init(void)
> static void __exit ftpm_mod_exit(void)
> {
> platform_driver_unregister(&ftpm_tee_plat_driver);
> - driver_unregister(&ftpm_tee_driver.driver);
> + tee_client_driver_unregister(&ftpm_tee_driver);
> }
>
> module_init(ftpm_mod_init);
> --
> 2.47.3
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 15/17] KEYS: trusted: Make use of tee bus methods
From: Jarkko Sakkinen @ 2025-12-15 22:04 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Sumit Garg, James Bottomley, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
linux-integrity, keyrings, linux-security-module, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <ad8aaa343c1e8523659259290f63aea8be906977.1765791463.git.u.kleine-koenig@baylibre.com>
On Mon, Dec 15, 2025 at 03:16:45PM +0100, Uwe Kleine-König wrote:
> The tee bus got dedicated callbacks for probe and remove.
> Make use of these. This fixes a runtime warning about the driver needing
> to be converted to the bus methods.
>
> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> security/keys/trusted-keys/trusted_tee.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> index 3cea9a377955..6e465c8bef5e 100644
> --- a/security/keys/trusted-keys/trusted_tee.c
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -202,9 +202,9 @@ static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> return 0;
> }
>
> -static int trusted_key_probe(struct device *dev)
> +static int trusted_key_probe(struct tee_client_device *rng_device)
> {
> - struct tee_client_device *rng_device = to_tee_client_device(dev);
> + struct device *dev = &rng_device->dev;
> int ret;
> struct tee_ioctl_open_session_arg sess_arg;
I'm sorry but cannot help saying but these not being in reverse tree
order hurts my eyes ;-)
I.e., I'd personally move declaration of sess_arg right after rng_device
despite being additional change to the scope of the patch.
That said, Sumit has the ultimate veto right here, and this not any kind
of fault in this patch so I will obviously ack the patch;
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> @@ -244,13 +244,11 @@ static int trusted_key_probe(struct device *dev)
> return ret;
> }
>
> -static int trusted_key_remove(struct device *dev)
> +static void trusted_key_remove(struct tee_client_device *dev)
> {
> unregister_key_type(&key_type_trusted);
> tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> tee_client_close_context(pvt_data.ctx);
> -
> - return 0;
> }
>
> static const struct tee_client_device_id trusted_key_id_table[] = {
> @@ -261,11 +259,11 @@ static const struct tee_client_device_id trusted_key_id_table[] = {
> MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
>
> static struct tee_client_driver trusted_key_driver = {
> + .probe = trusted_key_probe,
> + .remove = trusted_key_remove,
> .id_table = trusted_key_id_table,
> .driver = {
> .name = DRIVER_NAME,
> - .probe = trusted_key_probe,
> - .remove = trusted_key_remove,
> },
> };
>
> --
> 2.47.3
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH v2 14/17] KEYS: trusted: Migrate to use tee specific driver registration function
From: Jarkko Sakkinen @ 2025-12-15 22:01 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Sumit Garg, James Bottomley, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
linux-integrity, keyrings, linux-security-module, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <687c004c32718ba7044ffa9165f33842267a745d.1765791463.git.u.kleine-koenig@baylibre.com>
On Mon, Dec 15, 2025 at 03:16:44PM +0100, Uwe Kleine-König wrote:
> The tee subsystem recently got a set of dedicated functions to register
> (and unregister) a tee driver. Make use of them. These care for setting the
> driver's bus (so the explicit assignment can be dropped) and the driver
> owner (which is an improvement this driver benefits from).
>
> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> security/keys/trusted-keys/trusted_tee.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> index aa3d477de6db..3cea9a377955 100644
> --- a/security/keys/trusted-keys/trusted_tee.c
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -264,7 +264,6 @@ static struct tee_client_driver trusted_key_driver = {
> .id_table = trusted_key_id_table,
> .driver = {
> .name = DRIVER_NAME,
> - .bus = &tee_bus_type,
> .probe = trusted_key_probe,
> .remove = trusted_key_remove,
> },
> @@ -272,12 +271,12 @@ static struct tee_client_driver trusted_key_driver = {
>
> static int trusted_tee_init(void)
> {
> - return driver_register(&trusted_key_driver.driver);
> + return tee_client_driver_register(&trusted_key_driver);
> }
>
> static void trusted_tee_exit(void)
> {
> - driver_unregister(&trusted_key_driver.driver);
> + tee_client_driver_unregister(&trusted_key_driver);
> }
>
> struct trusted_key_ops trusted_key_tee_ops = {
> --
> 2.47.3
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 21:09 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, James Bottomley, Mimi Zohar,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM, open list,
Jason A. Donenfeld
In-Reply-To: <aUBxKqL5hFibwI3r@kernel.org>
On Mon, Dec 15, 2025 at 10:35:57PM +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 15, 2025 at 08:09:39PM +0000, Eric Biggers wrote:
> > On Sun, Dec 14, 2025 at 11:32:36PM +0200, Jarkko Sakkinen wrote:
> > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
> > > use should be pooled rather than directly used. This both reduces
> > > latency and improves its predictability.
> > >
> > > 2. Linux is better off overall if every subsystem uses the same source for
> > > the random bistream as the de-facto choice, unless *force majeure*
> > > reasons point to some other direction.
> > >
> > > In the case, of TPM there is no reason for trusted keys to invoke TPM
> > > directly.
> > >
> > > Thus, unset '.get_random', which causes fallback to kernel_get_random().
> > >
> > > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > > ---
> > > security/keys/trusted-keys/trusted_tpm1.c | 6 ------
> > > 1 file changed, 6 deletions(-)
> > >
> > > diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> > > index 636acb66a4f6..33b7739741c3 100644
> > > --- a/security/keys/trusted-keys/trusted_tpm1.c
> > > +++ b/security/keys/trusted-keys/trusted_tpm1.c
> > > @@ -936,11 +936,6 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
> > > return ret;
> > > }
> > >
> > > -static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
> > > -{
> > > - return tpm_get_random(chip, key, key_len);
> > > -}
> > > -
> > > static int __init init_digests(void)
> > > {
> > > int i;
> > > @@ -992,6 +987,5 @@ struct trusted_key_ops trusted_key_tpm_ops = {
> > > .init = trusted_tpm_init,
> > > .seal = trusted_tpm_seal,
> > > .unseal = trusted_tpm_unseal,
> > > - .get_random = trusted_tpm_get_random,
> > > .exit = trusted_tpm_exit,
> > > };
> >
> > Reviewed-by: Eric Biggers <ebiggers@kernel.org>
> >
> > Agreed that kernel code should prefer the standard Linux RNG whenever
> > possible. Note that the standard Linux RNG already incorporates entropy
> > from hardware RNGs, when available.
>
> I get also the argument of using TPM RNG here just for the sake of
> matching the creation with fully internally generated TPM objects.
>
> I'm a bit little in-between what to do with this patch.
>
> I suggested a comment to James. Other alternative would be do this
> change and update this patch with a comment:
>
> /*
> * tpm_get_random() was used previously here as the RNG in order to match
> * rng with the objects generated internally inside the TPM. However, since
> * e.g., FIPS certification requires kernel crypto and rng to be FIPS
> * certified, formally kernel_get_random() is equally legit source for
> * the random numbers.
> */
>
> It's longish but I think this fully covers the whole issue.
>
> And if there is ever need to return to this, it's a good remainder of
> the design choices.
I'll supplement the patch with that explanatory comment. I think the
previous discussions pointed out by James were useful reflection point
and that comment summarizes that discussion.
I'll add your reviewd-by to the next version, as no additional code
changes will be implemented.
I think that this discussion also implies that the callback itself is
somewhat questionable, perhaps even harmful. Same arguments apply also
to e.g., TEE trusted keys. IMHO, would be overall best for Linux to a
have a one single call path for generating random numbers.
Using combined entropy also decreases corrateral damage caused by e.g.,
a buggy TPM firmware, which does happen sometimes in the wild.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 20:35 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, James Bottomley, Mimi Zohar,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM, open list,
Jason A. Donenfeld
In-Reply-To: <20251215200939.GA10539@google.com>
On Mon, Dec 15, 2025 at 08:09:39PM +0000, Eric Biggers wrote:
> On Sun, Dec 14, 2025 at 11:32:36PM +0200, Jarkko Sakkinen wrote:
> > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
> > use should be pooled rather than directly used. This both reduces
> > latency and improves its predictability.
> >
> > 2. Linux is better off overall if every subsystem uses the same source for
> > the random bistream as the de-facto choice, unless *force majeure*
> > reasons point to some other direction.
> >
> > In the case, of TPM there is no reason for trusted keys to invoke TPM
> > directly.
> >
> > Thus, unset '.get_random', which causes fallback to kernel_get_random().
> >
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > ---
> > security/keys/trusted-keys/trusted_tpm1.c | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> > index 636acb66a4f6..33b7739741c3 100644
> > --- a/security/keys/trusted-keys/trusted_tpm1.c
> > +++ b/security/keys/trusted-keys/trusted_tpm1.c
> > @@ -936,11 +936,6 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
> > return ret;
> > }
> >
> > -static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
> > -{
> > - return tpm_get_random(chip, key, key_len);
> > -}
> > -
> > static int __init init_digests(void)
> > {
> > int i;
> > @@ -992,6 +987,5 @@ struct trusted_key_ops trusted_key_tpm_ops = {
> > .init = trusted_tpm_init,
> > .seal = trusted_tpm_seal,
> > .unseal = trusted_tpm_unseal,
> > - .get_random = trusted_tpm_get_random,
> > .exit = trusted_tpm_exit,
> > };
>
> Reviewed-by: Eric Biggers <ebiggers@kernel.org>
>
> Agreed that kernel code should prefer the standard Linux RNG whenever
> possible. Note that the standard Linux RNG already incorporates entropy
> from hardware RNGs, when available.
I get also the argument of using TPM RNG here just for the sake of
matching the creation with fully internally generated TPM objects.
I'm a bit little in-between what to do with this patch.
I suggested a comment to James. Other alternative would be do this
change and update this patch with a comment:
/*
* tpm_get_random() was used previously here as the RNG in order to match
* rng with the objects generated internally inside the TPM. However, since
* e.g., FIPS certification requires kernel crypto and rng to be FIPS
* certified, formally kernel_get_random() is equally legit source for
* the random numbers.
*/
It's longish but I think this fully covers the whole issue.
And if there is ever need to return to this, it's a good remainder of
the design choices.
>
> - Eric
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 20:25 UTC (permalink / raw)
To: James Bottomley
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <5446f517848338b4ccac8d7bbedf4cc1ed315cb4.camel@HansenPartnership.com>
On Mon, Dec 15, 2025 at 09:01:49PM +0100, James Bottomley wrote:
> On Mon, 2025-12-15 at 21:43 +0200, Jarkko Sakkinen wrote:
> [...]
> > I think there is misunderstanding with FIPS.
> >
> > Having FIPS certificated RNG in TPM matters but it only matters only
> > in the sense that callers can be FIPS certified as they use that RNG
> > as a source.
> >
> > Using FIPS certified RNG does not magically make callers be FIPS
> > ceritified actors. The data is contaminated in that sense at the
> > point when kernel acquires it.
>
> I think FIPS certification is a red herring. The point being made in
> the original thread is about RNG quality. The argument essentially
> being that the quality of the TPM RNG is known at all points in time
> but the quality of the kernel RNG (particularly at start of day when
> the entropy pool is new) is less certain.
OK, that's fair point.
I.e., using TPM2_GetRandom here makes sense, not because of FIPS
certification per se but because it is guarantees matching entropy to
other types of keys generated with TPM2_Create (as everything uses the
same RNG).
I can buy this but think it would really make sense to add a comment to
the source code.
I was thinking something along the lines of:
/*
* tpm_get_random() is used here directly instead of relying kernel's
* RNG in order to match RNGs with objects generated by TPM internally.
*/
It does not mention FIPS explicitly because I think this is already
enforcing condition and thus enough. And e.g., applies also when one
uses an emulator (and thus useful tidbit for that use and purpose).
>
> Regards,
>
> James
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Eric Biggers @ 2025-12-15 20:09 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, James Bottomley, Mimi Zohar,
open list:KEYS/KEYRINGS, open list:SECURITY SUBSYSTEM, open list,
Jason A. Donenfeld
In-Reply-To: <20251214213236.339586-1-jarkko@kernel.org>
On Sun, Dec 14, 2025 at 11:32:36PM +0200, Jarkko Sakkinen wrote:
> 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus its
> use should be pooled rather than directly used. This both reduces
> latency and improves its predictability.
>
> 2. Linux is better off overall if every subsystem uses the same source for
> the random bistream as the de-facto choice, unless *force majeure*
> reasons point to some other direction.
>
> In the case, of TPM there is no reason for trusted keys to invoke TPM
> directly.
>
> Thus, unset '.get_random', which causes fallback to kernel_get_random().
>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> ---
> security/keys/trusted-keys/trusted_tpm1.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index 636acb66a4f6..33b7739741c3 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -936,11 +936,6 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
> return ret;
> }
>
> -static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
> -{
> - return tpm_get_random(chip, key, key_len);
> -}
> -
> static int __init init_digests(void)
> {
> int i;
> @@ -992,6 +987,5 @@ struct trusted_key_ops trusted_key_tpm_ops = {
> .init = trusted_tpm_init,
> .seal = trusted_tpm_seal,
> .unseal = trusted_tpm_unseal,
> - .get_random = trusted_tpm_get_random,
> .exit = trusted_tpm_exit,
> };
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Agreed that kernel code should prefer the standard Linux RNG whenever
possible. Note that the standard Linux RNG already incorporates entropy
from hardware RNGs, when available.
- Eric
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: James Bottomley @ 2025-12-15 20:01 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <aUBk2nUpd2V8p9qc@kernel.org>
On Mon, 2025-12-15 at 21:43 +0200, Jarkko Sakkinen wrote:
[...]
> I think there is misunderstanding with FIPS.
>
> Having FIPS certificated RNG in TPM matters but it only matters only
> in the sense that callers can be FIPS certified as they use that RNG
> as a source.
>
> Using FIPS certified RNG does not magically make callers be FIPS
> ceritified actors. The data is contaminated in that sense at the
> point when kernel acquires it.
I think FIPS certification is a red herring. The point being made in
the original thread is about RNG quality. The argument essentially
being that the quality of the TPM RNG is known at all points in time
but the quality of the kernel RNG (particularly at start of day when
the entropy pool is new) is less certain.
Regards,
James
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 19:43 UTC (permalink / raw)
To: James Bottomley
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <aT_Lh8l3E2yQJYI7@kernel.org>
On Mon, Dec 15, 2025 at 10:49:15AM +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 15, 2025 at 04:55:58PM +0900, James Bottomley wrote:
> > On Mon, 2025-12-15 at 08:43 +0200, Jarkko Sakkinen wrote:
> > > On Mon, Dec 15, 2025 at 07:18:41AM +0900, James Bottomley wrote:
> > > > On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> > > > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and
> > > > > thus its use should be pooled rather than directly used. This
> > > > > both reduces latency and improves its predictability.
> > > > >
> > > > > 2. Linux is better off overall if every subsystem uses the same
> > > > > source for the random bistream as the de-facto choice, unless
> > > > > *force majeure* reasons point to some other direction.
> > > > >
> > > > > In the case, of TPM there is no reason for trusted keys to invoke
> > > > > TPM directly.
> > > >
> > > > That assertion isn't correct: you seem to have forgotten we had
> > > > this argument six or seven years ago, but even that was a reprise
> > > > of an even earlier one. Lore doesn't go back far enough for the
> > > > intermediate one on the tpm list, but the original was cc'd to
> > > > lkml:
> > > >
> > > > https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
> > > >
> > > > The decision then was to use the same random source as the key
> > > > protection. Unfortunately most of the active participants have
> > > > moved on from IBM and I don't have their current email addresses,
> > > > but the bottom line is there were good reasons to do trusted keys
> > > > this way that your assertions above don't overcome. I'm not saying
> > > > we shouldn't reconsider the situation, but we need a reasoned
> > > > debate rather than simply doing it by fiat.
> > >
> > > The way I see this is that given that kernel is not running inside
> > > TPM, FIPS certification of the RNG does not have any measurable
> > > value.
> > >
> > > Random data generation should happen as part of object creation
> > > process i.e. should be fully self-contained process within the TPM in
> > > order for FIPS to matter.
> >
> > In FIPS terms, there's no distinction between keeping the whole
> > generation process internal to the TPM and using the FIPS certified rng
> > of the TPM to source the contents of a kernel protected key. Both
> > provide equally valid, and FIPS certified data.
>
> I understand being "FIPS certified" embedding the premise that kernel
> is also FIPS certified, which covers also crypto etc. This is the case
> with enterprise kernels.
>
> I have understanding FIPS certification dies at the point when random
> data is acquired by a kernel, which is not FIPS certified. It's not
> really a safe closure.
>
> Using same code path for RNG universally should actually help with any
> certification processes.
I think there is misunderstanding with FIPS.
Having FIPS certificated RNG in TPM matters but it only matters only in
the sense that callers can be FIPS certified as they use that RNG as a
source.
Using FIPS certified RNG does not magically make callers be FIPS
ceritified actors. The data is contaminated in that sense at the point
when kernel acquires it.
BR, Jarkko
^ permalink raw reply
* [PATCH v2 17/17] tpm/tpm_ftpm_tee: Make use of tee bus methods
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Peter Huewe, Jarkko Sakkinen
Cc: Jason Gunthorpe, Sumit Garg, linux-integrity, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <cover.1765791463.git.u.kleine-koenig@baylibre.com>
The tee bus got dedicated callbacks for probe and remove.
Make use of these. This fixes a runtime warning about the driver needing
to be converted to the bus methods.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/char/tpm/tpm_ftpm_tee.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
index e5fbc70b0eca..20294d1953a3 100644
--- a/drivers/char/tpm/tpm_ftpm_tee.c
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -169,7 +169,7 @@ static int ftpm_tee_match(struct tee_ioctl_version_data *ver, const void *data)
* Return:
* On success, 0. On failure, -errno.
*/
-static int ftpm_tee_probe(struct device *dev)
+static int ftpm_tee_probe_generic(struct device *dev)
{
int rc;
struct tpm_chip *chip;
@@ -251,11 +251,18 @@ static int ftpm_tee_probe(struct device *dev)
return rc;
}
+static int ftpm_tee_probe(struct tee_client_device *tcdev)
+{
+ struct device *dev = &tcdev->dev;
+
+ return ftpm_tee_probe_generic(dev);
+}
+
static int ftpm_plat_tee_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- return ftpm_tee_probe(dev);
+ return ftpm_tee_probe_generic(dev);
}
/**
@@ -265,7 +272,7 @@ static int ftpm_plat_tee_probe(struct platform_device *pdev)
* Return:
* 0 always.
*/
-static int ftpm_tee_remove(struct device *dev)
+static void ftpm_tee_remove_generic(struct device *dev)
{
struct ftpm_tee_private *pvt_data = dev_get_drvdata(dev);
@@ -285,15 +292,20 @@ static int ftpm_tee_remove(struct device *dev)
tee_client_close_context(pvt_data->ctx);
/* memory allocated with devm_kzalloc() is freed automatically */
+}
- return 0;
+static void ftpm_tee_remove(struct tee_client_device *tcdev)
+{
+ struct device *dev = &tcdev->dev;
+
+ ftpm_tee_remove_generic(dev);
}
static void ftpm_plat_tee_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- ftpm_tee_remove(dev);
+ ftpm_tee_remove_generic(dev);
}
/**
@@ -335,11 +347,11 @@ static const struct tee_client_device_id optee_ftpm_id_table[] = {
MODULE_DEVICE_TABLE(tee, optee_ftpm_id_table);
static struct tee_client_driver ftpm_tee_driver = {
+ .probe = ftpm_tee_probe,
+ .remove = ftpm_tee_remove,
.id_table = optee_ftpm_id_table,
.driver = {
.name = "optee-ftpm",
- .probe = ftpm_tee_probe,
- .remove = ftpm_tee_remove,
},
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 16/17] tpm/tpm_ftpm_tee: Make use of tee specific driver registration
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Peter Huewe, Jarkko Sakkinen
Cc: Jason Gunthorpe, Sumit Garg, linux-integrity, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <cover.1765791463.git.u.kleine-koenig@baylibre.com>
tee_client_driver_register() is typed more strongly and cares about
assigning the driver's bus. Similar for tee_client_driver_unregister().
Make use of these functions.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
drivers/char/tpm/tpm_ftpm_tee.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
index 4e63c30aeaf1..e5fbc70b0eca 100644
--- a/drivers/char/tpm/tpm_ftpm_tee.c
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -338,7 +338,6 @@ static struct tee_client_driver ftpm_tee_driver = {
.id_table = optee_ftpm_id_table,
.driver = {
.name = "optee-ftpm",
- .bus = &tee_bus_type,
.probe = ftpm_tee_probe,
.remove = ftpm_tee_remove,
},
@@ -352,7 +351,7 @@ static int __init ftpm_mod_init(void)
if (rc)
return rc;
- rc = driver_register(&ftpm_tee_driver.driver);
+ rc = tee_client_driver_register(&ftpm_tee_driver);
if (rc) {
platform_driver_unregister(&ftpm_tee_plat_driver);
return rc;
@@ -364,7 +363,7 @@ static int __init ftpm_mod_init(void)
static void __exit ftpm_mod_exit(void)
{
platform_driver_unregister(&ftpm_tee_plat_driver);
- driver_unregister(&ftpm_tee_driver.driver);
+ tee_client_driver_unregister(&ftpm_tee_driver);
}
module_init(ftpm_mod_init);
--
2.47.3
^ permalink raw reply related
* [PATCH v2 15/17] KEYS: trusted: Make use of tee bus methods
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Sumit Garg, James Bottomley, Jarkko Sakkinen,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn
Cc: linux-integrity, keyrings, linux-security-module, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <cover.1765791463.git.u.kleine-koenig@baylibre.com>
The tee bus got dedicated callbacks for probe and remove.
Make use of these. This fixes a runtime warning about the driver needing
to be converted to the bus methods.
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
security/keys/trusted-keys/trusted_tee.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
index 3cea9a377955..6e465c8bef5e 100644
--- a/security/keys/trusted-keys/trusted_tee.c
+++ b/security/keys/trusted-keys/trusted_tee.c
@@ -202,9 +202,9 @@ static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
return 0;
}
-static int trusted_key_probe(struct device *dev)
+static int trusted_key_probe(struct tee_client_device *rng_device)
{
- struct tee_client_device *rng_device = to_tee_client_device(dev);
+ struct device *dev = &rng_device->dev;
int ret;
struct tee_ioctl_open_session_arg sess_arg;
@@ -244,13 +244,11 @@ static int trusted_key_probe(struct device *dev)
return ret;
}
-static int trusted_key_remove(struct device *dev)
+static void trusted_key_remove(struct tee_client_device *dev)
{
unregister_key_type(&key_type_trusted);
tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
tee_client_close_context(pvt_data.ctx);
-
- return 0;
}
static const struct tee_client_device_id trusted_key_id_table[] = {
@@ -261,11 +259,11 @@ static const struct tee_client_device_id trusted_key_id_table[] = {
MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
static struct tee_client_driver trusted_key_driver = {
+ .probe = trusted_key_probe,
+ .remove = trusted_key_remove,
.id_table = trusted_key_id_table,
.driver = {
.name = DRIVER_NAME,
- .probe = trusted_key_probe,
- .remove = trusted_key_remove,
},
};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 14/17] KEYS: trusted: Migrate to use tee specific driver registration function
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Sumit Garg, James Bottomley, Jarkko Sakkinen,
Mimi Zohar, David Howells, Paul Moore, James Morris,
Serge E. Hallyn
Cc: linux-integrity, keyrings, linux-security-module, op-tee,
linux-kernel, Sumit Garg
In-Reply-To: <cover.1765791463.git.u.kleine-koenig@baylibre.com>
The tee subsystem recently got a set of dedicated functions to register
(and unregister) a tee driver. Make use of them. These care for setting the
driver's bus (so the explicit assignment can be dropped) and the driver
owner (which is an improvement this driver benefits from).
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
security/keys/trusted-keys/trusted_tee.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
index aa3d477de6db..3cea9a377955 100644
--- a/security/keys/trusted-keys/trusted_tee.c
+++ b/security/keys/trusted-keys/trusted_tee.c
@@ -264,7 +264,6 @@ static struct tee_client_driver trusted_key_driver = {
.id_table = trusted_key_id_table,
.driver = {
.name = DRIVER_NAME,
- .bus = &tee_bus_type,
.probe = trusted_key_probe,
.remove = trusted_key_remove,
},
@@ -272,12 +271,12 @@ static struct tee_client_driver trusted_key_driver = {
static int trusted_tee_init(void)
{
- return driver_register(&trusted_key_driver.driver);
+ return tee_client_driver_register(&trusted_key_driver);
}
static void trusted_tee_exit(void)
{
- driver_unregister(&trusted_key_driver.driver);
+ tee_client_driver_unregister(&trusted_key_driver);
}
struct trusted_key_ops trusted_key_tee_ops = {
--
2.47.3
^ permalink raw reply related
* [PATCH v2 00/17] tee: Use bus callbacks instead of driver callbacks
From: Uwe Kleine-König @ 2025-12-15 14:16 UTC (permalink / raw)
To: Jens Wiklander, Jonathan Corbet, Sumit Garg, Olivia Mackall,
Herbert Xu, Clément Léger, Alexandre Belloni,
Ard Biesheuvel, Maxime Coquelin, Alexandre Torgue, Sumit Garg,
Ilias Apalodimas, Jan Kiszka, Uwe Kleine-König, Sudeep Holla,
Christophe JAILLET, Rafał Miłecki, Michael Chan,
Pavan Chebbi, James Bottomley, Jarkko Sakkinen, Mimi Zohar,
David Howells, Paul Moore, James Morris, Serge E. Hallyn,
Peter Huewe
Cc: op-tee, linux-kernel, linux-doc, linux-crypto, linux-rtc,
linux-efi, linux-stm32, linux-arm-kernel, Cristian Marussi,
arm-scmi, linux-mips, netdev, linux-integrity, keyrings,
linux-security-module, Jason Gunthorpe
Hello,
the objective of this series is to make tee driver stop using callbacks
in struct device_driver. These were superseded by bus methods in 2006
(commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
methods.")) but nobody cared to convert all subsystems accordingly.
Here the tee drivers are converted. The first commit is somewhat
unrelated, but simplifies the conversion (and the drivers). It
introduces driver registration helpers that care about setting the bus
and owner. (The latter is missing in all drivers, so by using these
helpers the drivers become more correct.)
v1 of this series is available at
https://lore.kernel.org/all/cover.1765472125.git.u.kleine-koenig@baylibre.com
Changes since v1:
- rebase to v6.19-rc1 (no conflicts)
- add tags received so far
- fix whitespace issues pointed out by Sumit Garg
- fix shutdown callback to shutdown and not remove
As already noted in v1's cover letter, this series should go in during a
single merge window as there are runtime warnings when the series is
only applied partially. Sumit Garg suggested to apply the whole series
via Jens Wiklander's tree.
If this is done the dependencies in this series are honored, in case the
plan changes: Patches #4 - #17 depend on the first two.
Note this series is only build tested.
Uwe Kleine-König (17):
tee: Add some helpers to reduce boilerplate for tee client drivers
tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
tee: Adapt documentation to cover recent additions
hwrng: optee - Make use of module_tee_client_driver()
hwrng: optee - Make use of tee bus methods
rtc: optee: Migrate to use tee specific driver registration function
rtc: optee: Make use of tee bus methods
efi: stmm: Make use of module_tee_client_driver()
efi: stmm: Make use of tee bus methods
firmware: arm_scmi: optee: Make use of module_tee_client_driver()
firmware: arm_scmi: Make use of tee bus methods
firmware: tee_bnxt: Make use of module_tee_client_driver()
firmware: tee_bnxt: Make use of tee bus methods
KEYS: trusted: Migrate to use tee specific driver registration
function
KEYS: trusted: Make use of tee bus methods
tpm/tpm_ftpm_tee: Make use of tee specific driver registration
tpm/tpm_ftpm_tee: Make use of tee bus methods
Documentation/driver-api/tee.rst | 18 +----
drivers/char/hw_random/optee-rng.c | 26 ++----
drivers/char/tpm/tpm_ftpm_tee.c | 31 +++++---
drivers/firmware/arm_scmi/transports/optee.c | 32 +++-----
drivers/firmware/broadcom/tee_bnxt_fw.c | 30 ++-----
drivers/firmware/efi/stmm/tee_stmm_efi.c | 25 ++----
drivers/rtc/rtc-optee.c | 27 ++-----
drivers/tee/tee_core.c | 84 ++++++++++++++++++++
include/linux/tee_drv.h | 12 +++
security/keys/trusted-keys/trusted_tee.c | 17 ++--
10 files changed, 164 insertions(+), 138 deletions(-)
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
--
2.47.3
^ permalink raw reply
* Re: [PATCH V2 1/1] IMA event log trimming
From: Mimi Zohar @ 2025-12-15 14:02 UTC (permalink / raw)
To: steven chen, linux-integrity
Cc: roberto.sassu, dmitry.kasatkin, eric.snowberg, corbet, serge,
paul, jmorris, linux-security-module, anirudhve, gregorylumen,
nramas, sushring, linux-doc
In-Reply-To: <20251210235314.3341-2-chenste@linux.microsoft.com>
Hi Steven,
The main difference between this patch and Roberto's version is the length of
time needed for locking the measurement list, which prevents new entries from
being appended to the measurement list. In Roberto's version, the list head is
moved quickly and the lock released. Measuring the total amount of time needed
to trim the measurement list ignores the benefit of his version. I plan on
reviewing both this version and his (hopefully today).
There are a number of other things missing from this patch, which I'll enumerate
when I review it.
On Wed, 2025-12-10 at 15:53 -0800, steven chen wrote:
> This patch is for trimming N entries of the IMA event logs. It will also
> cleaning the hash table if ima_flush_htable is set.
Please refer to "Describe your changes in imperative mood" in the "Describe your
changes" section of Documentation/process/submitting-patches.rst.
>
> It provides a userspace interface ima_trim_log that can be used to input
> number N to let kernel to trim N entries of IMA event logs. When read
> this interface, it returns number of entries trimmed last time.
>
> Signed-off-by: steven chen <chenste@linux.microsoft.com>
--
thanks,
Mimi
^ permalink raw reply
* Re: [RFC][PATCH v2] ima: Add support for staging measurements for deletion and trimming
From: Roberto Sassu @ 2025-12-15 12:41 UTC (permalink / raw)
To: Paul Moore
Cc: corbet, zohar, dmitry.kasatkin, eric.snowberg, jmorris, serge,
linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, chenste, nramas, Roberto Sassu
In-Reply-To: <CAHC9VhRUQxayj=XcdfbfHka-=N+B8cNk7Grg3QWGOTOz3BKfgw@mail.gmail.com>
On Fri, 2025-12-12 at 21:06 -0500, Paul Moore wrote:
> On Fri, Dec 12, 2025 at 12:19 PM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> > From: Roberto Sassu <roberto.sassu@huawei.com>
> >
> > Introduce the ability of staging the entire (or a portion of the) IMA
> > measurement list for deletion. Staging means moving the current content of
> > the measurement list to a separate location, and allowing users to read and
> > delete it. This causes the measurement list to be atomically truncated
> > before new measurements can be added. Staging can be done only once at a
> > time. In the event of kexec(), staging is reverted and staged entries will
> > be carried over to the new kernel.
> >
> > User space is responsible to concatenate the staged IMA measurements list
> > portions following the temporal order in which the operations were done,
> > together with the current measurement list. Then, it can send the collected
> > data to the remote verifiers.
> >
> > Also introduce the ability of trimming N measurements entries from the IMA
> > measurements list, provided that user space has already read them. Trimming
> > combines staging and deletion in one operation.
> >
> > The benefit of these solutions is the ability to free precious kernel
> > memory, in exchange of delegating user space to reconstruct the full
> > measurement list from the chunks. No trust needs to be given to user space,
> > since the integrity of the measurement list is protected by the TPM.
> >
> > By default, staging/trimming the measurements list does not alter the hash
> > table. When staging/trimming are done, IMA is still able to detect
> > collisions on the staged and later deleted measurement entries, by keeping
> > the entry digests (only template data are freed).
> >
> > However, since during the measurements list serialization only the SHA1
> > digest is passed, and since there are no template data to recalculate the
> > other digests from, the hash table is currently not populated with digests
> > from staged/deleted entries after kexec().
> >
> > Introduce the new kernel option ima_flush_htable to decide whether or not
> > the digests of staged measurement entries are flushed from the hash table.
> >
> > Then, introduce ascii_runtime_measurements_staged_<algo> and
> > binary_runtime_measurement_staged_<algo> interfaces to stage/trim/delete
> > the measurements. Use 'echo A > <IMA interface>' and
> > 'echo D > <IMA interface>' to respectively stage and delete the entire
> > measurements list. Use 'echo N > <IMA interface>', with N between 1 and
> > LONG_MAX, to stage the selected portion of the measurements list, and
> > 'echo -N > <IMA interface>' to trim N measurements entries.
>
> In an effort to help preserve the sanity of admins, I might suggest
> avoiding commands that start with a dash/'-'. I'd probably also
> simplify the commands a bit and drop all/'A' since the measurement
> list could change at any time, stick with an explicit number and just
> let the admin go over, e.g. write LONG_MAX, which effectively becomes
> 'A'. I think you could do everything you need with just two commands:
>
> <NUM>: stage <NUM> entries
> D: delete staged entries
If the goal is that the verifier always receives a TPM quote aligned
with the measurements, the remote attestation agent in the target
system has to walk over the measurements to find N.
The difference between the approach I was suggesting and Steven's is
that I calculate N after staging all measurements and store the
exceeding measurements locally until the next attestation request. If
the verifier supports it, the exceeding measurements could be stored
also there.
That means that I don't need to walk in the measurement list to stage,
because I stage the entire list (with list_replace()). I do a walk
after detaching, without interfering with the processes adding new
measurements (hot path).
Steven's approach is to read the measurements list to calculate N and
stage/trim the measurement based on N. As Steven/Gregory pointed out,
at this point you could already trim N because you already have the
measurements list.
However, in this case you have to walk through the measurements list as
an RCU reader in the hot path, calculate N, and walk through the
measurements list again as an RCU writer in the hot path to stage/trim
N. In the next attestation request, you would read the previous
exceeding measurements again.
One major obstacle of my approach, as Gregory pointed out, was that
staged measurements were not carried over during kexec(). While I
thought about coordinating remote attestation requests with kexec() in
a management engine, there can be cases where this is harder to
achieve.
I managed to solve that by introducing a third linked list containing
the measurements to delete, by doing another list replace between
staged and measurements to delete (when the 'D' command is issued),
under the hot path lock. That allowed me to take the hot path lock
during kexec() and prepend the staged measurements before the non-
staged ones (that reminded me that I should properly inform user space
if kexec() consumed staged measurements before the 'D' command was
executed, i.e. it lost the race with kexec()).
The approach to keep the stage N approach would be necessary if
exceeding measurements cannot be stored either locally or at the
verifier side.
For me it would be fine to keep both approaches, but I still see
advantages of the stage all approach.
Thanks
Roberto
> I intentionally left out the trim/'T' command, because I'm not sure it
> is really necessary if you are going to implement the phased
> stage/delete process. Yes, you have to do two operations (stage and
> delete) as opposed to just the trim, but I'd probably take the
> simplicity of just supporting a single approach over the trivial
> necessity of having to do two operations in userspace.
>
> Staging also has the benefit of having a sane way of handling two
> tasks racing to stage the measurement list. I could see cases where
> multiple tasks race to trim the list and end up trimming more than was
> intended since they both hit in sequence.
>
> If you did want to take a trim approach over a stage/delete approach,
> I could see something like this working:
>
> 1. process opens the measurement list
> 2. process reads from the measurement list, keeps the fd open
> 3. process does whatever it wants to preserve the list
> 4. process writes <NUM> to the measurement list, kernel trims <NUM> entries
> 5. process closes fd
>
> ... error handling shouldn't be too bad. The process only writes
> <NUM> to the fd if it has already finished whatever it needs to do to
> preserve the list outside the kernel, think of it as a "commit"
> operation on a transaction. If the fd is closed for some reason
> (error, interruption, killed) before the process writes <NUM> to the
> fd then IMA does nothing - no trim takes place.
>
> Multiple process racing can easily be solved when the log is opened;
> only one open(O_RDWR) is allowed at a time, other racing processes
> will get EBUSY. Yes, one process could block others from trimming by
> holding the fd open for an extended period of time, but I would expect
> that CAP_SYS_ADMIN and root fs perms would be required to open the log
> read/write (not to mention any LSM access rights in place).
>
> I know I mentioned this basic idea to someone at some point, but there
> have been various discussion threads and multiple people over a fairly
> lengthy time that I've lost track of where it was mentioned. If it
> was already discussed on-list and rejected for a good reason you can
> simply ignore the above approach ... although I still think the
> stage/delete API could be simplified as described :)
>
> [UPDATE: as I'm reading Steven's replies it looks like he has proposed
> something very similar to the above]
>
^ permalink raw reply
* Re: [PATCH v1 00/17] tee: Use bus callbacks instead of driver callbacks
From: Uwe Kleine-König @ 2025-12-15 9:32 UTC (permalink / raw)
To: Sumit Garg
Cc: Jens Wiklander, Olivia Mackall, Herbert Xu,
Clément Léger, Alexandre Belloni, Ard Biesheuvel,
Maxime Coquelin, Alexandre Torgue, Sumit Garg, Ilias Apalodimas,
Jan Kiszka, Sudeep Holla, Christophe JAILLET, Michael Chan,
Pavan Chebbi, Rafał Miłecki, James Bottomley,
Jarkko Sakkinen, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe, op-tee, linux-kernel,
linux-crypto, linux-rtc, linux-efi, linux-stm32, linux-arm-kernel,
Cristian Marussi, arm-scmi, netdev, linux-mips, linux-integrity,
keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <aT--ox375kg2Mzh-@sumit-X1>
[-- Attachment #1: Type: text/plain, Size: 3035 bytes --]
Hello Sumit,
On Mon, Dec 15, 2025 at 04:54:11PM +0900, Sumit Garg wrote:
> On Thu, Dec 11, 2025 at 06:14:54PM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > the objective of this series is to make tee driver stop using callbacks
> > in struct device_driver. These were superseded by bus methods in 2006
> > (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> > methods.")) but nobody cared to convert all subsystems accordingly.
> >
> > Here the tee drivers are converted. The first commit is somewhat
> > unrelated, but simplifies the conversion (and the drivers). It
> > introduces driver registration helpers that care about setting the bus
> > and owner. (The latter is missing in all drivers, so by using these
> > helpers the drivers become more correct.)
> >
> > The patches #4 - #17 depend on the first two, so if they should be
> > applied to their respective subsystem trees these must contain the first
> > two patches first.
>
> Thanks Uwe for your efforts to clean up the boilerplate code for TEE bus
> drivers.
Thanks for your feedback. I will prepare a v2 and address your comments
(whitespace issues and wrong callback in the shutdown method).
> > Note that after patch #2 is applied, unconverted drivers provoke a
> > warning in driver_register(), so it would be good for the user
> > experience if the whole series goes in during a single merge window.
>
> +1
>
> I suggest the whole series goes via the Jens tree since there shouldn't
> be any chances for conflict here.
>
> > So
> > I guess an immutable branch containing the frist three patches that can
> > be merged into the other subsystem trees would be sensible.
> >
> > After all patches are applied, tee_bus_type can be made private to
> > drivers/tee as it's not used in other places any more.
> >
>
> Feel free to make the tee_bus_type private as the last patch in the series
> such that any followup driver follows this clean approach.
There is a bit more to do for that than I'm willing to invest. With my
patch series applied `tee_bus_type` is still used in
drivers/tee/optee/device.c and drivers/tee/tee_core.c. Maybe it's
sensible to merge these two files into a single one.
The things I wonder about additionally are:
- if CONFIG_OPTEE=n and CONFIG_TEE=y|m the tee bus is only used for
drivers but not devices.
- optee_register_device() calls device_create_file() on
&optee_device->dev after device_register(&optee_device->dev).
(Attention half-knowledge!) I think device_create_file() should not
be called on an already registered device (or you have to send a
uevent afterwards). This should probably use type attribute groups.
(Or the need_supplicant attribute should be dropped as it isn't very
useful. This would maybe be considered an ABI change however.)
- Why does optee_probe() in drivers/tee/optee/smc_abi.c unregister all
optee devices in its error path (optee_unregister_devices())?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: Jarkko Sakkinen @ 2025-12-15 8:49 UTC (permalink / raw)
To: James Bottomley
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <60cf8bd2afbad5e930119d73ccf069e95ee4fd9d.camel@HansenPartnership.com>
On Mon, Dec 15, 2025 at 04:55:58PM +0900, James Bottomley wrote:
> On Mon, 2025-12-15 at 08:43 +0200, Jarkko Sakkinen wrote:
> > On Mon, Dec 15, 2025 at 07:18:41AM +0900, James Bottomley wrote:
> > > On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> > > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and
> > > > thus its use should be pooled rather than directly used. This
> > > > both reduces latency and improves its predictability.
> > > >
> > > > 2. Linux is better off overall if every subsystem uses the same
> > > > source for the random bistream as the de-facto choice, unless
> > > > *force majeure* reasons point to some other direction.
> > > >
> > > > In the case, of TPM there is no reason for trusted keys to invoke
> > > > TPM directly.
> > >
> > > That assertion isn't correct: you seem to have forgotten we had
> > > this argument six or seven years ago, but even that was a reprise
> > > of an even earlier one. Lore doesn't go back far enough for the
> > > intermediate one on the tpm list, but the original was cc'd to
> > > lkml:
> > >
> > > https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
> > >
> > > The decision then was to use the same random source as the key
> > > protection. Unfortunately most of the active participants have
> > > moved on from IBM and I don't have their current email addresses,
> > > but the bottom line is there were good reasons to do trusted keys
> > > this way that your assertions above don't overcome. I'm not saying
> > > we shouldn't reconsider the situation, but we need a reasoned
> > > debate rather than simply doing it by fiat.
> >
> > The way I see this is that given that kernel is not running inside
> > TPM, FIPS certification of the RNG does not have any measurable
> > value.
> >
> > Random data generation should happen as part of object creation
> > process i.e. should be fully self-contained process within the TPM in
> > order for FIPS to matter.
>
> In FIPS terms, there's no distinction between keeping the whole
> generation process internal to the TPM and using the FIPS certified rng
> of the TPM to source the contents of a kernel protected key. Both
> provide equally valid, and FIPS certified data.
I understand being "FIPS certified" embedding the premise that kernel
is also FIPS certified, which covers also crypto etc. This is the case
with enterprise kernels.
I have understanding FIPS certification dies at the point when random
data is acquired by a kernel, which is not FIPS certified. It's not
really a safe closure.
Using same code path for RNG universally should actually help with any
certification processes.
>
> > In the case of sealed data objects, this not the case.
>
> FIPS is concerned with origins and provenance, so it most certainly is
> the case even for trusted keys. However, if the Kernel RNG is fips
> certified (as can happen with certain FIPS modules) it is the case that
> either the Kernel or TPM RNG would satisfy the FIPS requirement. The
> question for trusted key users is really do they always want the TPM
> FIPS RNG or should we allow mixing with the kernel RNG even in the non-
> FIPS case.
I don't disagree on benefits of FIPS certification.
>
> Perhaps, rather than getting hung up on FIPS sources and to facilitate
> debating the bedrock requirements, we could turn this around and ask
> what the use case you have for using the in-kernel RNG is?
Generally removing any non-mandatory TPM traffic is a feasible idea.
This was just something low-hanging fruit that I spotted while working
on larger patch set.
BR, Jarkko
>
> Regards,
>
> James
>
>
>
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM
From: James Bottomley @ 2025-12-15 7:55 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, David Howells, Paul Moore, James Morris,
Serge E. Hallyn, Mimi Zohar, open list:KEYS/KEYRINGS,
open list:SECURITY SUBSYSTEM, open list
In-Reply-To: <aT-uHgyYw3XhFasi@kernel.org>
On Mon, 2025-12-15 at 08:43 +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 15, 2025 at 07:18:41AM +0900, James Bottomley wrote:
> > On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> > > 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and
> > > thus its use should be pooled rather than directly used. This
> > > both reduces latency and improves its predictability.
> > >
> > > 2. Linux is better off overall if every subsystem uses the same
> > > source for the random bistream as the de-facto choice, unless
> > > *force majeure* reasons point to some other direction.
> > >
> > > In the case, of TPM there is no reason for trusted keys to invoke
> > > TPM directly.
> >
> > That assertion isn't correct: you seem to have forgotten we had
> > this argument six or seven years ago, but even that was a reprise
> > of an even earlier one. Lore doesn't go back far enough for the
> > intermediate one on the tpm list, but the original was cc'd to
> > lkml:
> >
> > https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/
> >
> > The decision then was to use the same random source as the key
> > protection. Unfortunately most of the active participants have
> > moved on from IBM and I don't have their current email addresses,
> > but the bottom line is there were good reasons to do trusted keys
> > this way that your assertions above don't overcome. I'm not saying
> > we shouldn't reconsider the situation, but we need a reasoned
> > debate rather than simply doing it by fiat.
>
> The way I see this is that given that kernel is not running inside
> TPM, FIPS certification of the RNG does not have any measurable
> value.
>
> Random data generation should happen as part of object creation
> process i.e. should be fully self-contained process within the TPM in
> order for FIPS to matter.
In FIPS terms, there's no distinction between keeping the whole
generation process internal to the TPM and using the FIPS certified rng
of the TPM to source the contents of a kernel protected key. Both
provide equally valid, and FIPS certified data.
> In the case of sealed data objects, this not the case.
FIPS is concerned with origins and provenance, so it most certainly is
the case even for trusted keys. However, if the Kernel RNG is fips
certified (as can happen with certain FIPS modules) it is the case that
either the Kernel or TPM RNG would satisfy the FIPS requirement. The
question for trusted key users is really do they always want the TPM
FIPS RNG or should we allow mixing with the kernel RNG even in the non-
FIPS case.
Perhaps, rather than getting hung up on FIPS sources and to facilitate
debating the bedrock requirements, we could turn this around and ask
what the use case you have for using the in-kernel RNG is?
Regards,
James
^ permalink raw reply
* Re: [PATCH v1 00/17] tee: Use bus callbacks instead of driver callbacks
From: Sumit Garg @ 2025-12-15 7:54 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Olivia Mackall, Herbert Xu,
Clément Léger, Alexandre Belloni, Ard Biesheuvel,
Maxime Coquelin, Alexandre Torgue, Sumit Garg, Ilias Apalodimas,
Jan Kiszka, Sudeep Holla, Christophe JAILLET, Michael Chan,
Pavan Chebbi, Rafał Miłecki, James Bottomley,
Jarkko Sakkinen, Mimi Zohar, David Howells, Paul Moore,
James Morris, Serge E. Hallyn, Peter Huewe, op-tee, linux-kernel,
linux-crypto, linux-rtc, linux-efi, linux-stm32, linux-arm-kernel,
Cristian Marussi, arm-scmi, netdev, linux-mips, linux-integrity,
keyrings, linux-security-module, Jason Gunthorpe
In-Reply-To: <cover.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:14:54PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> the objective of this series is to make tee driver stop using callbacks
> in struct device_driver. These were superseded by bus methods in 2006
> (commit 594c8281f905 ("[PATCH] Add bus_type probe, remove, shutdown
> methods.")) but nobody cared to convert all subsystems accordingly.
>
> Here the tee drivers are converted. The first commit is somewhat
> unrelated, but simplifies the conversion (and the drivers). It
> introduces driver registration helpers that care about setting the bus
> and owner. (The latter is missing in all drivers, so by using these
> helpers the drivers become more correct.)
>
> The patches #4 - #17 depend on the first two, so if they should be
> applied to their respective subsystem trees these must contain the first
> two patches first.
Thanks Uwe for your efforts to clean up the boilerplate code for TEE bus
drivers.
>
> Note that after patch #2 is applied, unconverted drivers provoke a
> warning in driver_register(), so it would be good for the user
> experience if the whole series goes in during a single merge window.
+1
I suggest the whole series goes via the Jens tree since there shouldn't
be any chances for conflict here.
> So
> I guess an immutable branch containing the frist three patches that can
> be merged into the other subsystem trees would be sensible.
>
> After all patches are applied, tee_bus_type can be made private to
> drivers/tee as it's not used in other places any more.
>
Feel free to make the tee_bus_type private as the last patch in the series
such that any followup driver follows this clean approach.
-Sumit
> Best regards
> Uwe
>
> Uwe Kleine-König (17):
> tee: Add some helpers to reduce boilerplate for tee client drivers
> tee: Add probe, remove and shutdown bus callbacks to tee_client_driver
> tee: Adapt documentation to cover recent additions
> hwrng: optee - Make use of module_tee_client_driver()
> hwrng: optee - Make use of tee bus methods
> rtc: optee: Migrate to use tee specific driver registration function
> rtc: optee: Make use of tee bus methods
> efi: stmm: Make use of module_tee_client_driver()
> efi: stmm: Make use of tee bus methods
> firmware: arm_scmi: optee: Make use of module_tee_client_driver()
> firmware: arm_scmi: Make use of tee bus methods
> firmware: tee_bnxt: Make use of module_tee_client_driver()
> firmware: tee_bnxt: Make use of tee bus methods
> KEYS: trusted: Migrate to use tee specific driver registration
> function
> KEYS: trusted: Make use of tee bus methods
> tpm/tpm_ftpm_tee: Make use of tee specific driver registration
> tpm/tpm_ftpm_tee: Make use of tee bus methods
>
> Documentation/driver-api/tee.rst | 18 +----
> drivers/char/hw_random/optee-rng.c | 26 ++----
> drivers/char/tpm/tpm_ftpm_tee.c | 31 +++++---
> drivers/firmware/arm_scmi/transports/optee.c | 32 +++-----
> drivers/firmware/broadcom/tee_bnxt_fw.c | 30 ++-----
> drivers/firmware/efi/stmm/tee_stmm_efi.c | 25 ++----
> drivers/rtc/rtc-optee.c | 27 ++-----
> drivers/tee/tee_core.c | 84 ++++++++++++++++++++
> include/linux/tee_drv.h | 12 +++
> security/keys/trusted-keys/trusted_tee.c | 17 ++--
> 10 files changed, 164 insertions(+), 138 deletions(-)
>
>
> base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v1 17/17] tpm/tpm_ftpm_tee: Make use of tee bus methods
From: Sumit Garg @ 2025-12-15 7:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jens Wiklander, Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe,
op-tee, linux-integrity, linux-kernel
In-Reply-To: <eaf8216e8a6c3dabce5a82be5765d67c66318791.1765472125.git.u.kleine-koenig@baylibre.com>
On Thu, Dec 11, 2025 at 06:15:11PM +0100, Uwe Kleine-König wrote:
> The tee bus got dedicated callbacks for probe and remove.
> Make use of these. This fixes a runtime warning about the driver needing
> to be converted to the bus methods.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> ---
> drivers/char/tpm/tpm_ftpm_tee.c | 26 +++++++++++++++++++-------
> 1 file changed, 19 insertions(+), 7 deletions(-)
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
-Sumit
>
> diff --git a/drivers/char/tpm/tpm_ftpm_tee.c b/drivers/char/tpm/tpm_ftpm_tee.c
> index e5fbc70b0eca..20294d1953a3 100644
> --- a/drivers/char/tpm/tpm_ftpm_tee.c
> +++ b/drivers/char/tpm/tpm_ftpm_tee.c
> @@ -169,7 +169,7 @@ static int ftpm_tee_match(struct tee_ioctl_version_data *ver, const void *data)
> * Return:
> * On success, 0. On failure, -errno.
> */
> -static int ftpm_tee_probe(struct device *dev)
> +static int ftpm_tee_probe_generic(struct device *dev)
> {
> int rc;
> struct tpm_chip *chip;
> @@ -251,11 +251,18 @@ static int ftpm_tee_probe(struct device *dev)
> return rc;
> }
>
> +static int ftpm_tee_probe(struct tee_client_device *tcdev)
> +{
> + struct device *dev = &tcdev->dev;
> +
> + return ftpm_tee_probe_generic(dev);
> +}
> +
> static int ftpm_plat_tee_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> - return ftpm_tee_probe(dev);
> + return ftpm_tee_probe_generic(dev);
> }
>
> /**
> @@ -265,7 +272,7 @@ static int ftpm_plat_tee_probe(struct platform_device *pdev)
> * Return:
> * 0 always.
> */
> -static int ftpm_tee_remove(struct device *dev)
> +static void ftpm_tee_remove_generic(struct device *dev)
> {
> struct ftpm_tee_private *pvt_data = dev_get_drvdata(dev);
>
> @@ -285,15 +292,20 @@ static int ftpm_tee_remove(struct device *dev)
> tee_client_close_context(pvt_data->ctx);
>
> /* memory allocated with devm_kzalloc() is freed automatically */
> +}
>
> - return 0;
> +static void ftpm_tee_remove(struct tee_client_device *tcdev)
> +{
> + struct device *dev = &tcdev->dev;
> +
> + ftpm_tee_remove_generic(dev);
> }
>
> static void ftpm_plat_tee_remove(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
>
> - ftpm_tee_remove(dev);
> + ftpm_tee_remove_generic(dev);
> }
>
> /**
> @@ -335,11 +347,11 @@ static const struct tee_client_device_id optee_ftpm_id_table[] = {
> MODULE_DEVICE_TABLE(tee, optee_ftpm_id_table);
>
> static struct tee_client_driver ftpm_tee_driver = {
> + .probe = ftpm_tee_probe,
> + .remove = ftpm_tee_remove,
> .id_table = optee_ftpm_id_table,
> .driver = {
> .name = "optee-ftpm",
> - .probe = ftpm_tee_probe,
> - .remove = ftpm_tee_remove,
> },
> };
>
> --
> 2.47.3
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox