| Message ID | 20241017065907.172504-2-mikko.rapeli@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [v3,1/2] optee-client: use udev rule and systemd service from upstream | expand |
Hi, 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? /George From: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org> on behalf of Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> Date: Thursday, 17 October 2024 at 09:01 To: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org> Cc: Mikko Rapeli <mikko.rapeli@linaro.org> Subject: [meta-arm] [PATCH v3 2/2] trusted-service: remove optee udev and group settings optee-client now provides them and sets "tee" group for /dev/tee* and "teepriv" group for /dev/teepriv* access. tee-supplicant runs as "teesuppl" user account. Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> --- .../trusted-services/libts/tee-udev.rules | 7 ------- .../trusted-services/libts_git.bb | 19 ++----------------- 2 files changed, 2 insertions(+), 24 deletions(-) delete mode 100644 meta-arm/recipes-security/trusted-services/libts/tee-udev.rules diff --git a/meta-arm/recipes-security/trusted-services/libts/tee-udev.rules b/meta-arm/recipes-security/trusted-services/libts/tee-udev.rules deleted file mode 100644 index 43fafd8c..00000000 --- a/meta-arm/recipes-security/trusted-services/libts/tee-udev.rules +++ /dev/null @@ -1,7 +0,0 @@ -# tee devices can only be accessed by the teeclnt group members -KERNEL=="tee[0-9]*", TAG+="systemd", MODE="0660", GROUP="teeclnt" - -# If a /dev/teepriv[0-9]* device is detected, start an instance of -# tee-supplicant.service with the device name as parameter -KERNEL=="teepriv[0-9]*", MODE="0660", OWNER="root", GROUP="tee", \ - TAG+="systemd", ENV{SYSTEMD_WANTS}+="tee-supplicant@%k.service" diff --git a/meta-arm/recipes-security/trusted-services/libts_git.bb b/meta-arm/recipes-security/trusted-services/libts_git.bb index 635e4769..9d0e7373 100644 --- a/meta-arm/recipes-security/trusted-services/libts_git.bb +++ b/meta-arm/recipes-security/trusted-services/libts_git.bb @@ -5,24 +5,13 @@ TS_ENV = "arm-linux" require trusted-services.inc -SRC_URI += "file://tee-udev.rules \ - file://0001-Remove-TEE-driver-external-component.patch<file:///0001-Remove-TEE-driver-external-component.patch> \ - " +SRC_URI += "file://0001-Remove-TEE-driver-external-component.patch<file:///0001-Remove-TEE-driver-external-component.patch>" OECMAKE_SOURCEPATH="${S}/deployments/libts/${TS_ENV}" DEPENDS += "arm-ffa-user" -# Unix group name for dev/tee* ownership. -TEE_GROUP_NAME ?= "teeclnt" - do_install:append () { - if ${@oe.utils.conditional('VIRTUAL-RUNTIME_dev_manager', 'busybox-mdev', 'false', 'true', d)}; then - install -d ${D}${nonarch_base_libdir}/udev/rules.d/ - install -m 755 ${UNPACKDIR}/tee-udev.rules ${D}${nonarch_base_libdir}/udev/rules.d/ - sed -i -e "s/teeclnt/${TEE_GROUP_NAME}/" ${D}${nonarch_base_libdir}/udev/rules.d/tee-udev.rules - fi - # Move the dynamic libraries into the standard place. install -d ${D}${libdir} mv ${D}${TS_INSTALL}/lib/libts* ${D}${libdir} @@ -34,9 +23,5 @@ do_install:append () { fi } -inherit ${@oe.utils.conditional('VIRTUAL-RUNTIME_dev_manager', 'busybox-mdev', '', 'useradd', d)} -USERADD_PACKAGES = "${PN}" -GROUPADD_PARAM:${PN} = "--system ${TEE_GROUP_NAME}" - -FILES:${PN} = "${libdir}/libts.so.* ${nonarch_base_libdir}/udev/rules.d/" +FILES:${PN} = "${libdir}/libts.so.*" FILES:${PN}-dev = "${TS_INSTALL}/lib/cmake ${TS_INSTALL}/include ${libdir}/libts.so" -- 2.34.1
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
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 <mikko.rapeli@linaro.org> Date: Thursday, 17 October 2024 at 10:34 To: Gyorgy Szing <Gyorgy.Szing@arm.com> Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org> 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
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
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 <mikko.rapeli@linaro.org> Date: Thursday, 17 October 2024 at 11:52 To: Gyorgy Szing <Gyorgy.Szing@arm.com> Cc: meta-arm@lists.yoctoproject.org <meta-arm@lists.yoctoproject.org> 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
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
On 2024-10-17, 13:09, "Mikko Rapeli" <mikko.rapeli@linaro.org> 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 >
> > 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? Parsec uses the teeclnt group for access to the PSA APIs when TS is in PACKAGECONFIG but I'm not sure they test that configuration. Cassini tests that config and also use the same group to run the PSA API tests Regards Adam On Thu, 17 Oct 2024 at 12:09, Mikko Rapeli via lists.yoctoproject.org <mikko.rapeli=linaro.org@lists.yoctoproject.org> 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. > > > “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 > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#6210): > https://lists.yoctoproject.org/g/meta-arm/message/6210 > Mute This Topic: https://lists.yoctoproject.org/mt/109059457/8940727 > Group Owner: meta-arm+owner@lists.yoctoproject.org > Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/unsub [ > adam.johnston@linaro.org] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Thu, Oct 17, 2024 at 04:09 AM, Mikko Rapeli wrote: > > 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? Parsec is the example you're looking for. And parsec oeqa tests would test TS provider if included Anton
Hi, On Thu, Oct 17, 2024 at 07:48:27AM -0700, Anton Antonov via lists.yoctoproject.org wrote: > On Thu, Oct 17, 2024 at 04:09 AM, Mikko Rapeli wrote: > > > > > 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? > > Parsec is the example you're looking for. And parsec oeqa tests would test TS provider if included Thanks! So meta-security/recipes-parsec/parsec-service/parsec-service_1.4.1.bb would need to change from "teeclnt" to "tee" group to access /dev/tee* devices according to optee-client udev rule. I can provide the change when/if this series gets merged. Same for meta-cassini. But does the really need to be a separate copy of the optee-client udev rule for TS setups which need optee but not tee-supplicant from optee-client binary package? Cheers, -Mikko
diff --git a/meta-arm/recipes-security/trusted-services/libts/tee-udev.rules b/meta-arm/recipes-security/trusted-services/libts/tee-udev.rules deleted file mode 100644 index 43fafd8c..00000000 --- a/meta-arm/recipes-security/trusted-services/libts/tee-udev.rules +++ /dev/null @@ -1,7 +0,0 @@ -# tee devices can only be accessed by the teeclnt group members -KERNEL=="tee[0-9]*", TAG+="systemd", MODE="0660", GROUP="teeclnt" - -# If a /dev/teepriv[0-9]* device is detected, start an instance of -# tee-supplicant.service with the device name as parameter -KERNEL=="teepriv[0-9]*", MODE="0660", OWNER="root", GROUP="tee", \ - TAG+="systemd", ENV{SYSTEMD_WANTS}+="tee-supplicant@%k.service" diff --git a/meta-arm/recipes-security/trusted-services/libts_git.bb b/meta-arm/recipes-security/trusted-services/libts_git.bb index 635e4769..9d0e7373 100644 --- a/meta-arm/recipes-security/trusted-services/libts_git.bb +++ b/meta-arm/recipes-security/trusted-services/libts_git.bb @@ -5,24 +5,13 @@ TS_ENV = "arm-linux" require trusted-services.inc -SRC_URI += "file://tee-udev.rules \ - file://0001-Remove-TEE-driver-external-component.patch \ - " +SRC_URI += "file://0001-Remove-TEE-driver-external-component.patch" OECMAKE_SOURCEPATH="${S}/deployments/libts/${TS_ENV}" DEPENDS += "arm-ffa-user" -# Unix group name for dev/tee* ownership. -TEE_GROUP_NAME ?= "teeclnt" - do_install:append () { - if ${@oe.utils.conditional('VIRTUAL-RUNTIME_dev_manager', 'busybox-mdev', 'false', 'true', d)}; then - install -d ${D}${nonarch_base_libdir}/udev/rules.d/ - install -m 755 ${UNPACKDIR}/tee-udev.rules ${D}${nonarch_base_libdir}/udev/rules.d/ - sed -i -e "s/teeclnt/${TEE_GROUP_NAME}/" ${D}${nonarch_base_libdir}/udev/rules.d/tee-udev.rules - fi - # Move the dynamic libraries into the standard place. install -d ${D}${libdir} mv ${D}${TS_INSTALL}/lib/libts* ${D}${libdir} @@ -34,9 +23,5 @@ do_install:append () { fi } -inherit ${@oe.utils.conditional('VIRTUAL-RUNTIME_dev_manager', 'busybox-mdev', '', 'useradd', d)} -USERADD_PACKAGES = "${PN}" -GROUPADD_PARAM:${PN} = "--system ${TEE_GROUP_NAME}" - -FILES:${PN} = "${libdir}/libts.so.* ${nonarch_base_libdir}/udev/rules.d/" +FILES:${PN} = "${libdir}/libts.so.*" FILES:${PN}-dev = "${TS_INSTALL}/lib/cmake ${TS_INSTALL}/include ${libdir}/libts.so"
optee-client now provides them and sets "tee" group for /dev/tee* and "teepriv" group for /dev/teepriv* access. tee-supplicant runs as "teesuppl" user account. Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> --- .../trusted-services/libts/tee-udev.rules | 7 ------- .../trusted-services/libts_git.bb | 19 ++----------------- 2 files changed, 2 insertions(+), 24 deletions(-) delete mode 100644 meta-arm/recipes-security/trusted-services/libts/tee-udev.rules