op-tee / optee_linuxdriver Goto Github PK

Hi,
I really want to write a module using functions in the tee_kernel_api.c， But, It can't work. I guess the reason is the functions can't work on the 64 bit platform, because I find there are some notes like this /* TODO fixme will not work on 64-bit platform */. I tried to change type of fd from int to uint64_t, but it have no effect. So, I have to ask you for help.

At https://github.com/OP-TEE/optee_linuxdriver/blob/master/core/tee_supp_com.c#L215, commFromUser.nbr_bf is completely user controlled and it could be greater than TEE_RPC_BUFFER_NUMBER, this potentially leads to for loop reading and writing to heap over bounds.

I've been checking the tee_kernel_api.c to know more about the login methods specified by GP. I see that they seem not to be implemented. I know for sure that you support TEE_LOGIN_TRUSTED_APP to communicate between TAs, but I was curious how the login would work for REE applications. I see GP specifies for some logins that the REE must provide a UUID and this is REE dependant. Do you know more about this? Are you planning on supporting that part of the GP spec? And do you know where could I get more information on the issue?

Thanks in advance,
Roberto

I want to port optee_linuxdriver which can support optee_os version >= 3.13.0 into linux4.9.37 ,how can I achive it

Dear Pascal :
TEEC_Result TEEC_InitializeContext(const char name, TEEC_Context *context)
{
/ TODO fixme will not work on 64-bit platform */
context->fd = (int)(uintptr_t)ctx;
}
May i ask about this problem , because when I use this function in 64 bit platform, kernel panic will happen , but i have no idea how to fix it . Can you give me more information about this ?

Hi all,

I'm doing some tests with the A80 OptimusBoard and OP-TEE. However I found problems when trying to use the kernel provided by Merrii (3.4.39) and the driver provided here. I see you basically indicate a kernel 3.10.32.

I tried providing the missing pieces like a couple of scatter/gather functions in scatterlist.h and .c that do not depend on any other thing, and some inclusions of linux/module.h to fix some THIS_MODULE and EXPORT_SYMBOL missing symbols. As the change was not complicated I would expect it to work, but basically tee-supplicant is crashing the board. I forgot to mention I'm running Android on the board. I have similar experience with the Juno board and it worked fine but the kernel was a 3.10.72.

This is the stack trace I get when running the supplicant:

[  684.296651] [<bf215a3c>] (tz_start+0x90/0x17c [optee_armtz]) from [<bf222a48>] (tee_get+0x84/0xf8 [optee])
[  684.307659] [<bf222a48>] (tee_get+0x84/0xf8 [optee]) from [<bf222e84>] (tee_context_create+0xa4/0x10c [optee])
[  684.319051] [<bf222e84>] (tee_context_create+0xa4/0x10c [optee]) from [<bf222510>] (tee_ctx_open+0xdc/0x114 [optee])
[  684.331007] [<bf222510>] (tee_ctx_open+0xdc/0x114 [optee]) from [<c031002c>] (misc_open+0x130/0x1a0)
[  684.341364] [<c031002c>] (misc_open+0x130/0x1a0) from [<c0113174>] (chrdev_open+0x12c/0x154)
[  684.350935] [<c0113174>] (chrdev_open+0x12c/0x154) from [<c010ce18>] (__dentry_open+0x1b4/0x2c0)
[  684.360899] [<c010ce18>] (__dentry_open+0x1b4/0x2c0) from [<c010e0bc>] (nameidata_to_filp+0x64/0x74)
[  684.371255] [<c010e0bc>] (nameidata_to_filp+0x64/0x74) from [<c011cebc>] (do_last+0x800/0x810)
[  684.381020] [<c011cebc>] (do_last+0x800/0x810) from [<c011d0d4>] (path_openat+0xc8/0x38c)
[  684.390293] [<c011d0d4>] (path_openat+0xc8/0x38c) from [<c011d4bc>] (do_filp_open+0x3c/0x88)
[  684.399861] [<c011d4bc>] (do_filp_open+0x3c/0x88) from [<c010e20c>] (do_sys_open+0x140/0x1d4)
[  684.409527] [<c010e20c>] (do_sys_open+0x140/0x1d4) from [<c010e2d0>] (sys_open+0x30/0x34)
[  684.418802] [<c010e2d0>] (sys_open+0x30/0x34) from [<c000ff00>] (ret_fast_syscall+0x0/0x30)

How can I check that the TEE OS is effectively being loaded? The modules seem to load fine but I remember having similar issues in the Juno board when the TEE OS was not properly loaded.

Also I'm not sure if I can just use a higher version of the kernel if I want to retain all the HW acceleration capabilities of the A80.

Excuse me if this is not the appropriate channel to contact you, but had no other contact.

Many thanks,
Roberto

Hi, I'd like to write a device driver which need to connect to tee. But the kernel module made a mistake : "kernel panic - not syncing : BUG!" Maybe It because I called the functions in "tee_kernel_api.c",such as TEEC_InitializeContext. It makes me confused, why the TEE_TZ_DEVICE_NAME is defined "opteearm3200"? it may be "opteearmtz00". And if the functions can work on the 64-bit platform?

I ran "setup_juno_optee.sh" script(got it from optee_os git) and encountered an error when building the linux driver.

The error was about dma_buf_export function called in "core/tee_shm.c".
It complains about the number of arguments passed to the function (5 arguments are passed when it expects 4.)

      In core/tee_shm.c
      dmabuf = dma_buf_export(shm, &_tee_shm_dma_buf_ops, shm->size_alloc, O_RDWR, 0);

Indeed according to the linux source code(linux/include/linux/dma-buf.h) dma_buf_export macro function expects just 4 arguments.

     #define dma_buf_export(priv, ops, size, flags) \
            dma_buf_export_named(priv, ops, size, flags, KBUILD_MODNAME)

I thought that the 5th argument might be unnecessary in that its value is 0, so I removed it from the linux driver code.
After this modification I could build the linux driver just fine and it seems to work properly when actually running CA and TA.

My question here is whether the modification I made is valid.

It seems that the interface(type signature) of "dma_buf_export" function differs by linux versions.

To make the driver more compatible, how about put some "if def" and determine the version of "dma_buf_export" function to be called at compile time?
(-> maybe it's not possible since the driver is built using liux kernel build system? Just suggesting!)

I am trying to add another module which depends on optee_armtz. I was wondering how I can get that into the (module).mod.c __module_depends[] variable. I can't see how in the makefile set up current, how the build process knows that optee_armtz depends on core/. Thanks.

In the code _update_client_tee_cmd. I have some uncertainty about here. _update_client_tee_cmd is copy result when OP-TEE OS return,but in case TEEC_MEMREF_TEMP_OUTPUT and TEEC_MEMREF_TEMP_INOUT in first "if size_new != cmd_io->op->params[idx].tmpref.size" will use tee_put_user re-update value of cmd_io->op->params[idx].tmpref.size. But in the following judgment of "if (size_new > cmd_io->op->params[idx].tmpref.size)" will never be True. "dev_err" will not occur . The following behavior of tee_copy_to_user (ctx, cmd_io->op->params[idx].tmpref.buffer, cmd->param.params[idx].shm->kaddr, size_new) will copy the risk of over boundary??

In https://github.com/OP-TEE/optee_linuxdriver/blob/master/core/tee_session.c#L600, param->c_shm[idx] is copied from user.

In https://github.com/OP-TEE/optee_linuxdriver/blob/master/core/tee_session.c#L628, where we call tee_shm_get:
tee_shm_get(ctx, &param->c_shm[idx], size, offset)

Then in function: tee_shm_get (https://github.com/OP-TEE/optee_linuxdriver/blob/master/core/tee_shm.c#L716) , Here, c_shm is copied from user (i.e param->c_shm[idx]).

Then the check in 741, i.e:
if (c_shm->flags & TEEC_MEM_KAPI) {
//Now, kc_shm is User Controlled.
struct tee_shm *kc_shm = (struct tee_shm *)c_shm->d.ptr;

    if (!kc_shm) {
        dev_err(_DEV(tee), "kapi fd null\n");
        ret = -EINVAL;
        goto err;
    }
           //  Here shm->paddr is controlled by user.
    shm->paddr = kc_shm->paddr;

This could be exploited to pass arbitrary physical address to Trustlets.

Hi!

I am having trouble using the opteearmtz device in linux 4.4.0. When I try to access the device, I get the following error:

root@zynq7:~# cat /dev/opteearmtz00
Entry fast...
armv7sec armv7sec.0: shm ioremap failed
misc opteearmtz00: tee_get: opteearmtz00::start() failed, err=-12
cat: can't open '/dev/opteearmtz00': Cannot allocate memory

The address of the shared memory that it is trying to remap is properly read from OPTEE, and so is the size. I.e. they match the values specified in the OPTEE_OS build. So the interface to OPTEE and secure world is working. However, I suspect that the Linux ioremap command is failing because the shared memory is RAM and the ioremap method doesn't like that.

Is there a workaround for this issue?

In the code I am working on, data are sent in a loop to tee-supplicant. Two buffers are allocated using thread_optee_rpc_alloc_payload() (one for the request, one for the response) [here]. Then thread_rpc_cmd() is called several times [here], and finally the buffers are freed by thread_optee_rpc_free_payload() [here].

This code causes a kernel crash as thread_rpc_cmd() is called for the second time.

DBG TEE-CORE:tee_rpmb_write:1283: len 1040, block address 505, block count 5, byte offset 0
FLW TEE-CORE:tee_rpmb_write:1291: Branch 2
FLW TEE-CORE:tee_rpmb_read:1091: tee_rpmb_alloc returned 0x0
DBG TEE-CORE:tee_rpmb_read:1111: BLOCK READ 5 blocks at index 505
FLW TEE-CORE:tee_rpmb_resp_unpack_verify:742: tee_rpmb_data_cpy_mac_calc res=0x0
FLW TEE-CORE:tee_rpmb_read:1140: 0x0,0
DBG TEE-CORE:tee_rpmb_write:1301: tee_rpmb_read returned 0x0
DBG TEE-CORE:tee_rpmb_write_blk:1223: BLOCK WRITE 1 block at index 505
DBG TEE-CORE:tee_rpmb_write_blk:1223: BLOCK WRITE 1 block at index 506
misc opteearmtz00: Can't find shm for 000000003ef0a000
------------[ cut here ]------------
kernel BUG at ../optee_linuxdriver/core/tee_supp_com.c:221!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in: optee_armtz(O) optee(O)
CPU: 2 PID: 772 Comm: tee-supplicant Tainted: G           O    4.3.0 #115
[...]

There is no crash if the allocation and deallocation are moved inside the loop (see this commit).
Test environment: HiKey, project hikey_optee branch rpmbdev.

Please also note that the bug is not reproducible with the "generic driver".

Hi,

I got a problem when I install the OP-TEE Linux Driver. It said that "optee: section 2 reloc 398 sym 'tee_smc_call': relocation 10 out of range (0x7f808efa -> 0x7f809334)
insmod: ERROR: could not insert module ./optee.ko: Invalid module format." I want to know have you ever see this problem before? What should I do?

Thanks a lot,