Implements LOGIN_APPLICATION and LOGIN_USER_APPLICATION #121

Kh-Oleg · 2025-02-18T15:19:02Z

This PR implements the GlobalPlatform's LOGIN_APPLICATION and LOGIN_USER_APPLICATION methods, by adding the executable path and name to the input string for the UUIDv5 hashing algorithm.

From the commit below, the mt8173-evb failed to boot to console due to changes in the mt8173 device tree files. commit c0d6fe2 Merge: b44a3d2 3e4dda7 Author: Linus Torvalds <[email protected]> Date: Tue Nov 10 15:06:26 2015 -0800 Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Until properly solved, let's just remove the section in the device tree blob that causes this. Signed-off-by: Joakim Bech <[email protected]> Reviewed-by: Pascal Brand <[email protected]>

Configures foundation-v8 with OP-TEE. Signed-off-by: Jens Wiklander <[email protected]> [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>

Configures Juno with OP-TEE. Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>

…dation-v8 **not for mainline** All the platforms that reserve memory for OP-TEE statically via the DT (i.e., not those that reserve it via UEFI or that patch the DT dynamically thanks to OP-TEE's CFG_DT option) have to mark it 'no-map' so that only the TEE driver may map it. Signed-off-by: Jens Wiklander <[email protected]>

… **not for mainline** All the platforms that reserve memory for OP-TEE statically via the DT (i.e., not those that reserve it via UEFI or that patch the DT dynamically thanks to OP-TEE's CFG_DT option) have to mark it 'no-map' so that only the TEE driver may map it. Signed-off-by: Jens Wiklander <[email protected]>

Signed-off-by: Joakim Bech <[email protected]> Reviewed-by: Pascal Brand <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>

Reserve memory for bootloader purposes. Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]>

Add optee node, so OP-TEE driver is probed properly. Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]>

Define OP-TEE firmware node for stm32mp15 based platforms. The node if disable by default. Enable the OP-TEE node and define OP-TEE reserved memory for stm32mp157c-dk2. Signed-off-by: Etienne Carriere <[email protected]> [jf: rebase onto v5.9] Signed-off-by: Jerome Forissier <[email protected]>

Signed-off-by: Javier Almansa Sobrino <[email protected]> Acked-by: Joakim Bech <[email protected]> Link: linaro-swg#85 [jf: not currently intended for upstream; add link to PR] Signed-off-by: Jerome Forissier <[email protected]>

The optee device status is disabled by default, change its status to 'okay' in the dts of the EV1 board Signed-off-by: Timothée Cercueil <[email protected]> [jf: rebase onto v5.17] Signed-off-by: Jerome Forissier <[email protected]>

This change fixes EV1 configuration which lacked OP-TEE reserved memory. This change also makes ED1 board ready the host OP-TEE by enabling OP-TEE node and defining the OP-TEE reserved memory for that board. This change defines these resources in ED1 DTS file which is included in EV1 DTS file. Signed-off-by: Etienne Carriere <[email protected]> Acked-by: Jerome Forissier <[email protected]> [jf: rebase onto v5.17] [jf: rebase onto v6.6] Signed-off-by: Jerome Forissier <[email protected]>

Configures FVP Base RevC with OP-TEE. With commit 1bf41f5d9b0d ("fvp: add Trusted Services support") in https://github.com/OP-TEE/build there is support for building running with the FVP Base RevC model. However, some updates to the DTB passed to the kernel is missing for the OP-TEE driver to be probed. So fix that by adding an OP-TEE node in the DTS. Signed-off-by: Jens Wiklander <[email protected]>

Enable OP-TEE node defined in stm32mp151.dtsi and define OP-TEE reserverd memory for all boards based on STM32MP15 DHCOM. Signed-off-by: Johann Neuhauser <[email protected]> Acked-by: Etienne Carriere <[email protected]>

Enable OP-TEE node defined in stm32mp151.dtsi and define OP-TEE reserverd memory for all boards based on STM32MP15 DHCOR. Signed-off-by: Johann Neuhauser <[email protected]> Acked-by: Etienne Carriere <[email protected]>

If a USB-A to USB-A cable is used to flash the RockPi4 eMMC as described in [1], it is likely that the board will be booted with the cable still plugged into the board and into the computer on the other side. Such a configuration results in periodic error messages from the kernel: [ 4.832697] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 4.833416] usb usb6-port1: config error That is annoying, especially since the messages are also sent to the console by default, which could mess up with CI scripts. Therefore, disable this port (it is the upper USB3 blue port; the lower one will still work fine). Link: [1] https://wiki.radxa.com/Rockpi4/dev/usb-install Signed-off-by: Jerome Forissier <[email protected]> Acked-by: Jens Wiklander <[email protected]> Acked-by: Joakim Bech <[email protected]>

Add optee node as well as reserved memory to the Rockpi4 DT. Signed-off-by: Jerome Forissier <[email protected]>

jforissier

Hi,

Thanks for the patch. Please see comments below.

jforissier · 2025-02-24T09:46:27Z

drivers/tee/tee_core.c

@@ -254,6 +255,38 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method,
 		}
 		break;

+	case TEE_IOCTL_LOGIN_APPLICATION:
+		{
+			char path[512];


jforissier · 2025-02-24T09:53:52Z

drivers/tee/tee_core.c

@@ -254,6 +255,38 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method,
 		}
 		break;

+	case TEE_IOCTL_LOGIN_APPLICATION:


Please update the comment block above.

jforissier · 2025-02-24T09:54:15Z

drivers/tee/tee_core.c

+		}
+		break;
+
+	case TEE_IOCTL_LOGIN_USER_APPLICATION:


Please update the comment block above.

jforissier · 2025-02-24T09:54:23Z

drivers/tee/tee_core.c

+
+	case TEE_IOCTL_LOGIN_USER_APPLICATION:
+		{
+			char path[512];


jenswi-linaro · 2025-02-24T10:00:30Z

This has also been discussed at https://lists.trustedfirmware.org/archives/list/[email protected]/thread/6HLJ2GROVHZGY2LX7HGHOQ53YIFIC6PW/#6HLJ2GROVHZGY2LX7HGHOQ53YIFIC6PW

jforissier

Please squash all the changes in a single patch and add:

Acked-by: Jerome Forissier <[email protected]>

Please also consider the discussion mentioned by @jenswi-linaro.

jenswi-linaro · 2025-02-24T15:08:02Z

drivers/tee/tee_core.c

+	case TEE_IOCTL_LOGIN_APPLICATION:
+		{
+			char path[PATH_MAX];
+			if (get_cmdline(current, path, sizeof(path)) >= sizeof(path)) {


How accurate is this when taking chroot and different techniques into account?

Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Oleg Kharitonov <[email protected]>

Kh-Oleg · 2025-02-25T14:20:35Z

Hello, I squashed the commits and added "Acked-by".

With regards to the above mentioned discussion, there are several points being discussed:

Getting rid of TEE_UUID_NS_NAME_SIZE, by calling snprintf twice
In my view, from performance reasons, it's probably, better to increase TEE_UUID_NS_NAME_SIZE to some reasonable size (let's say 1024) to support majority of the cases rather than always execute snprintf second time.
Adding Konfig parameter to choose between path and extended attributes.
This goes beyond the scope of my PR. In my case, path based app id is enough. If the extended attributes method is necessary/desirable it can be done later as a separate PR.
chroot
If I'm not wrong, chroot requires root privileges. If the attacker could get root privileges, he can simply replace the original CA binary.
d_path vs d_absolute_path
With the current implementation running CA as my_app, ./my_app or /opt/bin/my_app will end up in generating different UUIDs, which has pros and cons. I feel that restricting to the absolute path only is too strong. The current implementation leaves it up to the user: if TA developer needs a fixed absolute path, he can calculate the UUID based on it and require CA to be always run using the absolute path.

Which one would you like to address in this PR to have it merged?

jenswi-linaro · 2025-02-26T13:42:43Z

Why are you proposing a PR to this repository instead of posting a patch on the LKML? A patch landed here is only temporary until we tire of it and remove it when we rebase the patches for a newer kernel. To get into the mainline kernel, it must follow the normal kernel process.

What you're proposing is an extension to the ABI. Once established, it cannot break userspace in further changes. So, it's important to get it right and try to be flexible enough for reasonable use cases. Kconfig is not a good way to select between two incompatible implementations.

What problem are you trying to solve with this patch?

Kh-Oleg · 2025-02-26T14:37:09Z

I created the PR to this repo, because this repo is used in the OPTEE manifests: https://github.com/OP-TEE/manifest/blob/master/common.xml#L13. I thought that contribution to this repo will end up in the next release of OPTEE.

Let me describe the problem and then we can decide whether we should proceed and how.

I am developing a TA, based on GlobalPlatform API, which shall be compiled and run for different TEEs. OPTEE running in QEMU is one of them. My TA uses LOGIN_APPLICATION and LOGIN_USER_APPLICATION methods to implement access control. It is desirable that OPTEE would support these login methods in some way, assuming that exec path is taken into account when calculating UUID. Otherwise, my TA and tests must have different implementations, depending on the TEE used, what I'd like to avoid.

I solved my problem by having a locally patched driver, but I thought that maybe it will be good to upstream the changes. Having a less flexible implementation which could be improved later is better than not having the feature at all. Breaking changes, if necessary, can be done via versioning and deprecation of the client library and driver.

If you're in principle not objecting from accepting the changes, please, let me know what is missing and what is the right way to contribute. Otherwise, the PR can be closed.

jenswi-linaro · 2025-02-26T15:34:02Z

I solved my problem by having a locally patched driver, but I thought that maybe it will be good to upstream the changes.

That makes a lot of sense and is the right thing to do. However, this isn't upstream for the kernel. This is where we keep local patches needed for our OP-TEE specific test setups. Your patch might have qualified for that if it wasn't for the fact that it touches on standardized interfaces. Once we support LOGIN_APPLICATION and LOGIN_USER_APPLICATION here, people will expect that this is the OP-TEE way. So I'd rather see that they can make it into the mainline kernel before we start to promise things.

Having a less flexible implementation which could be improved later is better than not having the feature at all. Breaking changes, if necessary, can be done via versioning and deprecation of the client library and driver.

We don't do breaking changes in the kernel and have no desire to accumulate baggage due to premature ABI changes.
If we've messed up and there's no way for a nice fix we may need to resort to fixes like that.

If you're in principle not objecting from accepting the changes, please, let me know what is missing and what is the right way to contribute. Otherwise, the PR can be closed.

We can continue the review here for a while longer. I'm interested in @vesajaaskelainen's thoughts on this. If the patch is received well on the LKML we can take it here too so it's available before we've stepped up the kernel.

Passing a sufficient amount of imix entries leads to invalid access to the pkt_dev->imix_entries array because of the incorrect boundary check. UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imix_pkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 linaro-swg#121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl lib/dump_stack.c:117 __ubsan_handle_out_of_bounds lib/ubsan.c:429 get_imix_entries net/core/pktgen.c:874 pktgen_if_write net/core/pktgen.c:1063 pde_write fs/proc/inode.c:334 proc_reg_write fs/proc/inode.c:346 vfs_write fs/read_write.c:593 ksys_write fs/read_write.c:644 do_syscall_64 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130 Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 52a62f8 ("pktgen: Parse internet mix (imix) input") Signed-off-by: Artem Chernyshev <[email protected]> [ fp: allow to fill the array completely; minor changelog cleanup ] Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: David S. Miller <[email protected]>

jbech-linaro and others added 17 commits December 2, 2024 12:03

arm64: dt: OP-TEE for foundation-v8 **not for mainline**

80fa328

Configures foundation-v8 with OP-TEE. Signed-off-by: Jens Wiklander <[email protected]> [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>

arm64: dt: OP-TEE for Juno **not for mainline**

77807de

Configures Juno with OP-TEE. Reviewed-by: Pascal Brand <[email protected]> Signed-off-by: Jens Wiklander <[email protected]> [jf: rebase onto v5.9-rc7] Signed-off-by: Jerome Forissier <[email protected]>

arm64: dt: Add OP-TEE firmware to mt8173 **not for mainline**

f3ac939

Signed-off-by: Joakim Bech <[email protected]> Reviewed-by: Pascal Brand <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>

arm64: dts: hi3798cv200-poplar: memreserve for bootloader

36ea285

Reserve memory for bootloader purposes. Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]>

arm64: dts: hi3798cv200-poplar: add optee node

d01ca7e

Add optee node, so OP-TEE driver is probed properly. Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Igor Opaniuk <[email protected]>

stm32mp157c-ev1.dts: Fix optee status to 'okay'

57841ba

The optee device status is disabled by default, change its status to 'okay' in the dts of the EV1 board Signed-off-by: Timothée Cercueil <[email protected]> [jf: rebase onto v5.17] Signed-off-by: Jerome Forissier <[email protected]>

arm64: dt: rockpi4: add OP-TEE nodes **not for mainline**

4da2533

Add optee node as well as reserved memory to the Rockpi4 DT. Signed-off-by: Jerome Forissier <[email protected]>

jforissier reviewed Feb 24, 2025

View reviewed changes

jenswi-linaro reviewed Feb 24, 2025

View reviewed changes

Implements LOGIN_APPLICATION and LOGIN_USER_APPLICATION

a267ac0

Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Oleg Kharitonov <[email protected]>

Kh-Oleg force-pushed the optee branch from 4a11bc5 to a267ac0 Compare February 25, 2025 13:27

jforissier force-pushed the optee branch from 4da2533 to 7ff2e50 Compare May 9, 2025 08:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implements LOGIN_APPLICATION and LOGIN_USER_APPLICATION #121

Implements LOGIN_APPLICATION and LOGIN_USER_APPLICATION #121

Kh-Oleg commented Feb 18, 2025

jforissier left a comment

jforissier Feb 24, 2025

Kh-Oleg Feb 24, 2025

jforissier Feb 24, 2025

Kh-Oleg Feb 24, 2025

jforissier Feb 24, 2025

Kh-Oleg Feb 24, 2025

jforissier Feb 24, 2025

Kh-Oleg Feb 24, 2025

jenswi-linaro commented Feb 24, 2025

jforissier left a comment

jenswi-linaro Feb 24, 2025

Kh-Oleg commented Feb 25, 2025 •

edited

Loading

jenswi-linaro commented Feb 26, 2025

Kh-Oleg commented Feb 26, 2025

jenswi-linaro commented Feb 26, 2025

Implements LOGIN_APPLICATION and LOGIN_USER_APPLICATION #121

Are you sure you want to change the base?

Implements LOGIN_APPLICATION and LOGIN_USER_APPLICATION #121

Conversation

Kh-Oleg commented Feb 18, 2025

jforissier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jenswi-linaro commented Feb 24, 2025

jforissier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kh-Oleg commented Feb 25, 2025 • edited Loading

jenswi-linaro commented Feb 26, 2025

Kh-Oleg commented Feb 26, 2025

jenswi-linaro commented Feb 26, 2025

Kh-Oleg commented Feb 25, 2025 •

edited

Loading