tkaratapanis opened a new pull request, #16734: URL: https://github.com/apache/nuttx/pull/16734
## Summary Currently the OP-TEE driver has bare minimum support of RPCs (Invokations of nuttx from OP-TEE), just enough to establish sessions. This PR aims to handle a group of RPCs `OPTEE_SMC_RPC_FUNC_CMD`, presently ignored. The newly supported RPCs can be handled either directly by the kernel and the code in `./drivers/misc/optee_rpc.c` or they might be delegated to userspace through `./drivers/misc/optee_supplicant.c`. The userspace support requires 2 extra commands to be handled by the ioctl handler, `TEE_IOC_SUPPL_RECV` and `TEE_IOC_SUPPL_SEND`. These commands must be invoked only by the TEE supplicant and not a regular nuttx Client Application (CA). A system can have multiple CAs (opens `/dev/tee0`) but only one TEE supplicant (opens `/dev/teepriv0`). The newly supported RPCs provide: 1) Shared memory allocation, either by the kernel or the userspace (TEE supplicant). 2) Freeing of shared memory. 3) Wall clock time to OP-TEE. 4) Suspension of a CA for a time specified by OP-TEE. 5) Supplicant RPCs. These result to higher-level services (e.g. secure storage) executed in user land through the TEE supplicant. To support the supplicant, a new device (`/dev/teepriv0`) is registered by the OP-TEE driver if `CONFIG_DEV_OPTEE_SUPPLICANT` is enabled. This device can be opened only by one user or it returns `-EBUSY`, it maintains a separate shared memory list and its entries can be queried by other CAs. The introduction of the supplicant logic, also requires to maintain in the `struct optee_shm` both the virtual address `.vaddr` and physical `.paddr`. The translation happens by the process who allocates that memory, since a CA and the supplicant have different memory mappings (different processes). ## Impact If `CONFIG_DEV_OPTEE_SUPPLICANT` is disabled (default) the code should work as it works now with the addition of kernel handled RPCs by `./driver/misc/optee_rpc.c` (1-4 as listed in the summary section). If `CONFIG_DEV_OPTEE_SUPPLICANT` is enabled and nuttx can run a TEE supplicant then services like secure storage can be provided to OP-TEE. ## Testing The tests happened in a custom imx9 board that runs TF-A (bl31) and OP-TEE (bl32) together with nuttx (bl33). Since there is minimal support for OP-TEE interacting applications, the existing functionality was tested by running the `optee_gp` [example](https://github.com/apache/nuttx-apps/tree/master/examples/optee_gp): ``` nsh> optee_gp INF [11] TEEC:main:164: Available devices: INF [11] TEEC:main:174: d96a5b40-c3e5-21e3-8794-1002a5d5c61b INF [11] TEEC:main:174: 145f361e-40f3-11ee-be56-0242ac120002 INF [11] TEEC:main:174: f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c ``` To test the supplicant functionality the code from https://github.com/OP-TEE/optee_client/tree/master/tee-supplicant was integrated with nuttx in a private fork. Also a testing CA (nuttx) and TA (OP-TEE) were developed that worked in unison to test secure storage. The test scenario is as follows: 1) CA -> sends a request to the TA with uuid `145f361e-40f3-11ee-be56-0242ac120002` to create a file and write a known payload to it ("Secure OP-TEE data"). 2) The TA sends a bunch of RPC requests that are delegated to the TEE supplicant. 3) The result of the operation is printed in the shell. 4) CA -> sends a request to the same TA to open the file and print its contents. 5) The TA sends a bunch of RPC requests that are delegated to the TEE supplicant. 6) The result of the operation is printed in the shell ``` nsh> optee_supplicant -f /data/tee > /dev/null & # Run the supplicant in the background with /data/tee as the root fs for OP-TEE optee_supplicant [0:100] nsh> optee_client 145f361e-40f3-11ee-be56-0242ac120002 2 # Request from the TA to create a secure file. I/TA: File created! closing handle! nsh> optee_client 145f361e-40f3-11ee-be56-0242ac120002 3 # Request from the TA to open that file and print its contents. I/TA: file found!! I/TA: Object content (19 bytes): "Secure OP-TEE data" ``` The files created by OP-TEE are encrypted (with a key only known to OP-TEE) under the directory we provided the TEE supplicant: `/data/tee`. We can however list the created files (besides` dirf.db` other OP-TEE filenames are not really known to nuttx): ``` nsh> ls -l /data/tee /data/tee: -rwxrwxrwx 16384 0 -rwxrwxrwx 16384 dirf.db ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
