Re: [meta-arm] [PATCH v3 2/2] trusted-service: remove optee udev and group settings

Hi,

“But optee and optee-client are part of the TS images and configs so there is a link.”
“I don't see any user being added to the previously used "teeclnt" group. So which non-root users are there? If the users are in Cassini, I have proposed fixes there.”
I am not saying the TS recipes are perfect and there might be a dependency, which is an error. Except for the OP-TEE SPMC tests SPs which indeed depend on op-tee and xtest.

“What is the proper way to fix this?

I don't think duplicating optee/tee-supplicant udev rules is the answer.
I could move optee-client recipe udev rules to a separate binary package
to enable installing without tee-supplicant.”
I think a dedicated recipe on which both libts and optee-client depends is one way to fix.

“But I'd like to see the users and have a test case, preferably in meta-arm.”
Well, I cannot provide a setup where TS is used without OP-TEE currently, but your config can and will be tested in the CI. Yes, TS only world might still be broken, but the change at least would make a step in the right direction.

/George

From: Mikko Rapeli <[email protected]>
Date: Thursday, 17 October 2024 at 11:52
To: Gyorgy Szing <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [meta-arm] [PATCH v3 2/2] trusted-service: remove optee udev and group settings
Hi,

On Thu, Oct 17, 2024 at 09:44:07AM +0000, Gyorgy Szing wrote:
> Hi,
>
> The Trusted Services protocol is implemented by the tstee driver and libts.  This means there are multiple drivers using the tee subsystem and multiple ecosystems relying on the /dev/tee devices.
> Your changes move the tee driver access configuration to the op-tee client only and this adds a dependency between the two ecosystems. The TS ecosystem will not work without the op-tee client, but op-tee client is not part of that ecosystem.

But optee and optee-client are part of the TS images and configs so there is a link.

> Yes, the /dev/tee* devices will be still there, but only accessible with root privileges which is kind of a feature degradation.

I don't see any user being added to the previously used "teeclnt" group.
So which non-root users are there? If the users are in Cassini, I have
proposed fixes there.

> “If this impacts libts users, then IMO they need to install optee-client orsetup the udev rules etc in some other way.“
> Yes, this “some other way” is the udev rules config you are removing.
>
> “Is there some problem I missed or a setup which is not covered in meta-arm testing?”
> AFAIK currently there is no meta-arm config which enables FF-A but does not use the OP-TEE SPMC. But this will change soon. So why not do this properly now?

What is the proper way to fix this?

I don't think duplicating optee/tee-supplicant udev rules is the answer.
I could move optee-client recipe udev rules to a separate binary package
to enable installing without tee-supplicant. But I'd like to see the
users and have a test case, preferably in meta-arm.

Cheers,

-Mikko