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

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.

> “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?

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.

Cheers,

-Mikko