Hi,

First of all, I want to thank you for your work.
This is a really amazing project!

In Aurora OS we use OP-TEE as a base for various security improvements. In particular, we need to log security events and — depending on system configuration — store them locally or send to a remote server.
For that purpose Aurora OS has a logging service provided via a certain set of API. To make logging available in TEE we have implemented a new RPC service and a deferred work framework (to flush early-boot events when tee_supplicant is ready).
We beleive that functionality might be useful, so we'd like to share it.

However, since our logger implementation depends on REE OS logging mechanisms, we think it might be helpful to render tee-supplicant a bit more flexible in terms of providing services. We propose to add a framework for loadable plugins in tee-supplicant.
We can do it with the help of dynamic shared objects, loading them in runtime with libdl.

To create a plugin one would need to:

1. Implement the plugin's methods according to this header:

#ifndef PLUGIN_METHOD_H
#define PLUGIN_METHOD_H

struct plugin_method {
    int (*init)(void);
    int (*fini)(void);
    int (*invoke)(int cmd, void *data);
};

/* the bind function must save plugin methods into the passed argument */
#define IMPLEMENT_PLUGIN_METHOD_BIND_FN(fn) \
    int supplicant_plugin_bind_func(struct plugin_method *m); \
    int supplicant_plugin_bind_func(struct plugin_method *m) { \
                if(!fn(m)) return 0; \
                return 1; }

#endif /* PLUGIN_METHOD_H */

2. Compile the plugin as a .so file and place it in a system directory (e.g. /usr/lib/tee-supplicant/plugins/). Plugins can be easily installed/updated this way.

tee-supplicant is assumed to load all the plugins found in the above directory into a list, binding external functions during startup process. For tee-supplicant a plugin can be described as:

#ifndef PLUGIN_H
#define PLUGIN_H

#include <plugin_method.h>

struct plugin {
    uuid_t *uuid;
    struct plugin_method *method; /* implemented by plugins' authors */
    int references;
    struct plugin *next;
};

/* loads all shared objects from /usr/lib/tee-supplicant/plugins/ and binds all functions */
int plugin_load_all(void);

/* used in RPC handler to handle TEE requests and run some plugin commands */
int plugin_invoke(uuid_t *uuid, int cmd, void *data);

#endif /* PLUGIN_H */

3. We assume that in TEE we add a common interface for the plugins. It is a new RPC-call for kernel code.
   And to use the plugins from TAs code we propose to implement a new special PTA in optee core.
   Thereby TAs might communicate with any plugins through the open/invoke/close interfaces.

After tee-supplicant has loaded every plugin, optee-os can use them with either a direct RPC-call from the kernel
or via a new PTA from TAs.

Example of plugin code:

#include <plugin_method.h>

/* It's assumed that the plugin's file name after compilation will be equal to its UUID */
#define PLUGIN_UUID \   
          { 0x4f5a5123, 0x0acc, 0x4ad4, \
                                    { 0x83, 0x11, 0x22, 0xfd, 0x7b, 0x70, 0x89, 0x78} }

static int awesome_plugin_init(void) {return 0;}
static int awesome_plugin_finit(void) {return 0;}
static int awesome_plugin_invoke(int cmd, void *data)
{
    switch(cmd) {
    case AWESOME_CMD:
        awesome_cmd_func(data);
        break;
    }
    return 0;
}

static int awesome_plugin_bind_helper(plugin_method *m)
{
    m->init = awesome_plugin_init;
    m->fini = awesome_plugin_finit;
    m->invoke = awesome_plugin_invoke;

    return 0;
}

IMPLEMENT_PLUGIN_METHOD_BIND_FN(awesome_plugin_bind_helper);

Example of using the plugin from OP-TEE kernel

plugin_rpc(awesome_plugin_uuid, AWESOME_CMD, data);

Example of an RPC handler in tee-supplicant

plugin_invoke(awesome_plugin_uuid, AWESOME_CMD, data);

Summary:

• If someone needs a new feature in the supplicant that isn't needed in upstream, they can use the unified plugin interface
• Easy to sync upstream version with own fork.
• No need to add new RPC-calls for new feature.

We would like to know your opinion about the proposed design.
What do you think about this?

Thank you!

Hello there,

I am using Hello world : https://github.com/linaro-swg/hello_world example to understand working of TEEC_RequestCancellation API. I have created a thread to cancel the TA. In that thread I am cancelling TA after a small delay. I have given more delay in TA so that TA is still alive when TEEC_RequestCancellation using TEE_Wait(). Here is the gist containing HOST, TA and output.

I have used TEE_UnmaskCancellation, TEE_GetCancellationFlag APIs. I have referred TEE_Internal_Core_API_Specification and TEE_Client_API_Specification document. Please let me know if I am missing something. Any idea @jenswi-linaro @jbech-linaro @jforissier @vchong Also I would like to know more about working of TEEC_RequestCancellation.

Thanks in Advance. :)

I have put the patches from https://lkml.org/lkml/2016/10/28/244 on v4.9 kernel, plus some extra dts stanza for hikey taken from an earlier patch series

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

It's using latest pieces for optee_os / client / test

NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.1(release):bdec62e
NOTICE:  BL1: Built : 11:11:48, Jun 23 2016
NOTICE:  syspll frequency:1190494208Hz
NOTICE:  succeed to init lpddr3 rank0 dram phy
INFO:    lpddr3_freq_init, set ddrc 533mhz
INFO:    init ddr3 rank0
INFO:    ddr3 rank1 init pass
INFO:    lpddr3_freq_init, set ddrc 800mhz
INFO:    init ddr3 rank0
INFO:    ddr3 rank1 init pass
INFO:    Elpida DDR
NOTICE:  BL1: Booting BL2
NOTICE:  acpu_dvfs_set_freq: set acpu freq success!NOTICE:  BL2: v1.1(release):b85b3f3
NOTICE:  BL2: Built : 14:03:59, Dec 28 2016
NOTICE:  BL1: Booting BL3-1
NOTICE:  BL3-1: v1.1(release):b85b3f3
NOTICE:  BL3-1: Built : 14:03:59, Dec 28 20INFO:    TEE-CORE: Initializing (2.2.0-150-g9d98bb2 #1 Mon Dec 26 02:54:58 UTC 2016 aarch64)
INFO:    TEE-CORE: Initialized

The kernel works well, and there is a /dev/tee0 and /dev/teepriv0 created. It seems the tee pieces have no complaint

# dmesg | grep tee
[    0.491002] optee firmware:optee: probing for conduit method from
DT.
[    0.491863] optee firmware:optee: initialized driver

After I removed the ancient optee pieces from the debian image ^^ and confirmed the pieces I built are binding to my libs ^^ I get this

root@hikey1:~# tee-supplicant &
[1] 2936
root@hikey1:~# xtest
Run test suite with lev[ 2184.302158] Unable to handle kernel paging
request at virtual address dededf0e
el=0

TEE test[ 2184.310986] pgd = ffff80003b9d4000
 application sta[ 2184.315643] [dededf0e] *pgd=000000003bc02003rted
with device [(null)]
#####[ 2184.321123] , *pud=0000000000000000
################[ 2184.327364] 
################[ 2184.330172] Internal error: Oops: 96000005 [#1]
PREEMPT SMP
################[ 2184.337191] Modules linked in:#
#
# XTEST_TE cfg80211E_TEST
#
##### rfkill################ adv7511################
kirin_drm################ dw_drm_dsi#
 
* XTEST_TE drm_kms_helperE_1001 Core self drm tests
  XTEST_ cdc_etherTEE_1001 OK
 
 usbnet* XTEST_TEE_1004 r8152 Test User Crypt ipv6 TA

[ 2184.365256] CPU: 1 PID: 2937 Comm: xtest Not tainted 4.9.0-aist-tb-
hikey-00011-gea6e826 #3
[ 2184.373665] Hardware name: HiKey Development Board (DT)
[ 2184.378980] task: ffff80003a87d780 task.stack: ffff80003b7b0000
[ 2184.385009] PC is at tee_shm_get_va+0x8/0x20
[ 2184.389352] LR is at optee_handle_rpc+0x9c/0x4d0
[ 2184.394048] pc : [<ffff0000087578ec>] lr : [<ffff0000087596e8>]
pstate: 60000145
[ 2184.401571] sp : ffff80003b7b3ba0
[ 2184.404939] x29: ffff80003b7b3ba0 x28: ffff80003b7b3dc8 
[ 2184.410356] x27: ffff000008892000 x26: ffff80003a5dd180 
[ 2184.415772] x25: 000000003ee00000 x24: 00000000ffff0000 
[ 2184.421188] x23: 00000000dededede x22: 00000000ffffffff 
[ 2184.426604] x21: ffff80003b4ac418 x20: ffff80003b92e280 
[ 2184.432020] x19: ffff80003b7b3c78 x18: 0000ffffd8b61ec0 
[ 2184.437434] x17: 0000000000000000 x16: 0000000000000000 
[ 2184.442849] x15: 0000000000000000 x14: 0000000000000000 
[ 2184.448263] x13: 0000000000000000 x12: 0000000000000000 
[ 2184.453677] x11: 0000000000000000 x10: 0000000000000000 
[ 2184.459093] x9 : 0000000000000000 x8 : 0000000000000000 
[ 2184.464508] x7 : 0000000000000000 x6 : 0000000000000000 
[ 2184.469922] x5 : 0000000000000000 x4 : 00000000dededede 
[ 2184.475336] x3 : 0000000000000000 x2 : 00000000dededede 
[ 2184.480750] x1 : 0000000000000000 x0 : ffffffffffffffea 
[ 2184.486165] 
[ 2184.487678] Process xtest (pid: 2937, stack limit =
0xffff80003b7b0020)
[ 2184.494408] Stack: (0xffff80003b7b3ba0 to 0xffff80003b7b4000)
[ 2184.500255] 3ba0: ffff80003b7b3c20 ffff000008758e8c ffff80003b4ac418
ffff80003b92e280
[ 2184.508223] 3bc0: ffff80003b7b3c98 00000000ffffffff ffff80003b4ac438
00000000ffff0000
[ 2184.516191] 3be0: 000000003ee00000 ffff000008758b84 ffff80003b7b3c20
ffff000008758e18
[ 2184.524158] 3c00: ffff80003b4ac418 ffff80003b92e280 ffff80003b7b3c98
ffff000008757c94
[ 2184.532125] 3c20: ffff80003b7b3cf0 ffff0000087590cc ffff80003b7b3dc8
0000000000000000
[ 2184.540092] 3c40: ffff80003a5dd100 ffff80003b92e280 ffff80003a5dd080
ffff000009000060
[ 2184.548059] 3c60: ffff80003b92ed00 000000000000001d ffff80003b7b3ca0
00000000ffff0005
[ 2184.556026] 3c80: 00000000dededede 0000000000000000 0000000000000000
00000000ffff0005
[ 2184.563993] 3ca0: 0000000000000000 00000000dededede 0000000000000000
ffff80003b4ac460
[ 2184.571960] 3cc0: ffff80003b4ac460 ffff000000000000 ffff800000000000
ffff80003b7b3cd8
[ 2184.579927] 3ce0: ffff80003b7b3cd8 0000ffffd8b62000 ffff80003b7b3d50
ffff000008757200
[ 2184.587894] 3d00: 0000ffffd8b62070 0000ffffd8b62038 ffff80003b92e280
ffff80003a5dd080
[ 2184.595861] 3d20: 000000008010a402 0000ffffd8b62028 0000000000000123
000000000000001d
[ 2184.603828] 3d40: ffff000009000000 000000003ee00000 ffff80003b7b3e00
ffff0000081e74b8
[ 2184.615106] 3d60: ffff80003b4dde00 0000ffffd8b62028 ffff80003b53c598
0000000000000003
[ 2184.626411] 3d80: 000000008010a402 0000ffffd8b62028 0000000000000123
000000000000001d
[ 2184.637724] 3da0: ffff000008892000 ffff80003b7b0000 0000000000000002
0000ffffd8b62038
[ 2184.648977] 3dc0: 00000000000000b8 e011f1ada05b3ecb 1bc5d5a502008b99
0000000000000000
[ 2184.660195] 3de0: 0000000000000000 0000000000000000 0000000000000000
0000000400000000
[ 2184.671369] 3e00: ffff80003b7b3e80 ffff0000081e7c04 0000000000000000
ffff80003b4dde00
[ 2184.682497] 3e20: ffff80003b4dde00 0000000000000003 000000008010a402
0000000000000000
[ 2184.693614] 3e40: ffff80003b7b3e80 ffff0000081e7bc0 0000000000000000
ffff80003b4dde00
[ 2184.704620] 3e60: ffff80003b4dde00 0000000000000003 000000008010a402
ffff0000081e7ba4
[ 2184.715519] 3e80: 0000000000000000 ffff000008082ef0 0000000000000000
0000000000000000
[ 2184.726365] 3ea0: ffffffffffffffff 0000ffff9dd3b81c 0000000060000000
0000000000000015
[ 2184.737192] 3ec0: 0000000000000003 000000008010a402 0000ffffd8b62028
0000000000000030
[ 2184.748014] 3ee0: ffffffffffffffd0 0000000000000040 000000000000003f
0000000000000000
[ 2184.758852] 3f00: 000000000000001d 0000000000000004 7f7fffffffffffff
0101010101010101
[ 2184.769661] 3f20: 0000000000000018 0000000000000000 0000ffff9dc7ba94
0000ffff9ddc0588
[ 2184.780436] 3f40: 0000ffff9dea1eb0 0000ffff9dd3b810 0000ffffd8b61ec0
0000000000000000
[ 2184.791242] 3f60: 0000000000000000 0000000000401a70 0000000000000000
0000000000000000
[ 2184.802069] 3f80: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2184.812871] 3fa0: 0000000000000000 0000ffffd8b61f10 0000ffff9de90f88
0000ffffd8b61f10
[ 2184.823713] 3fc0: 0000ffff9dd3b81c 0000000060000000 0000000000000003
000000000000001d
[ 2184.834576] 3fe0: 0000000000000000 0000000000000000 aa1b03e1f8607820
aa1b03e194000000
[ 2184.845454] Call trace:
[ 2184.850933] Exception stack(0xffff80003b7b39d0 to
0xffff80003b7b3b00)
[ 2184.860547] 39c0:                                   ffff80003b7b3c78
0001000000000000
[ 2184.871669] 39e0: ffff80003b7b3ba0 ffff0000087578ec 0000000000000200
ffff80003bd51900
[ 2184.882869] 3a00: ffff80003b92e280 0000000000000000 ffff80003b7b3a20
ffff00000836b744
[ 2184.894132] 3a20: ffff80003b7b3aa0 ffff00000836ba78 0000000000000001
ffff80003bfa8400
[ 2184.905447] 3a40: ffff80003b7b3ae8 ffff80003bfa87b0 ffff80003b7b3a60
ffff0000080e1534
[ 2184.916808] 3a60: ffff80003b7b3ac0 ffff0000080e170c ffffffffffffffea
0000000000000000
[ 2184.928234] 3a80: 00000000dededede 0000000000000000 00000000dededede
0000000000000000
[ 2184.939676] 3aa0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2184.951092] 3ac0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2184.962427] 3ae0: 0000000000000000 0000000000000000 0000000000000000
0000000000000000
[ 2184.973685] [<ffff0000087578ec>] tee_shm_get_va+0x8/0x20
[ 2184.982380] [<ffff000008758e8c>] optee_do_call_with_arg+0xe8/0x134
[ 2184.991959] [<ffff0000087590cc>] optee_open_session+0xf0/0x1b0
[ 2185.001157] [<ffff000008757200>] tee_ioctl+0x9ec/0xca4
[ 2185.009664] [<ffff0000081e74b8>] do_vfs_ioctl+0xa8/0x770
[ 2185.018344] [<ffff0000081e7c04>] SyS_ioctl+0x84/0x98
[ 2185.026656] [<ffff000008082ef0>] el0_svc_naked+0x24/0x28
[ 2185.035307] Code: 52800003 17fffffb aa0003e2 928002a0 (f9401843) 
[ 2185.054095] ---[ end trace c242f3dcac1bfb26 ]---

Segmentation fault

It\s quite possible I am doing something stupid... but any ideas what?

Hi All,

I want to use Openssl libraries from the client(host) side. How to get the libraries and headers into a QEMU client system? I can induvidually compile the libs using the toolchains under optee-qemu/toolchains/aarch32/bin/arm-linux-gnueabihf. However I need toexport the libraries and header to the OP-TEE client. What is the way to do this? How can I include sources as well? Which build script should I change?

Where to copy the "openssl " folder that I have built?

Thanks,
Tera

external/optee_client/libteec/src/tee_client_api.c:488:11: error: fields must have a constant size: 'variable length array in structure' extension will never be supported
                uint8_t data[sizeof(struct tee_ioctl_open_session_arg) + p_sz];
                        ^
external/optee_client/libteec/src/tee_client_api.c:566:11: error: fields must have a constant size: 'variable length array in structure' extension will never be supported
                uint8_t data[sizeof(struct tee_ioctl_invoke_arg) + p_sz];
                        ^

Re: https://stackoverflow.com/questions/14629504/variable-length-array-in-the-middle-of-struct-why-this-c-code-is-valid-for-gcc

Any ideas? Can we define the struct sizes as constants? Something else?

struct tee_ioctl_param_memref {
        __u64 shm_offs;
        __u64 size;
        __s64 shm_id;
};

struct tee_ioctl_param_value {
        __u64 a;
        __u64 b;
        __u64 c;
};

struct tee_ioctl_param {
        __u64 attr;
        union {
                struct tee_ioctl_param_memref memref;
                struct tee_ioctl_param_value value;
        } u;
};

struct tee_ioctl_open_session_arg {
        __u8 uuid[TEE_IOCTL_UUID_LEN];
        __u8 clnt_uuid[TEE_IOCTL_UUID_LEN];
        __u32 clnt_login;
        __u32 cancel_id;
        __u32 session;
        __u32 ret;
        __u32 ret_origin;
        __u32 num_params;
        /*
         * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
         * which follows requires 8 byte alignment.
         *
         * Commented out element used to visualize the layout dynamic part
         * of the struct. This field is not available at all if
         * num_params == 0.
         *
         * struct tee_ioctl_param params[num_params];
         */
} __aligned(8);

struct tee_ioctl_invoke_arg {
        __u32 func;
        __u32 session;
        __u32 cancel_id;
        __u32 ret;
        __u32 ret_origin;
        __u32 num_params;
        /*
         * this struct is 8 byte aligned since the 'struct tee_ioctl_param'
         * which follows requires 8 byte alignment.
         *
         * Commented out element used to visualize the layout dynamic part
         * of the struct. This field is not available at all if
         * num_params == 0.
         *
         * struct tee_ioctl_param params[num_params];
         */
} __aligned(8);

Hi there!

My application sends data with a known size to the TA using Shared Memory but the returned size is unknown. Because of this it's not really an option to create a return buffer for it as overestimating the size of the returned data and copying less isn't what I'm looking for, I'll need something more deterministic.

My question is, is there an option to reallocate the shared memory buffer to a bigger size from inside the TA and write data into the extended buffer? It would make creating place for the returned data much easier as the TA knows how much data was created and once the data is returned the Rich App can just read it from the end of the buffer.

I hope my question can be understood I'm happy to provide more info if it's a bit ... weird.

Hi, the GlobalPlattform TEE Client API Specification states that TEEC_RegisterSharedMemory "SHOULD attempt to transfer data in to the TEE without using copies, if this is possible on the underlying implementation, but MUST fall back on data copies if zero-copy cannot be achieved."

Do you know if zero-copy is realized in OP-TEE's implementation of TEEC_RegisterSharedMemory?

Hi All,

I am trying to run a trusted application and have allocated around 5mb stack and 1 mb heap space.
I am getting this error and not sure about the root cause for this.

Can someone explain what is depicted in this log ?

D/TC:2 0 abort_handler:518 [abort] abort in User mode (TA will panic)
E/TC:? 0
E/TC:? 0 User mode data-abort at address 0x0 (translation fault)
E/TC:? 0 esr 0x92000005 ttbr0 0x2000010190040 ttbr1 0x00000000 cidr 0x0
E/TC:? 0 cpu #2 cpsr 0x40000100
E/TC:? 0 x0 0000000000077690 x1 00000000406b4120
E/TC:? 0 x2 0000000000000210 x3 0000000000000000
E/TC:? 0 x4 0000000000000000 x5 0000000000000000
E/TC:? 0 x6 0000000000000000 x7 00000000406b40cc
E/TC:? 0 x8 0000000000000035 x9 000000004009d418
E/TC:? 0 x10 0000000000000000 x11 0000000000000000
E/TC:? 0 x12 0000000000000000 x13 00000000406b4048
E/TC:? 0 x14 0000000000000000 x15 0000000000000000
E/TC:? 0 x16 0000000010123f70 x17 0000000000000000
E/TC:? 0 x18 0000000000000000 x19 00000000400b3fa4
E/TC:? 0 x20 0000000000000000 x21 00000000400a0000
E/TC:? 0 x22 0000000000000210 x23 000000004009d000
E/TC:? 0 x24 000000004009d547 x25 000000001a896779
E/TC:? 0 x26 00000000400b3f00 x27 0000000000000000
E/TC:? 0 x28 0000000000000000 x29 00000000406b4070
E/TC:? 0 x30 000000004008d220 elr 00000000400927e4
E/TC:? 0 sp_el0 00000000406b4070
E/LD: Status of TA 37d82404-6269-4ab8-924e-76cd69fcfffb
E/LD: arch: aarch64
E/LD: region 0: va 0x40004000 pa 0x10800000 size 0x002000 flags rw-s (ldelf)
E/LD: region 1: va 0x40006000 pa 0x10802000 size 0x008000 flags r-xs (ldelf)
E/LD: region 2: va 0x4000e000 pa 0x1080a000 size 0x001000 flags rw-s (ldelf)
E/LD: region 3: va 0x4000f000 pa 0x1080b000 size 0x004000 flags rw-s (ldelf)
E/LD: region 4: va 0x40013000 pa 0x1080f000 size 0x001000 flags r--s
E/LD: region 5: va 0x4008c000 pa 0x00001000 size 0x013000 flags r-xs [0]
E/LD: region 6: va 0x4009f000 pa 0x00014000 size 0x115000 flags rw-s [0]
E/LD: region 7: va 0x401b4000 pa 0x10938000 size 0x501000 flags rw-s (stack)
E/LD: [0] 37d82404-6269-4ab8-924e-76cd69fcfffb @ 0x4008c000
E/LD: Call stack:
E/LD: 0x00000000400927e4
E/LD: 0x000000004008d21c
E/LD: 0x000000004008d3f8
E/LD: 0x000000004008ce90
E/LD: 0x000000004008c2e8
E/LD: 0x000000004008c174
E/LD: 0x000000004008c090
E/LD: 0x0000000040092f78
E/LD: 0x0000000040090460
D/TC:? 0 user_ta_enter:176 tee_user_ta_enter: TA panicked with code 0xdeadbeef
D/TC:? 0 tee_ta_close_session:514 csess 0x10178b40 id 1
D/TC:? 0 tee_ta_close_session:533 Destroy session
D/TC:? 0 destroy_context:310 Destroy TA ctx (0x10178ae0)
E/TC:? 0 tee_ta_open_session:769 Failed. Return error 0xffff3024

Thanks

Soname libckteec.so.ckteec is wrong and should be libckteec.so.0.

I have implemented a host application which starts multiple threads (1, 2, 4 or 8). Each of the threads redoes a so called query method/transaction during a fixed amount of time. This query transaction includes:

1. an initialization of a context (TEEC_InitializeContext)
2. an opening of a session (TEEC_OpenSession)
3. 2 calls towards the TA loaded by the session (TEEC_InvokeCommand)
4. a closure of the session
5. a finalization of the context

I have runned the host application
a. emulated with QEMU (SMP = 4, CFG_NUM_THREADS = 4) and
b. on the Raspberry Pi (CFG_NUM_THREADS = 4)
Other from what I expect, the throughput (number of query transaction per second) does not double (or nearly double) with a doubling of threads. In case a. we only have an increase of the throughput by factor 1.2 from 1 to 2 threads, and in case b. the throughput even decreases from 1 to 2 threads.

As far as I have seen from the code, the tee-supplicant is multi-threaded and cannot be the bottleneck. Is there any part of OP-TEE which does provide a bottleneck for multi-threaded host application (each having its own context and session) calling the secure world?

Thanks in advance for any pointers.

Hi,

I think that every time I running tee-supplicant should added a & is not convenience, I think it would be better to change it to running as a daemon process automatically. As I know it is just fork a subprocess and exit its parent. But I 'm not sure is this you design on purpose.

Regards,
Ruizhi

When building the pkg with cmake the soname in the library is "libopteeclibopteec"

I suppose porper soname could be ie 1.

Index: optee_client-3.1.0/libteec/CMakeLists.txt
===================================================================
--- optee_client-3.1.0.orig/libteec/CMakeLists.txt
+++ optee_client-3.1.0/libteec/CMakeLists.txt
@@ -37,7 +37,7 @@ add_library (teec SHARED ${SRC})
 
 set_target_properties (teec PROPERTIES
 	VERSION ${PROJECT_VERSION}
-	SOVERSION ${PROJECT_NAME}
+	SOVERSION 1
 )
 
 ################################################################################

The code like this:

TEEC_SharedMemory inShm{};
TEEC_ReleaseSharedMemory(&inShm);

with 0-ed TEEC_SharedMemory structure falls through all ifs and causes this line:

A simple workaround does the job, but it relies on internals which is not a very good idea:

TEEC_SharedMemory inShm{};
inShm.id = -1;

I try to understand how operations can be cancelled by reading the code of the client.
But from what I read in the code:

• TEEC_RequestCancellation() sets cancel_id field to 0, and only sets the session identifier,
• TEEC_OpenSession() does not set cancel_id and the session identifier is an output, not an input,
• TEEC_InvokeCommand() does not set cancel_id and only sets the session identifier.

Thus I have the feeling that:

• TEEC_OpenSession() should not be cancellable as carrying nothing to identify it,
• TEEC_InvokeCommand() is cancellable by using the session identifier, but this is a little weak, as it does not fully identify the operation (if a thread invocates A then B, and a parallel thread tries to cancel A, then it might cancel B instead unless extraneous synchronisation is added),
• cancel_id field is never used.

Is there anything that I did not see?

teec_pre_process_operation will return an error code of teec_pre_process_tmpref derrectly when it failed (such as allocate a very large size of SHM). In this situation, the shm->id are still zero. It result in to wrong error handling. When TEEC_ReleaseSharedMemory is called in function teec_free_temp_refs, it may close a wrong fd 0 since the shm->id is not -1 (the initial value is zero).

As per https://github.com/OP-TEE/optee_client/blob/master/tee-supplicant/src/tee_supplicant.c#L506

Will this creates a potantial integer overflow?

static bool write_response(int fd, union tee_rpc_invoke *request)
{
	struct tee_ioctl_buf_data data;

	memset(&data, 0, sizeof(data));

	data.buf_ptr = (uintptr_t)&request->send;
	data.buf_len = sizeof(struct tee_iocl_supp_send_arg) +
		       sizeof(struct tee_ioctl_param) *
				request->send.num_params;
	if (ioctl(fd, TEE_IOC_SUPPL_SEND, &data)) {
		EMSG("TEE_IOC_SUPPL_SEND: %s", strerror(errno));
		return false;
	}
	return true;
}

On 32bit CPU, line 506 seems like __u64 = __u32 * __u32

Building v3.1.0 on openSUSE Tumbleweed with its GCC 8.1.1 leads to the following build error:

[   67s] /home/abuild/rpmbuild/BUILD/optee_client-3.1.0/libteec/src/teec_trace.c: In function '_dprintf':
[   67s] /home/abuild/rpmbuild/BUILD/optee_client-3.1.0/libteec/src/teec_trace.c:110:24: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size 246 [-Werror=format-truncation=]
[   67s]      "%s [%d] %s:%s:%d: %s",
[   67s]                         ^~
[   67s] /home/abuild/rpmbuild/BUILD/optee_client-3.1.0/libteec/src/teec_trace.c:112:11:
[   67s]      line, raw);
[   67s]            ~~~           
[   67s] In file included from /usr/include/stdio.h:862,
[   67s]                  from /home/abuild/rpmbuild/BUILD/optee_client-3.1.0/libteec/src/teec_trace.c:27:
[   67s] /usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' output 11 or more bytes (assuming 266) into a destination of size 256
[   67s]    return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
[   67s]           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[   67s]         __bos (__s), __fmt, __va_arg_pack ());
[   67s]         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[   67s] cc1: all warnings being treated as errors
[   67s] make[2]: *** [libteec/CMakeFiles/teec.dir/build.make:79: libteec/CMakeFiles/teec.dir/src/teec_trace.c.o] Error 1

In the function of process_one_request, Firstly, main function will call process_one_request to get request from TA by reading the request list in OP-TEE driver. If tee_supplicant get request data from driver, main function will call spawn_thread function to create a new thread, and the new thread also will call process_on_request to continue to get request. After that, main function will handle the request and loop again. It's like main function will create new thread every time when main receive the request from TA then handle request and loop again. Is there any wrong by this logic?

Aloha!

In the following file there is a fairly confusing comment:
https://github.com/OP-TEE/optee_client/blob/master/libteec/src/tee_client_api.c

The comment is:
/*

• Specification says that when no name is provided it should fall back
• on a predefined TEE, hence no check for NULL.
  */

And the line following the code is:
if (name == NULL)

Hi,
According to point 4.5.7 of TEE_Client_API_Specification. "connectionData MUST point to a uint32_t" for connectionMethod TEEC_LOGIN_GROUP or TEEC_LOGIN_GROUP_APPLICATION .
I see that You don't use connetionData at all, but maybe I could add parameter verification in TEE_OpenSession?

Hi. I'm having trouble using eMMC RPMB in an i.MX6 system. This is not actually an optee-client issue, but since optee-client can communicate with RPMB i'm taking a chance that someone here might recognize the issue and give me a hint where to look for the cause. I have the boot flow SPL -> optee-os -> U-boot -> Linux. The SW versions used are:

optee (all parts): 3.7.0 (with patches to read HUK at from CAAM at start-up)
SPL & U-boot: 2019.07
Linux: 4.14.149

Configurations:
optee-client: Disabled RPMB_EMU in tee-supplicant makefile
optee-os: CFG_RPMB_FS=y, CFG_RPMB_WRITE_KEY=y, CFG_RPMB_FS_DEV_ID=2 (since mmc2 is our eMMC device)

The issue is, we can successfully program a key and read the RPMB counter from U-boot, using the mmc command. Once Linux is started however, RPMB communication attempts fails, and it fails in a similar fashion regardless if it is mmc-utils or optee-client making the ioctl calls: It seems the responses from the ioctl calls are empty, i.e. no response data is provided on the given address (the data in the response frame remains whatever it was prior to the ioctl call).

If anyone have any idea what might cause this problem, a hint is very much appreciated.

Hi,

I'm interested in your pkcs11 implementation, namely libcktee in REE and pkcs11-ta as a backend in TEE.

In Aurora OS project (Russian fork of Sailfish OS) we plan to use pkcs11 as an interface between REE and TEE keystore and TEE cryptography.

I see that some of pkcs11-functions are just stubs, namely:

• C_GenerateKey/C_GenerateKeyPair
• C_FindObjects
• C_SignInit/C_Sign/C_SignUpdate/C_SignFinal
• C_SeedRandom/C_GenerateRandom

...that return 'CKR_FUNCTION_NOT_SUPPORTED'.

Could you please tell us about your pkcs11 implementation plan?
Or maybe we can help you to implement them?

Thank you!

@etienne-lms Currently the fd is used as s32 in both optee_client and optee-driver, why define it as type s64?

Is there already an effort to port OP-TEE client to u-boot and other bootloader environments?

my config.mk is

#########################################################################
# Public variables                                                      #
# Developers may override these values when calling the makefile,       #
# as for example                                                        #
#       CFG_TEE_CLIENT_LOG_LEVEL=1 make                                 #
# Note:                                                                 #
#   Please do not use export to declare the variables, so that to avoid #
#   compiling problem for android platform                              #
#########################################################################

# CFG_TEE_CLIENT_LOG_LEVEL
#   Client (User Non Secure) log level
#   Supported values: 0 (no traces) to 4 (all traces)
CFG_TEE_CLIENT_LOG_LEVEL ?= 4

# CFG_TEE_SUPP_LOG_LEVEL
#   Supplicant log level
#   Supported values: 0 (no traces) to 4 (all traces)
CFG_TEE_SUPP_LOG_LEVEL ?= 4

# CFG_TEE_FS_PARENT_PATH
#   Path to folder that will contain TEE filesystem.
#   This folder can be created with the required permission in an init
#   script during boot, else it will be created by the tee-supplicant on
#   first REE FS access.
CFG_TEE_FS_PARENT_PATH ?= /data/tee

# CFG_TEE_CLIENT_LOG_FILE
#   The location of the client log file when logging to file is enabled.
CFG_TEE_CLIENT_LOG_FILE ?= $(CFG_TEE_FS_PARENT_PATH)/teec.log

then , I add some log with DMSG in tee_client.api.c at TEEC_InitializeContext TEEC_OpenSession
TEEC_InvokeCommand , in tee_supplicant.c at process_one_request .

then , I run optee-os ,optee-client optee_example_helloworld on qemu-v8,
but I can not find teec.log in /data/tee folder.

so i am confused.

Hello!

I have a TA application that might take a NULL memory reference as an input:

TEEC_Operation operation = {0};
TEEC_PARAM_TYPES(TEEC_MEMREF_TEMP_INPUT,
                                      TEEC_NONE,
                                      TEEC_NONE,
                                      TEEC_NONE);
}

operation.params[0].tmpref.buffer = buffer;
operation.params[0].tmpref.size = buffer_length;

buffer and buffer_length are two parameters that are given as input and the buffer can be NULL. If the buffer is NULL, then the size is 0.

When I try to use Inkove_Command() the TEE seems to fail. The application stalls. If I try to restart the application I get:
3: ERR [3026] TEES:main:663: failed to find an OP-TEE supplicant device

After looking at 4.3.7. TEEC_TempMemoryReference in the TEE_Client_API_Specification-V1.0_c, I saw:

buffer is a pointer to the first byte of a region of memory which needs to be temporarily
registered for the duration of the Operation. This field can be NULL to specify a null Memory
Reference.

I was wondering if I miss-understood the documentation or if this is indeed an issue. I found that strange to see the application that stopped.
Let me know if you need any more information, debug logs,..

I ran into a Large File Support issue today, where the OP-TEE client could not detect the creation of the /data directory correctly, since the stat64() call was used.
The fix inside my BSP was to append -D_FILE_OFFSET_BITS to the optee_client CFLAGS.
The GLIBC Feature page describes all the macros, you might prefer another fix for the optee_client Makefile.
Please let me now and I will create a Pull request with your prefered fix.

[RFC] libsks for Pkcs#11 services through OP-TEE SKS TA #138

Build now fails when linking libckteec with: "cannot find -lteec"

Workaround:
diff --git a/zynqmp/optee-client/optee-client.bb b/zynqmp/optee-client/optee-client.bb
index ee8dbea..e1c7bbb 100644
--- a/zynqmp/optee-client/optee-client.bb
+++ b/zynqmp/optee-client/optee-client.bb
@@ -1,5 +1,6 @@
OPTEE_VERSION ??= "latest"
-SRCREV ??= "${AUTOREV}"
+# SRCREV ??= "${AUTOREV}"
+SRCREV = "82ec680ece99e7b345765fe680bd1c143b993da0"
BRANCH ??= "master"

DESCRIPTION = "OP-TEE Client"

Hi everyone,

For attestation purposes I am trying to keep a shared memory alive during the entire execution of a trusted application.

From the client part I am using TEEC_RegisterSharedMemory() method for registering it and from there it is never closed, i.e. I don't call the TEEC_ReleaseSharedMemory() method.

At first I am able to reach the shared binary.
The problem arises when I share other parts of memory for communication purposes. It seems like the new shared memories overwrite the old one, meaning that the address I originally saved has the same value but inside of it there is no more the original shared binary but the new one.

Is there a way to keep the shared memory available throughout the entire execution? Already tried to globally declare the Shared Memory object but it is still not working.

Edit:
I read on the issues that the shared address passed as parameter during an InvokeCommand() is valid only throughout the scope of that execution and will not be valid after that.

Probably I should change my question to: is there any way to make a shared memory accessible during different invocations? And if this is not achievable, could it be possible to get the normal world address value to see if the buffer shared is always the same?

Thank you very much.

I added the following node to enable optee device in u-boot per https://gitlab.denx.de/u-boot/u-boot/blob/master/doc/device-tree-bindings/firmware/linaro,optee-tz.txt but it is not binding because "firmware" does not immediately have a "compatible" property (https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/core/lists.c#L147).

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

Am I missing something?

I have got a kernel panic during reboot stress test. It seems to be a race condition issue in kernel driver. I don't know where to report this problem.. Could someone tell to how to report kernel driver issue?

So here is the panic stack:

PID: 467 TASK: ffffffc0a0c0b800 CPU: 5 COMMAND: "[email protected]"
#0 [ffffffc0a0d1f5d0] panic at ffffff80081ad6bc
#1 [ffffffc0a0d1f7e0] die at ffffff800808c778
#2 [ffffffc0a0d1f820] __do_kernel_fault at ffffff80080a0a28
#3 [ffffffc0a0d1f850] do_translation_fault at ffffff800809daf4
#4 [ffffffc0a0d1f880] do_mem_abort at ffffff80080814ec
#5 [ffffffc0a0d1fa80] el1_ia at ffffff8008085148
PC: ffffff8008913dcc [optee_supp_thrd_req+260]
LR: ffffff8008913da0 [optee_supp_thrd_req+216]
SP: ffffffc0a0d1fa80 PSTATE: 60400045
X29: ffffffc0a0d1fa80 X28: ffffffc0a0c0b800 X27: ffffff8008ba1000
X26: 00000000ffff0005 X25: 0000000000000007 X24: 0000000000000001
X23: ffffffc0a0d1fb38 X22: ffffffc0b2a6ec00 X21: ffffffc07034deb0
X20: ffffffc07034de80 X19: ffffffc0b2a6ec88 X18: 00000070d3c72fb0
X17: 00000070d419d810 X16: ffffff8008141700 X15: 000027452f61fd84
X14: 00112a87fa6df980 X13: 000000005bee05e7 X12: 0000000000000018
X11: 0000000000000000 X10: 0000000000000a10 X9: ffffffc0a0d1f8f0
X8: ffffffc0a0c0c270 X7: 0000000000000000 X6: 0000000000000000
X5: 0000000000000000 X4: dead000000000100 X3: dead000000000200
X2: dead000000000100 X1: dead000000000200 X0: ffffffc0b2a6ec88
#6 [ffffffc0a0d1fad0] optee_handle_rpc at ffffff8008913944
#7 [ffffffc0a0d1fb70] optee_do_call_with_arg at ffffff80089126ac
#8 [ffffffc0a0d1fc90] optee_invoke_func at ffffff8008912b44
#9 [ffffffc0a0d1fd00] tee_ioctl_invoke at ffffff800890e06c
#10 [ffffffc0a0d1fd80] tee_ioctl at ffffff800890ed94
#11 [ffffffc0a0d1fdf0] do_vfs_ioctl at ffffff800822f670
#12 [ffffffc0a0d1fe80] sys_ioctl at ffffff800822f978
#13 [ffffffc0a0d1fec0] el0_svc_naked at ffffff8008085c6c
PC: 0000007d71f92f84 LR: 0000007d71f4d18c SP: 0000007fd0e2b800
X29: 0000007fd0e2b8f0 X28: 0000007d7154e7d0 X27: 0000007d7154e7f0
X26: 0000007d714f5508 X25: 0000007d7154b000 X24: 0000007d72570a40
X23: 0000007fd0e2b9e8 X22: 0000007d7154e7d8 X21: 0000000000000000
X20: 0000007fd0e2bb38 X19: 0000007d72570a40 X18: 0000000000000011
X17: 0000007d71f4d100 X16: 0000007d71a96f50 X15: ffffffffffffffff
X14: ffffffffff000000 X13: 0000000000000000 X12: 0000007fd0e2b8b8
X11: 0000007fd0e2b880 X10: 00000000ffffff80 X9: 0000007fd0e2b8b8
X8: 000000000000001d X7: 0000000000000000 X6: 0000000000000000
X5: 0000007d71a93000 X4: 0000007d715cb7f0 X3: 0000007d71a92f80
X2: 0000007fd0e2b900 X1: 000000008010a403 X0: 0000000000000008
ORIG_X0: 0000000000000008 SYSCALLNO: 1d PSTATE: a0000000

I think this flow may lead this result: one task (A) is waiting inside optee_supp_thrd_req(), another task (B) is doing optee_supp_release(). B called list_del(&req->link) then wakeup A by complete(&req->c); After B wakes up, B found &req->link has been poisoned, so a panic() happened.

A:

 47 void optee_supp_release(struct optee_supp *supp)
 48 {
 49         int id;
 50         struct optee_supp_req *req;
 51         struct optee_supp_req *req_tmp;
 52 
 53         mutex_lock(&supp->mutex);
 54 
 55         /* Abort all request retrieved by supplicant */
 56         idr_for_each_entry(&supp->idr, req, id) {
 57                 req->busy = false;
 58                 idr_remove(&supp->idr, id);
 59                 req->ret = TEEC_ERROR_COMMUNICATION;
 60                 complete(&req->c); 
 61         }
 62 
 63         /* Abort all queued requests */
 64         list_for_each_entry_safe(req, req_tmp, &supp->reqs, link) {
 65                 list_del(&req->link);  <--------------------------------------------- poison here
 66                 req->ret = TEEC_ERROR_COMMUNICATION;
 67                 complete(&req->c);

B:

 85 u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params,
 86                         struct tee_param *param)
....
116         while (wait_for_completion_interruptible(&req->c)) {
117                 mutex_lock(&supp->mutex);
118                 interruptable = !supp->ctx;
119                 if (interruptable) {
120                         /*
121                          * There's no supplicant available and since the
122                          * supp->mutex currently is held none can
123                          * become available until the mutex released
124                          * again.
125                          *
126                          * Interrupting an RPC to supplicant is only
127                          * allowed as a way of slightly improving the user
128                          * experience in case the supplicant hasn't been
129                          * started yet. During normal operation the supplicant
130                          * will serve all requests in a timely manner and
131                          * interrupting then wouldn't make sense.
132                          */
133                         interruptable = !req->busy;
134                         if (!req->busy)
135                                 list_del(&req->link); <--------------------------- try to reference poisoned memory
136                 }
137                 mutex_unlock(&supp->mutex);
138 

I'm not sure whether it's a problem, could anyone check for this? thanks!

Hello @jenswi-linaro ,

I am writing a trusted application which needs to be linked with my custom cryptographic library dynamically. I have seen a optee-test examples folder in which they have tried link an application dynamically , which is again like an other trusted app but instead of BINARY they have built it as a SHAREDLIB and then they have linked it with the main application dynamically via
LDADD += -L ltest

1. I need to know whether this sharedlib which is a trusted app should be stored in lib/optee_tz folder or in other location.?

2. Secondly, Is there a way wherein I am allowed to stored this sharedlibs in a persistent object ?
   Can I load the Sharedlibs from the perssitent object at runtime and make use of the shared library ?
   Could you please share your thoughts on this ?
   Thanks again.

I've noticed a weird thing that I cannot explain by reading our makefiles (in this git and in build.git). If you start out from a clean build environment and build once, then you'll end up with

$ find out-br/build/optee_client-1.0/ -maxdepth 1 -type d
out-br/build/optee_client-1.0/
out-br/build/optee_client-1.0/tee-supplicant
out-br/build/optee_client-1.0/libteec
out-br/build/optee_client-1.0/scripts
out-br/build/optee_client-1.0/public
out-br/build/optee_client-1.0/CMakeFiles
out-br/build/optee_client-1.0/libckteec

Nothing strange (notice no out-folder), but if you for example then do

$ mkdir -p optee_client/out && echo "foobar" > optee_client/out/joakim.h

Then rebuild, then you see that "joakim.h" is in out-br.

$ find out-br/build/optee_client-1.0/ -maxdepth 1 -type d
out-br/build/optee_client-1.0/
out-br/build/optee_client-1.0/tee-supplicant
out-br/build/optee_client-1.0/libteec
out-br/build/optee_client-1.0/scripts
out-br/build/optee_client-1.0/public
out-br/build/optee_client-1.0/out
out-br/build/optee_client-1.0/CMakeFiles
out-br/build/optee_client-1.0/libckteec

$ find out-br/build/optee_client-1.0/ -name "joakim.h"
out-br/build/optee_client-1.0/out/joakim.h

Where the heck does our makefiles find and do the copy from optee_client/out/ to out-br/build/optee_client-1.0/out? This doesn't seem to be called and I believe it shouldn't since it's not (I hope?) used by Buildroot. This maybe? I've done some printing with those variables, but doesn't look like that either.

Why do I care? Well, the system have tricked me on this when trying to use files built by buildroot. I have other ways to avoid this, but I find it rather annoying that I cannot figure out why it behaves like this. So, I'm throwing out the question to someone else who might have an answer to it :)

Root Makefile can be cleaned:

• CFG_TEE_TEEC_GENERIC_PATH not used
• target "copy" is unused
• missing a "clean_rootfs" target, symmetric to "copy_rootfs"

Hi, I am working on RaspberryPi-3B+ board. I tested the optee-examples and it works completely fine. But I see the logs are intermingled. The print messages from the client app side is not printed correctly . Could someone explain how to solve this ?

Hello,

As part of my projects, I would like to be able to consume TEE Client APIs from another kernel module. As per Global Platform TEE Client API Specification, there is no assumption taken on whether the TEE Client APIs are exposed to the privileged and/or user layers of the rich environment. Have you considered exposing the TEE Client APIs from the TEE kernel module directly?

And second to that, if you were heavily opposed to exposing TEE Client APIs directly inside the kernel, do you have a recommendation as to how to execute a TA from another kernel module?

Regards,
Jiri

Hello All,

I have a question regarding the shared memory allocation with respect to OP-TEE Client Application.
As far as I understand from the documentation of OPTEE-Client API , we can allocate the memory via the OP-TEE Client API TEEC_AllocateSharedMemory or if memory is already allocated from the caller it needs to be registered via TEEC_RegisterSharedMemory.

I am writing a client application for the rpi3b+ module and I tried to allocate the shared memory via TEEC_AllocateSharedMemory api on the client side. I am curious to know from which region of physical memory is the Memory allocated.

I have attached the log captured here.

Allocated Input Shared Memory Address is 0x7f853ed000 (I added prints to see the memory address).

I also tried to allocate the memory via malloc in the client application and was able to print the memory address from the RAM.
pointer 0x14ef4260.

Can someone explain whats happening when I call the TEEC_AllocateSharedMemory api and from where is the memory allocated.
Thanks in advance.

When using cmake buildsystem the CMakeLists.txt gets installed in /usr/include:
/usr/include/CMakeLists.txt

This file should not be installed on resulting system.

Unhandled fault: unsupported exclusive occurs when using gcc builtin atomic __sync_fetch_and_add(&cpu_buf->head, 1);, which is unfolded into LDXR/STLXR pair (aarch64).

Currently, __sync_fetch_and_add is used in bm_timestamp() for updating head/tail of timestamp per-cpu ringbuffers (https://github.com/OP-TEE/optee_client/blob/master/libteec/src/teec_benchmark.c#L203)

bt:

#0  0x0000007fb7fc23f8 in bm_timestamp () from target:/lib/libteec.so.1.0
#1  0x0000007fb7fc167c in TEEC_InvokeCommand () from target:/lib/libteec.so.1.0
#2  0x0000000000403180 in xtest_tee_test_1001 (c=0x4b6090) at /home/xdev/work/linaro/reps/rpi3/optee_test/host/xtest/regression_1000.c:286
#3  0x000000000040c090 in ADBG_RunSuite (Runner_p=0x4b6040, argc=0, argv=0x7ffffffda0) at /home/xdev/work/linaro/reps/rpi3/optee_test/host/xtest/adbg/src/adbg_run.c:162
#4  0x000000000040bd40 in Do_ADBG_RunSuite (Suite_p=0x7ffffffc20, argc=0, argv=0x7ffffffda0) at /home/xdev/work/linaro/reps/rpi3/optee_test/host/xtest/adbg/src/adbg_run.c:74
#5  0x000000000042ae30 in main (argc=1, argv=0x7ffffffd98) at /home/xdev/work/linaro/reps/rpi3/optee_test/host/xtest/xtest_main.c:164

Basically, after executing ldr x0, [x29,#320] CA falls down with Bus error message.

0x7fb7fc23f4 <bm_timestamp+516> ldr    x0, [x29,#320]                                                                                                                
0x7fb7fc23f8 <bm_timestamp+520> ldxr   x1, [x0]                                                                                                                                             
0x7fb7fc23fc <bm_timestamp+524> add    x2, x1, #0x1                                                                                                                          0x7fb7fc2400 <bm_timestamp+528> stlxr  w3, x2, [x0]

Kernel reports:

[  532.544993] Unhandled fault: implementation fault (unsupported exclusive) (0x92000035) at 0x0000007fa67c1938

Based on details from threads:
https://community.arm.com/processors/f/discussions/5832/what-is-real-application-of-exclusive-access-in-axi/19404#19404
https://www.riscosopen.org/forum/forums/9/posts?page=6&posts_per_page=50&posts_per_page_change=Change

Today’s cache maintenance learning: Cortex-A53 generates an “unsupported exclusive access” data abort when LDREX/STREX targets a page which is temporarily unacheable (i.e. Normal, non-cacheable – documented in the TRM). It also aborts if a LDREX/STREX targets a cacheable page while the data cache is disabled (not documented in the TRM?).

@jenswi-linaro @etienne-lms
Have you ever faced similar issues when using AArch64 exclusive instructions?

Hi,
I have a question regardings OP-TEE's implementation of the login methods specified by GlobalPlattform. When a CA calls TEEC_OpenSession, it can choose a login method by setting a value for parameter connectionMethod. The TA can retrieve the login method by accessing the property gpd.client.identity which is of type TEE_Identity. TEE_Identity contains an UUID for identifying the CA. The TEE Internal Core API Specification states that this UUID is set by the Rich Excecution Environment and therefore it is implementation-specific.

So my question is: How does OP-TEE handles the UUID? I haven't found any documentation. For example: When a CA calls TEEC_OpenSession with connectionMethod=TEEC_LOGIN_APPLICATION, which UUID the TA can expect?

Hi All,

Currenttly, the treble architecture of Android P, have a lot of restrictions . for example, libary linker, socket between system and vendor .
Once a system service want to use the op-tee client api, it will face the problem.Maybe we can use hidl service to deal with this . But it still will be some problem about sharememory and struction inforation which need to be passed between process.
I notice op-tee is doing some work about the AOSP . Will you have a plan to design a standard hidl interface for the gp client api？

Thanks

Hi,

I am testing some code sequence in QEMU, which involves message queues.
I am getting msg queue id = 0, and any msgsnd() is failing on that with error code = 22 (EINVAL)
However, msgrcv() is waiting. Can you please help in suggesting some solution. Thanks

Thanks for providing this code. There are a few issues though.
The files are quite promiscuous in terms of what is included.

https://github.com/OP-TEE/optee_client/blob/master/libteec/src/tee_client_api.c
includes malloc even though no allocation is done in the code. There are also header files that includes malloc.

Hi all,
Android5.1 compile error.
Does other Android version work well ?

LOG:
Install: out/target/product/Hi3798MV200/system/lib/libteec.so
Import includes file: out/target/product/Hi3798MV200/obj/EXECUTABLES/tee-supplicant_intermediates/import_includes
target thumb C: tee-supplicant <= device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/handle.c
target thumb C: tee-supplicant <= device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_supp_fs.c
target thumb C: tee-supplicant <= device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_supplicant.c
target thumb C: tee-supplicant <= device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/teec_ta_load.c
target thumb C: tee-supplicant <= device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/rpmb.c
target thumb C: tee-supplicant <= device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_socket.c
device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_socket.c: In function 'sa_set_port':
device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_socket.c:551:12: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (slen < sizeof(*sain))
^
device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_socket.c:561:12: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (slen < sizeof(*sain6))
^
device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_socket.c: In function 'sa_get_port':
device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_socket.c:577:12: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (slen < sizeof(*sain))
^
device/hisilicon/bigfish/HiSTBSDKV6R2/source/tee/core/optee/optee_client/tee-supplicant/src/tee_socket.c:587:12: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (slen < sizeof(*sain6))
^
cc1: all warnings being treated as errors
make: *** [out/target/product/Hi3798MV200/obj/EXECUTABLES/tee-supplicant_intermediates/src/tee_socket.o] Error 1

In tee_client_api.h there is an incorrect constant for max shared memory size:
#define TEEC_CONFIG_SHAREDMEM_MAX_SIZE 0x8000

According to GP API specification (and the comment above the constant), the limit should be equal to 512 kB (0x80000), now it is 32kB, which in result does not allow you to allocate higher memory sizes for bigger data.

The Makefile builds a versioned shared library, but the CMake build just installs a static library.

Notably, the keyword SHARED is missing from the add_library calls.

As the subject says, if the distro uses /lib64 libtee*.so will get installed in the wrong place and won't be found be e.g. optee-test.