Re: [meta-arm] [PATCH v3 2/2] trusted-service: remove optee udev and group settings
Gyorgy Szing <[email protected]>
| Newsgroups | org.yoctoproject.lists.meta-arm |
|---|---|
| Message-ID | <AS8PR08MB589512524CBB7BFB377101C391472@AS8PR08MB5895.eurprd08.prod.outlook.com> |
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. Yes, the /dev/tee* devices will be still there, but only accessible with root privileges which is kind of a feature degradation. “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? /George From: Mikko Rapeli <[email protected]> Date: Thursday, 17 October 2024 at 10:34 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 08:17:32AM +0000, Gyorgy Szing wrote: > How is the system going to work if op-tee client is not deployed, but libts is? E.g. if the SPMC is Hafnium and no S-EL1 OP-TEE SP is needed, but the FWU SP is used? If optee-client is not installed, then optee is not functional in Linux userspace and rootfs so optee-test fails. The plain kernel driver for optee will work and /dev/tee* and /dev/teepriv* interfaces will pop up with root access rights, but not with the setup expected by tee-supplicant systemd service file from optee-client. This may be enough for TS use cases. In the firmware side, optee services are not affected. If this impacts libts users, then IMO they need to install optee-client or setup the udev rules etc in some other way. Is there some problem I missed or a setup which is not covered in meta-arm testing? Cheers, -Mikko