Hi,

FYI - In preparation for the next OP-TEE release, I have rebased linaro-swg/linux branch optee onto Linux kernel v5.17. The only differences between our branch and upstream are:

• DTS updates
• One commit reverted pending a fix in the Xen mediator. Note that Xen 4.16.0 has the fix, but Buildroot is still using 4.14.x.

I'm trying to port optee to allwinner h5 board and for that I've created nano.xml here, and makefile based on juno.mk called nano.mk

I am able to compile the framwork and create bootable sd card but when I boot up I am getting following screenshot result :

some notes:
art-tf : I've ported support for allwinner h5 board called sun50iw2p1 here
optee_os: I've made changes for h5 board support here
linux: I'm using frendlyarm core linux as seen here

I'm thinking do I have to use linaro-swg/linux ?
if so I don't see support for all winner h5 board

appreciate any advice

Thanks

Avani

There are multiple issues with device PTA driver:

1. It uses old style TMEM arg even with dynamic SHM enabled. Xen is not happy about this
2. If optee_enumerate_devices() fails, optee_driver_init() fails. But actually optee can work without this feature. Does it means, than older OP-TEE versions are not supported anymore?
3. Drivers panics during optee_remove()

Basically I'm getting this error log:

optee: probing for conduit method from DT.                                                         
optee: revision 3.8                                                                                
optee: dynamic shared memory is enabled    
(XEN) optee.c:868:d0v0 Guest tries to use old tmem arg
optee: PTA_CMD_GET_DEVICES invoke function err: ffff0006                                           
Unable to handle kernel NULL pointer dereference at virtual address 00000058
Mem abort info:                                 
  Exception class = DABT (current EL), IL = 32 bits  
  SET = 0, FnV = 0                         
  EA = 0, S1PTW = 0                         
Data abort info:                                                                                   
  ISV = 0, ISS = 0x00000005         
  CM = 0, WnR = 0                                                                                  
[0000000000000058] user address but active_mm is swapper                                           
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:     
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.75-ltsi-yocto-tiny #7                               
Hardware name: Renesas Salvator-XS board based on r8a7795 ES2.0+ (DT)                              
task: ffffffc6dd908000 task.stack: ffffffc6dd904000                             
PC is at tee_shm_free+0x18/0x40                  
LR is at optee_disable_shm_cache+0x88/0xbc       
pc : [<ffffff80083f45a4>] lr : [<ffffff80083f6540>] pstate: 80000045
sp : ffffffc6dd907c80
x29: ffffffc6dd907c80 x28: ffffff8008729300 
x27: 0000000000000007 x26: ffffff80086f8078 
x25: ffffffc6d76d4980 x24: 0000000000000004 
x23: ffffff8008559798 x22: 00000000b200000a 
x21: ffffffc6dd907ce0 x20: ffffffc6dd0c2c00 
x19: 0000000000000000 x18: 0000000000000010 
x17: 0000000000007fff x16: 00000000deadbeef 
x15: 0000000000000000 x14: ffffffc6dce4f028 
x13: ffffffc6d76cfba0 x12: 0000000000000020 
x11: ffffffc6dce4eff8 x10: ffffffc6d76cfba0 
x9 : 0000000000000001 x8 : ffffff80083f5598 
x7 : 0000000000000000 x6 : 0000000000000000 
x5 : 0000000000000000 x4 : 0000000000000000 
x3 : 0000000000000000 x2 : 0000000000000000 
x1 : 0000000000000000 x0 : ffffff80083f6540 
Process swapper/0 (pid: 1, stack limit = 0xffffffc6dd904000)
Call trace:
Exception stack(0xffffffc6dd907b40 to 0xffffffc6dd907c80)
7b40: ffffff80083f6540 0000000000000000 0000000000000000 0000000000000000
7b60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
7b80: ffffff80083f5598 0000000000000001 ffffffc6d76cfba0 ffffffc6dce4eff8
7ba0: 0000000000000020 ffffffc6d76cfba0 ffffffc6dce4f028 0000000000000000
7bc0: 00000000deadbeef 0000000000007fff 0000000000000010 0000000000000000
7be0: ffffffc6dd0c2c00 ffffffc6dd907ce0 00000000b200000a ffffff8008559798
7c00: 0000000000000004 ffffffc6d76d4980 ffffff80086f8078 0000000000000007
7c20: ffffff8008729300 ffffffc6dd907c80 ffffff80083f6540 ffffffc6dd907c80
7c40: ffffff80083f45a4 0000000080000045 ffffffc6dd907cb0 ffffff80083f6520
7c60: ffffffffffffffff ffffffc6dd0c2c00 ffffffc6dd907c80 ffffff80083f45a4
[<ffffff80083f45a4>] tee_shm_free+0x18/0x40
[<ffffff80083f6540>] optee_disable_shm_cache+0x88/0xbc
[<ffffff80083f5a90>] optee_remove+0x20/0x68
[<ffffff80086e08f4>] optee_driver_init+0x5ac/0x5ec
[<ffffff8008083078>] do_one_initcall+0x104/0x114
[<ffffff80086b0f0c>] kernel_init_freeable+0x228/0x22c
[<ffffff80084fbe68>] kernel_init+0x18/0x108
[<ffffff8008084218>] ret_from_fork+0x10/0x18
Code: f9000bf3 aa0003f3 aa1e03e0 d503201f (b9405a60) 
---[ end trace b20a0eef62340328 ]---

Note that Xen mediator returns an error and then kernel panics.

In call.c, optee_open_session(), the destination uuid in arg->uuid is being copied twice instead of copying the arg->clnt_uuid field.

memcpy(&msg_arg->params[0].u.value, arg->uuid, sizeof(arg->uuid));
memcpy(&msg_arg->params[1].u.value, arg->uuid, sizeof(arg->clnt_uuid));

Note, in optee_client/libteec/src/tee_client_api.c TEEC_OpenSession() clnt_uuid is not being initialized.

Hi,

I have pushed a new branch called wip/optee-v5.5 which is our current linaro-swg/linux.git branch optee rebased onto upstream kernel 5.5 (and with upstream-tee-subsys-patches.txt updated).

Sanity-tested on QEMU, HiKey and HiKey960. I'd like to replace the tip of the optee branch with this new one soon.

If anyone has any issue with that, please comment here! Thanks.

FYI, I have just rebased branch optee onto upstream v6.2-rc3, which notably brings in a fix for trusted keys (see this discussion). Previous head of branch saved as branch-optee-5.19-2023011.

Looks like the shared memory allocated by linux tee driver (via IOCTL TEE_IOC_SHM_ALLOC) is not zeroed out.

I verified this by modifying tee_client_api.c for checking for non-null bytes in mmap memory in function: TEEC_AllocateSharedMemory.

This could be exploited to leak data.

Is there any reason why it is not Zeroed out? or Am i missing something?

Hi

Currently the "optee_enable_shm_cache" cause the kmemleak false alarm,
This API pre alloc shm buffer for better performance, but if linux kernel
enable CONFIG_DEBUG_KMEMLEAK, show the leak record likes:

cat /sys/kernel/debug/kmemleak

unreferenced object 0xffffff8108ecd600 (size 128):
comm "android.hardwar", pid 229, jiffies 4294893003 (age 919.340s)
hex dump (first 32 bytes):
00 d1 ec 08 81 ff ff ff 00 d0 5c 07 01 00 00 00 ...............
00 d0 5c 07 81 ff ff ff 00 10 00 00 00 00 00 00 ...............
backtrace:
[<000000001e549164>] optee_handle_rpc+0x78/0x828 [optee]
[<0000000092ae58d4>] optee_do_call_with_arg+0x1ec/0x330 [optee]
[<00000000385ef677>] optee_open_session+0x1bc/0x28c [optee]
[<0000000038996787>] tee_ioctl_open_session+0x16c/0x5a0 [tee]
[<0000000080aeafb5>] tee_ioctl+0x78/0x450 [tee]
[<0000000074d1f571>] __arm64_compat_sys_ioctl+0x170/0x584
[<00000000b390ddec>] el0_svc_common+0xc8/0x22c
[<00000000131581a6>] el0_svc_compat_handler+0x1c/0x28

the backtrace should be like that:
optee_handle_rpc
handle_rpc_func_cmd
handle_rpc_func_cmd_shm_alloc
tee_shm_alloc
shm = kzalloc(sizeof(*shm), GFP_KERNEL);

is any better way to avoid it ? or just disable the shm cache method
if CONFIG_DEBUG_KMEMLEAK=y ?

thanks

Hello,

I am trying to run OPTEE-OS on i.MX6Q Sabre Automotive board.
I added following lines to imx6qdl-sabreauto.dtsi:

reserved-memory {
    #address-cells = <1>;
    #size-cells = <1>;
    ranges;

    optee@0x8D000000 {
        reg = <0x8D000000 0x03000000>;
    };
};

firmware {
    optee {
        compatible = "linaro,optee-tz";
        method = "smc";
    };
};

Kernel fails on invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res);

I use signed u-boot and zImage, but I don't burn fuses. My boot security configuration is Open.
I need enable secure boot for running optee drivers? Or my dts file is wrong?

linux_panic_optee.txt

Hi @jenswi-linaro ,

We've faced an issue with tee_shm_alloc kernel API when migrating from optee 3.7 to 3.10.
Our driver was using a shared memory allocated as follow:
shm = tee_shm_alloc(ctx,size,TEE_SHM_MAPPED);

which was used in parameter of tee_client_invoke_func:
param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
param[1].u.memref.shm_offs = offset;
param[1].u.memref.size = size;
param[1].u.memref.shm = shm;

but it seems that it is no more possible with optee 3.10 and we have to allocate shared memory with TEE_SHM_DMA_BUF flag.
without doing that set_tmem_param return TEE_ERROR_BAD_PARAMETERS because our buffer is not in the contiguous shared memory (or OPTEE static shared memory).

However tee_shm_alloc will allocate into the dynamic shared memory area without the OPTEE_MSG_ATTR_NONCONTIG attribute.

Could you tell me if it is a restriction or not ?

Best regards,
Olivier

Do we have a plan for the ION patches in the optee branch?
They have been there for quite some time and I suppose they are quite painful to rebase.

I know that /dev/tee is for normal client to do operations like opening session, invoking command and so on. /dev/teepriv is for tee-supplicant to do PRC command receiving and sending.
I'm wondering why we don't put these operation in one device file. In the optee_supp_desc structure, TEE_DESC_PRIVILEGED flag will be set. What's the usage for this flag? or what's the usage for TEE_GEN_CAP_PRIVILEGED capability exported by tee_ioctl_version?

Thanks

Hello,

I find a memory leak in optee driver introduced by the following commit:
9d5c773

the driver do not release correctly a dma_buf_attachment structure when releasing a file descriptor shared memory.
PFA a patch to fix the issue.

0001-MMIOT-674-Add-missing-DMA-Buf-detach.zip

BR / Olivier

Hello dev's,

in order to add our recent added STM32MP15 DHSOM based boards to OP-TEE/build and OP-TEE/manifest, it would be good to upgrade Linux to 5.18 or even better to 5.19.

Before creating a pull request, I would like to ask what is the preferred approach to this process?

The possible solutions to fully support our boards are:

1. backport needed patches to 5.17 and define OP-TEE resources.
2. bump Linux to 5.18 or even better to 5.19 and define OP-TEE resources

Thanks in advance,
Johann

Dear Team,
I am working on Android 9.0 (Pie) where Linux kernel version used is 4.14.98. Along with Android we are planning to use OPTEE 3.13.
So please can you refer me the source code of Linux OP-TEE Driver for Linux version 4.14.98 and OP-TEE version 3.13?
We are working on Armv8 (i.MX8MQ), so Arm-Trusted-Firmware also used (2.0). Is there any dependency is there on the ATF version for using OP-TEE 3.13?

Thanks and Regards,
Devendra

rpi3-optee-4.14 branch cannot compile, due to, possibly the last commit. Especially there is no sec_caps
in the definition of struct optee in optee_private.h.

Since it is OP-TEE release time again, we may as well update our Linux branch. Therefore I have rebased the optee branch (which is currently based on Linux v5.5) onto the latest upstream (v5.9-rc8).

The new branch is wip/optee-v5.9-rc8. I will use this branch when testing OP-TEE on QEMU, QEMUv8, HiKey and HiKey960. I have NOT touched the optee branch yet.

@etienne-lms a couple of patches caused conflicts due to different file names upstream and some changes already applied:
5973cd5 ARM: dts: stm32: Define OP-TEE resources on stm32mp15 and enable on DK2
b7b9d31 ARM: dts: stm32: bump PSCI to version 1.0 on stm32mp15x
Can you please check if what I have done is OK? The 2nd patch seems to be upstream already so it does not appear in the rebased branch.

Hi,
I want to use network on FVP, I added "--network=nat" at the end of "~/devel/optee/build/Makefile"
but there was not ip addr when I booted into the kernel, ifconfig shows as below:
image

FVP host is ubuntu-16.04 inside VirtualBox

I am not familiar with network. is there anyone can help me ? thanks a lot!

Hi,
I just cloned the latest tee driver code from this tee branch. I found a issue about using msleep() in handle_rpc_func_cmd_wait() function. msleep() will call schedule_timeout_uninterruptible() internally and calling thread will become uninterruptible, so it has no effect to call "set_current_state(TASK_INTERRUPTIBLE)" before calling msleep(). I suggest to use msleep_interruptible() directly to substitute following code segment:

/* set task's state to interruptible sleep */
set_current_state(TASK_INTERRUPTIBLE);

/* take a nap */
msleep(msec_to_wait);

Please review, thanks

Dears,

I have found the drivers/tee/ is different between 5.x, and remove the DMA-BUF support.

How does the newest linux tee driver transfer the dma-buf type from REE to TEE?

Many thanks.

While rebasing our optee branch onto kernel v5.8, I noticed that upstream is missing this patch:
https://lkml.org/lkml/2020/7/10/358

Is it expected?

I am facing issues on arm aarch64. For example the following code in core.c in optee driver:
invoke_fn(OPTEE_SMC_CALLS_UID, 0, 0, 0, 0, 0, 0, 0, &res);

As all arguments are expected to be 64 bit, OPTEE_SMC_CALLS_UID is signed extended to 64 making the higher 32 bits are all '1'.

This is causing issues with OPTEE and it is not able to recognize the SMC function id.

Has OPTEE 2.0.0 tested on a aarch64 platform or am I doing something wrong?

I guess macros such as

define ARM_SMCCC_FAST_CALL 1

define ARM_SMCCC_STD_CALL 0

needs to be replaced by

define ARM_SMCCC_FAST_CALL 1U

define ARM_SMCCC_STD_CALL 0U

in file include/linux/arm-smccc.h or change in optee function id comparision (optee os compares this function id value with unsigned value)

After the above mentioned changed, my xtests are running on aarch64 platform

FYI, I have rebased linaro-swg/linux branch optee onto Linux kernel v5.13. The previous tip of the branch is saved as tag optee-v5.12-20210628. The only remaining differences between our branch and upstream are:

1. The "benchmark" support code,
2. DTS updates.

Shared memory ids are stored in struct tee_device, which is common to all clients connected to tee driver.
A potentially malicious user space client can hijack shared memory allocated to another user space client by spoofing id.

Although, ids are created using idr_alloc, it is better to either store pid's in struct tee_shm (so that we can verify when referred) or store struct tee_shm in struct tee_context for every user space client (while searching for ids we use the tee_shm from tee_context, this way there is no need to do additional pid checking).

Hi,

If I'm not mistaken, it's soon OP-TEE release time, so it may be a good time to consider rebasing our kernel branch (which is currently based on Linux 5.0).

Therefore, I have prepared wip/optee-5.3 which is linaro-swg/linux.git branch optee rebased onto upstream kernel 5.3 (and with the upstream-tee-subsys-patches.txt file updated).

Sanity-tested on QEMU, I'll check HiKey and HiKey960 tomorrow. Assuming all is well, @jbech-linaro @jenswi-linaro let me know if you're OK with replacing the tip of the optee branch with this new one. Thanks!

Hi. Is it possible to add cmake command to normal world for CMake.txt files?

Hello,
I was just encountered an issue with CA break linux system suspend operation. Linux freezer reports the corresponding CA process can't be froze.
Here is the scenario:

• CA process invoke command into TA.
• TA use RPC call to tee-supplicant.
• TA(CA context) wait tee-supplicant result in OP-TEE Driver.
• User trigger system sleep(echo mem > /sys/power/state).
• tee-supplicant be frozen by linux freezer.
• Here is the issue, tee-supplicant be frozen first, so the TA(CA context) has no chance to back to CA.
• The freezer keep polling CA state wait its PF_FROZEN be set, until system suspend timeout and abort.

I just noted that linux freezer has some help functions to avoid this happened(refer to include/linux/freezer.h).
e.g.

	freezer_do_not_count()
	wait_for_completion(x)
	freezer_count()

Check with the latest OP-TEE Driver seems doesn't utilize this kind of help function.
Not sure this is the correct way or OP-TEE Driver has other consideration of this.
So do we have plan to update OP-TEE Driver more friendly with linux freezer ?

Thanks!

Hello!

I need some newer Linux features. However, the current RPi3 supported Linux version for OP-TEE is rpi3-optee-5.4
I need at least 5.14.

It seems that rpi3-optee-5.4 and main are not very different, considering only the "on-top-of-mainline" commits. I thought I might only have to cherry-pick some commits from the rpi3 branch into the main branch. However, it failed already for the first commit ( 196e461 ) because the files arch/arm/boot/dts/bcm2710-rpi-3-b.dts and arch/arm/boot/dts/bcm2710.dtsi are missing. Maybe it's sufficient to only copy this file from the old branch into the new one.

But before I dive deeper, I wanted to ask some developers experienced in this matter if my goal is quickly achievable or if there are huge problems I can't see. Thanks!

OPTEE OS: v3.12
linux tee driver: Tag - optee v3.12
Hi, I was trying to enable dynamic shared memory in OP-TEE OS and use the API thread_rpc_alloc_global_payload to allocate shared memory for DMA usage, but I failed. After tracking the code, I found that the pages and page_num in the shared memory object were null, which led to the failure. See the details below:

		pages = tee_shm_get_pages(shm, &page_num);
		if (!pages || !page_num) {
			arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
			goto bad;
		}

After reviewing the tee_shm_alloc and pool_op_alloc, and found out that the 'pages' and 'num_pages' haven't been set, see below:
tee_shm.c

struct tee_shm *tee_shm_alloc(struct tee_context *ctx, size_t size, u32 flags)
{
	struct tee_device *teedev = ctx->teedev;
	struct tee_shm_pool_mgr *poolm = NULL;
	struct tee_shm *shm;
	void *ret;
	int rc;

	if (!(flags & TEE_SHM_MAPPED)) {
		dev_err(teedev->dev.parent,
			"only mapped allocations supported\n");
		return ERR_PTR(-EINVAL);
	}

	if ((flags & ~(TEE_SHM_MAPPED | TEE_SHM_DMA_BUF))) {
		dev_err(teedev->dev.parent, "invalid shm flags 0x%x", flags);
		return ERR_PTR(-EINVAL);
	}

	if (!tee_device_get(teedev))
		return ERR_PTR(-EINVAL);

	if (!teedev->pool) {
		/* teedev has been detached from driver */
		ret = ERR_PTR(-EINVAL);
		goto err_dev_put;
	}

	shm = kzalloc(sizeof(*shm), GFP_KERNEL);
	if (!shm) {
		ret = ERR_PTR(-ENOMEM);
		goto err_dev_put;
	}

	shm->flags = flags | TEE_SHM_POOL;
	shm->ctx = ctx;
	if (flags & TEE_SHM_DMA_BUF)
		poolm = teedev->pool->dma_buf_mgr;
	else
		poolm = teedev->pool->private_mgr;

	rc = poolm->ops->alloc(poolm, shm, size);
	if (rc) {
		ret = ERR_PTR(rc);
		goto err_kfree;
	}


	if (flags & TEE_SHM_DMA_BUF) {
		DEFINE_DMA_BUF_EXPORT_INFO(exp_info);

		mutex_lock(&teedev->mutex);
		shm->id = idr_alloc(&teedev->idr, shm, 1, 0, GFP_KERNEL);
		mutex_unlock(&teedev->mutex);
		if (shm->id < 0) {
			ret = ERR_PTR(shm->id);
			goto err_pool_free;
		}

		exp_info.ops = &tee_shm_dma_buf_ops;
		exp_info.size = shm->size;
		exp_info.flags = O_RDWR;
		exp_info.priv = shm;

		shm->dmabuf = dma_buf_export(&exp_info);
		if (IS_ERR(shm->dmabuf)) {
			ret = ERR_CAST(shm->dmabuf);
			goto err_rem;
		}
	}

	teedev_ctx_get(ctx);

	return shm;
err_rem:
	if (flags & TEE_SHM_DMA_BUF) {
		mutex_lock(&teedev->mutex);
		idr_remove(&teedev->idr, shm->id);
		mutex_unlock(&teedev->mutex);
	}
err_pool_free:
	poolm->ops->free(poolm, shm);
err_kfree:
	kfree(shm);
err_dev_put:
	tee_device_put(teedev);
	return ret;
}

optee/shm_pool.c
static int pool_op_alloc(struct tee_shm_pool_mgr *poolm,
			 struct tee_shm *shm, size_t size)
{
	unsigned int order = get_order(size);
	struct page *page;
	int rc = 0;

	page = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
	if (!page)
		return -ENOMEM;

	shm->kaddr = page_address(page);
	shm->paddr = page_to_phys(page);
	shm->size = PAGE_SIZE << order;

	if (shm->flags & TEE_SHM_DMA_BUF) {
		unsigned int nr_pages = 1 << order, i;
		struct page **pages;

		pages = kcalloc(nr_pages, sizeof(pages), GFP_KERNEL);
		if (!pages)
			return -ENOMEM;

		for (i = 0; i < nr_pages; i++) {
			pages[i] = page;
			page++;
		}

		shm->flags |= TEE_SHM_REGISTER;
		rc = optee_shm_register(shm->ctx, shm, pages, nr_pages,
					(unsigned long)shm->kaddr);
		kfree(pages);
	}

	return rc;
}

optee/rpc.c
static void handle_rpc_func_cmd_shm_alloc(struct tee_context *ctx,
					  struct optee_msg_arg *arg,
					  struct optee_call_ctx *call_ctx)
{
	phys_addr_t pa;
	struct tee_shm *shm;
	size_t sz;
	size_t n;

	arg->ret_origin = TEEC_ORIGIN_COMMS;

	if (!arg->num_params ||
	    arg->params[0].attr != OPTEE_MSG_ATTR_TYPE_VALUE_INPUT) {
		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
		return;
	}

	for (n = 1; n < arg->num_params; n++) {
		if (arg->params[n].attr != OPTEE_MSG_ATTR_TYPE_NONE) {
			arg->ret = TEEC_ERROR_BAD_PARAMETERS;
			return;
		}
	}

	sz = arg->params[0].u.value.b;
	switch (arg->params[0].u.value.a) {
	case OPTEE_MSG_RPC_SHM_TYPE_APPL:
		shm = cmd_alloc_suppl(ctx, sz);
		break;
	case OPTEE_MSG_RPC_SHM_TYPE_KERNEL:
		shm = tee_shm_alloc(ctx, sz, TEE_SHM_MAPPED);
		break;
	case OPTEE_MSG_RPC_SHM_TYPE_GLOBAL:
		shm = tee_shm_alloc(ctx, sz, TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
		break;
	default:
		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
		return;
	}

	if (IS_ERR(shm)) {
		arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
		return;
	}

	if (tee_shm_get_pa(shm, 0, &pa)) {
		arg->ret = TEEC_ERROR_BAD_PARAMETERS;
		goto bad;
	}

	sz = tee_shm_get_size(shm);

	if (tee_shm_is_registered(shm)) {
		struct page **pages;
		u64 *pages_list;
		size_t page_num;

		pages = tee_shm_get_pages(shm, &page_num);
		if (!pages || !page_num) {
			arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
			goto bad;
		}

		pages_list = optee_allocate_pages_list(page_num);
		if (!pages_list) {
			arg->ret = TEEC_ERROR_OUT_OF_MEMORY;
			goto bad;
		}

		call_ctx->pages_list = pages_list;
		call_ctx->num_entries = page_num;

		arg->params[0].attr = OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT |
				      OPTEE_MSG_ATTR_NONCONTIG;
		/*
		 * In the least bits of u.tmem.buf_ptr we store buffer offset
		 * from 4k page, as described in OP-TEE ABI.
		 */
		arg->params[0].u.tmem.buf_ptr = virt_to_phys(pages_list) |
			(tee_shm_get_page_offset(shm) &
			 (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1));
		arg->params[0].u.tmem.size = tee_shm_get_size(shm);
		arg->params[0].u.tmem.shm_ref = (unsigned long)shm;

		optee_fill_pages_list(pages_list, pages, page_num,
				      tee_shm_get_page_offset(shm));
	} else {
		arg->params[0].attr = OPTEE_MSG_ATTR_TYPE_TMEM_OUTPUT;
		arg->params[0].u.tmem.buf_ptr = pa;
		arg->params[0].u.tmem.size = sz;
		arg->params[0].u.tmem.shm_ref = (unsigned long)shm;
	}

	arg->ret = TEEC_SUCCESS;
	return;
bad:
	tee_shm_free(shm);
}

Q1, When will the shm->pages be assigned? And, it will be freed in the tee_shm_release -> release_registered_pages.
Q2, Can the memory allocated by this API thread_rpc_alloc_global_payload is suitable for DMA usage?

Tested on qemu_v8

To reproduce

1. Checkout and build latest kernel (I used commit 4a704d6)
2. Run xtest

Kernel panics:

• regression_1001 Core self tests
  [ 7.055672] Unable to handle kernel paging request at virtual address ffff80003fe00000
  [ 7.055882] Mem abort info:
  [ 7.055981] Exception class = DABT (current EL), IL = 32 bits
  [ 7.056100] SET = 0, FnV = 0
  [ 7.056175] EA = 0, S1PTW = 0
  [ 7.056261] Data abort info:
  [ 7.056335] ISV = 0, ISS = 0x00000071
  [ 7.056423] CM = 0, WnR = 1
  [ 7.056550] swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff000008f49000
  [ 7.056704] [ffff80003fe00000] *pgd=00000000820f8003, *pud=00000000820f7003, *pmd=000000007ff14003, *pte=00e800007fe00712
  [ 7.057069] Internal error: Oops: 96000047 [#1] PREEMPT SMP
  [ 7.057261] Modules linked in:
  [ 7.057505] CPU: 0 PID: 1201 Comm: xtest Not tainted 4.14.0-rc1-00070-g4a704d6 #109
  [ 7.057664] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
  [ 7.057841] task: ffff800040569f80 task.stack: ffff0000096f8000
  [ 7.058005] PC is at __memset+0x1ac/0x1d0
  [ 7.058098] LR is at pool_op_gen_alloc+0x58/0x90
  [ 7.058254] pc : [] lr : [] pstate: 40000145

The same test on linaro/optee (ac0c2c2) works perfectly fine.

Small test shows that memory is remapped just fine, but access to it generates panic:

diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 7952357..2b96f70 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -388,7 +388,12 @@ optee_config_shm_memremap(optee_invoke_fn *invoke_fn, void **memremaped_shm)
                return ERR_PTR(-EINVAL);
        }
        vaddr = (unsigned long)va;
-
+       pr_info("remapped at %p\n", va);
+       pr_info("Trying direct access\n");
+       *((int*)va) = 0xFF;
+       pr_info("Trying memset\n");
+       memset(va, 0, size);
+       pr_info("Done\n");
        priv_info.vaddr = vaddr;
        priv_info.paddr = paddr;
        priv_info.size = OPTEE_SHM_NUM_PRIV_PAGES * PAGE_SIZE;

[ 3.460483] optee: probing for conduit method from DT.
[ 3.461409] optee: remapped at ffff80003fe00000
[ 3.461486] optee: Trying direct access
[ 3.461725] Unable to handle kernel paging request at virtual address ffff80003fe00000
[ 3.461832] Mem abort info:
[ 3.461900] Exception class = DABT (current EL), IL = 32 bits
[ 3.462004] SET = 0, FnV = 0
[ 3.462104] EA = 0, S1PTW = 0
[ 3.462220] Data abort info:
[ 3.462276] ISV = 0, ISS = 0x00000071
[ 3.462338] CM = 0, WnR = 1

I'm currently investigating this further.

hi，i had add the bench.c and its related codes into linux，but there are something wrong when compilation：
LD vmlinux.o
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
LD .tmp_vmlinux.kallsyms1
aarch64-v01c01-linux-musl-ld: warning: -z norelro ignored
aarch64-v01c01-linux-musl-ld: Unexpected GOT/PLT entries detected!
aarch64-v01c01-linux-musl-ld: Unexpected run-time procedure linkages detected!
aarch64-v01c01-linux-musl-ld: drivers/tee/optee/bench.o: in function optee_bm_timestamp': bench.c:(.text+0x14c): undefined reference to __aarch64_ldadd8_acq_rel'
Makefile:1185: recipe for target 'vmlinux' failed

i dont know how to fix it

Hi,

In preparation for the next OP-TEE release, I have rebased linaro-swg/linux branch optee onto Linux kernel v5.16. The previous tip of the branch is saved as tag optee-v5.14-20220110. The only differences between our branch and upstream are:

1. DTS updates
2. One commit reverted pending a fix in the Xen mediator.

This time I have completely removed the remaining bits of the dma-buf code (Secure Data Path) and the benchmark API, because it became to complex to apply to upstream.