[PATCH v2 1/3] rng: add OP-TEE based Random Number Generator

[Patrick DELAUNAY]

Hi,

On 3/28/22 15:25, Heinrich Schuchardt wrote:
> On 3/28/22 15:11, Patrick Delaunay wrote:
>> Add driver for OP-TEE based Random Number Generator on ARM SoCs
>> where hardware entropy sources are not accessible to normal world
>> and the RNG service is provided by a HWRNG Trusted Application (TA).
>>
>> This driver is based on the linux driver: char/hw_random/optee-rng.c
>>
>> Series_changes: 2
>> - change SPDX-License-Identifier, becausee "GPL-2.0+” is obsolete
>>    reference: https://spdx.dev/ids/
>> - update Kconfig long help message as proposed by Heinrich
>> - replace memset(.., 0, sizeof(..)) by struct initialisation (= {0};)
>> - add function descriptions
>>
>> Signed-off-by: Patrick Delaunay <patrick.delaunay at foss.st.com>
>> ---
>>
>> (no changes since v1)
>>
>>   MAINTAINERS             |   1 +
>>   drivers/rng/Kconfig     |   9 ++
>>   drivers/rng/Makefile    |   1 +
>>   drivers/rng/optee_rng.c | 180 ++++++++++++++++++++++++++++++++++++++++
>>   4 files changed, 191 insertions(+)
>>   create mode 100644 drivers/rng/optee_rng.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index f25ca7cd00..3356c65dd0 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -481,6 +481,7 @@ F:    drivers/power/regulator/stpmic1.c
>>   F:    drivers/ram/stm32mp1/
>>   F:    drivers/remoteproc/stm32_copro.c
>>   F:    drivers/reset/stm32-reset.c
>> +F:    drivers/rng/optee_rng.c
>>   F:    drivers/rng/stm32mp1_rng.c
>>   F:    drivers/rtc/stm32_rtc.c
>>   F:    drivers/serial/serial_stm32.*


(...)

>>
>> +++ b/drivers/rng/optee_rng.c
>> @@ -0,0 +1,180 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
>> +/*
>> + * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
>> + */
>> +#define LOG_CATEGORY UCLASS_RNG
>> +


(...)

>>
>> +
>> +/**
>> + * optee_rng_probe() - probe function for OP-TEE RNG device
>> + *
>> + * @dev:        device
>> + * Return:        0 if ok
>> + */
>> +static int optee_rng_probe(struct udevice *dev)
>> +{
>> +    const struct tee_optee_ta_uuid uuid = TA_HWRNG_UUID;
>> +    struct optee_rng_priv *priv = dev_get_priv(dev);
>> +    struct tee_open_session_arg sess_arg = {0};
>> +    int ret;
>> +
>> +    /* Open session with hwrng Trusted App */
>> +    tee_optee_ta_uuid_to_octets(sess_arg.uuid, &uuid);
>> +    sess_arg.clnt_login = TEE_LOGIN_PUBLIC;
>> +
>> +    ret = tee_open_session(dev->parent, &sess_arg, 0, NULL);
>> +    if (ret || sess_arg.ret) {
>> +        if (!ret)
>> +            ret = -EIO;
>> +        dev_err(dev, "can't open session: %d 0x%x\n", ret, 
>> sess_arg.ret);
>> +        return ret;
>> +    }
>> +    priv->session_id = sess_arg.session;
>
> Is it really necessary to keep the session open?
> Or should we reopen a session whenever a random number is requested?
>
> Best regards
>
> Heinrich
>

No, I don't think that it is necessary.

I just use the same mechanism than Linux driver

(drivers/char/hw_random/optee-rng.c:optee_rng_probe/optee_rng_remove)

or in other U-Boot driver = drivers/tpm/tpm2_ftpm_tee.c.


But I check with Etienne, which provide the SCMI over OP-TEE implementation,

It seens that manage the optee session in probe/remove function in U-Boot is

not recommended, because when the drivers are used before relocation the

remove function is not called (so the session is not freed)

and because the time of the session open procedure is not the largest part.


=> I will remove it to simplify this driver.


regards

Patrick