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

On 2024-10-17, 13:09, "Mikko Rapeli" <[email protected]> wrote:

> Hi,
>
> On Thu, Oct 17, 2024 at 10:54:41AM +0000, Gyorgy Szing wrote:
> > 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.
>
> A dedicated recipe is not ok. optee-client upstream provides the udev rule.
> A dedicated binary package from optee-client for the udev rule could be
> created. The udev rule and matching systemd service (and possibly sysvinit
> script) are non-trivial to setup and thus in meta-arm recipe some aspects
> were wrong and other Linux distros have even more issues. Thus it's better
> to collaborate with upstream when setting them up.

Op-tee client up-stream providing the udev rule might be a wrong decision based on you highlights of the complexities and the conclusion, this should be managed in sync with distros. Does this mean Yocto (a distro) should provide its own solution and only use op-tee client up-stream implementation as an example. Also, the optee-client up-stream implementation might be tailored for the op-tee integration system (op-tee build repo).

>
> > “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.
>
> I'm still not sure of the right direction. Which recipes and layers have userspace
> SW which needs to access /dev/tee* or /dev/teepriv* devices nodes without root
> rights in userspace? Where is a test for these recipes or functionality?

Any platform deploying Trusted Services will need access to /dev/tee*. Please see the recipes not starting with ts-sp- prefix under meta-arm/meta-arm/recipes-security/trusted-services.
TS is currently deployed on base_fvp, qeamuarm64-secureboot, n1sdp, and Corstone100.
All of these is using OP-TEE SPMC and deploying optee-client. There will be platforms using Hafnium SPMC and TS, and not deploying optee-client.

You can find the test here: meta-arm/lib/oeqa/runtime/cases/trusted_services.py

> The old teeclnt setup was a bit broken. For example tee-supplicant was still
> started in systemd service file as root user. Both /dev/tee* and /dev/teepriv*
> used the same teeclnt group which was not right according to upstream,
> they need to have different groups. Then the systemd service which did not
> work in initrd. Etc.
Great you fixed this.

>
> Cheers,
>
> -Mikko
>