An OP-TEE driver development method

By setting up Device modules and clearly defined module division and interface specifications in OP-TEE, the complexity and development difficulty of OP-TEE native solution are solved, and a more efficient driving development process is achieved.

CN119759325APending Publication Date: 2025-04-04HANGZHOU NATCHIP SCI & TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411939907.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-12-26
Publication Date
2025-04-04

AI Technical Summary

Technical Problem

The existing OP-TEE native solutions are complex and inconvenient to development, which leads to developers need to have an in-depth understanding of the system architecture and underlying principles, increasing learning costs and development difficulties.

Method used

The driver development process is simplified by setting up Device modules in OP-TEE, managing driver entities, and defining clear module division and interface specifications.

Benefits of technology

It reduces the learning cost and difficulty of getting started for developers, improves development efficiency, and reduces labor and time cost investment.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119759325A_ABST
    Figure CN119759325A_ABST
Patent Text Reader

Abstract

The present invention discloses an OP‑TEE driver development method. The method of the present invention comprises: firstly, setting a Device module in the existing OP‑TEE for managing a driver entity; then setting a driver entity for driving a hardware device; then setting a PTA module for communication between the Device module and the API module; and setting an API module for communication between a user TA and the PTA module. The present invention provides a clear and definite module division, each module having specific functions and responsibilities. At the same time, the method also defines a concise and clear interface specification. Developers no longer need to worry about the inconsistency and non-standardization of interfaces, and do not need to spend too much energy on cumbersome underlying architecture and file modifications, thereby reducing the learning cost and difficulty of getting started.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the field of embedded security technology, and in particular relates to a convenient OP-TEE driver development method. Background Art

[0002] In the current OP-TEE (Open Portable Trusted Execution Environment) driver development field, native solutions have many problems, which brings great inconvenience to developers. Usually, when users develop drivers according to the OP-TEE native solution, they need to have a deep understanding of the complex system architecture and underlying principles, and there are many places that need to be modified and paid attention to. This not only requires developers to have deep technical skills and rich experience, but also requires a lot of time and energy to study and understand those obscure code logic.

[0003] In addition, due to the complexity and inconvenience of OP-TEE's native solution, it is difficult for new developers to get started quickly, and the learning cost is extremely high. For enterprises and development teams, using native solutions to develop drivers means high manpower and time costs. Long development cycles may cause project delays, missed market opportunities, and increase the operational risks and economic pressures of enterprises. Summary of the invention

[0004] The purpose of the present invention is to provide a convenient OP-TEE driver development method to address the many shortcomings of the OP-TEE native solution in the above-mentioned prior art.

[0005] The method of the present invention is specifically as follows: Step (1) First, set up the Device module in the existing OP-TEE to manage the driver entity. The specific method is:

[0006] (1-1) Declare the device structure, which includes: driver name, driver behavior and driver interrupt number.

[0007] (1-2) Declare the interrupt behavior of the device; (1-3) Declare the device's driver behavior, which includes: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; (1-4) Set up the device registration interface; (1-5) According to the declared driver behavior, set the driver behavior of the Device module, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data and device control; (1-6) Register the Device module into OP-TEE; (1-7) Provide the Device module calling interface and declaration to the driver entity and PTA (Pseudo Trust Application) module. The calling interface includes the device registration interface and the driver behavior interface.

[0008] Step (2) sets the driver entity, which is used to drive the hardware device. The specific method is:

[0009] (2-1) According to the device structure declared by the Device module, set the driver name and driver interrupt number of this device entity; (2-2) According to the interrupt behavior declared by the Device module, set the interrupt service routine of this device; (2-3) According to the driver behavior declared by the Device module, set the driver behavior of this device, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; (2-4) Setting the driver entity of the device according to the driver name, driver interrupt number, interrupt service routine and driver behavior of the device; (2-5) Call the device registration interface of Device to register the device entity; (2-6) Provide the driver behavior interface of this device to the user TA (Trust Application, security program).

[0010] Step (3) Set up the PTA module for communication between the Device module and the API module. The specific method is:

[0011] (3-1) Declare the universally unique identifier (UUID) of the PTA module; (3-2) Setting the session behavior interface of the PTA module, including: session opening interface, session closing interface and session control interface; (3-3) The session control interface calls the driver behavior interface of the Device module to set the behavior of the session control interface, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; (3-4) Register the PTA module into OP-TEE; (3-5) Provide the session behavior interface of this PTA module to the API module.

[0012] Step (4) Setting up the API (Application Programming Interface) module for communication between the user TA and the PTA module. The specific method is:

[0013] (4-1) Call the session opening interface of the PTA module and set the behavior of the service opening interface of the API module to open the PTA module; (4-2) Call the session control interface of the PTA module to set the behavior of the service control interface of the API module, including: device opening, device closing, device reading data, device writing data, and device control; (4-3) Call the session closing interface of the PTA module and set the behavior of the service closing interface of the API module to close the PTA module; (4-4) Register the API module into OP-TEE; (4-5) Provide the service behavior interface of this API module to the user TA, including the opening interface, control interface and closing interface.

[0014] The present invention constructs a highly integrated and easily extensible driver development method, which provides a clear and definite module division, each module has specific functions and responsibilities, and defines a concise and clear interface specification. Developers no longer need to worry about the inconsistency and non-standardization of interfaces, and do not need to spend too much energy on cumbersome underlying architecture and file modifications, thereby reducing the learning cost and difficulty of getting started. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 Schematic diagram of an embodiment of the method of the present invention. DETAILED DESCRIPTION

[0016] An OP-TEE driver development method, such as Figure 1 As shown, the details are as follows: Step (1) First, set up the Xdev Device module in the existing OP-TEE. The Xdev Device module is used to manage the driver entity. The specific method is:

[0017] (1-1) Declare the device structure, which includes: driver name, driver behavior and driver interrupt number. The implementation code is as follows:

[0018] typedef struct { const char*name; / / Driver name xdev_device_ops *ops; / / Driver behavior struct itr_handler *itrs[TEE_XDEV_MAX_ITRS]; / / Driver interrupt number } XDev_Device; (1-2) Declare the interrupt behavior of the device; the implementation code is as follows: enum itr_return __maybe_unused irq_ihandler(struct itr_handler *handler); (1-3) Declare the device's driver behavior, which includes: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; the implementation code is as follows: typedef struct { TEE_Result (*init)(void *priv); / / Device initialization void(*uninit)(void); / / device deregistration TEE_Result (*open )(XDevDeviceHandle h); / / Device open void(*close)(XDevDeviceHandle h); / / Device close size_t(*read )(XDevDeviceHandle h, void * const buffer, const size_tsize); / / Device read data size_t(*write)(XDevDeviceHandle h, const void * buffer, const size_tsize); / / Device write data TEE_Result (*ioctl)(XDevDeviceHandle h, uint32_t cmd, void *buffer,size_t size); / / Device control } xdev_device_ops; (1-4) Set the device registration interface; the implementation code is as follows: #define xdev_device_register(...); (1-5) According to the declared driver behavior, set the driver behavior of the Xdev Device module, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data and device control; the implementation code is as follows: void xdev_device_init(void); void xdev_device_deinit(void); TEE_XDevHandle xdev_device_open (const char *path); TEE_Result xdev_device_close(XDevDeviceHandleh); size_t xdev_device_read (XDevDeviceHandleh, void * const buffer, const size_t size); size_t xdev_device_write(XDevDeviceHandle, const void * buffer,const size_t size); TEE_Result xdev_device_ioctl(XDevDeviceHandle h, uint32_t cmd, void *buffer, size_t size); (1-6) Register the Xdev Device module into OP-TEE; the implementation code is as follows: driver_init_late(xdev_device_init); (1-7) Provide the Xdev Device module calling interface and declaration to the Misc Device driver entity and the Xdev PTA (Pseudo Trust Application) module. The calling interface includes the device registration interface and the driver behavior interface.

[0019] Step (2) Set up the Misc Device driver entity, which is used to drive the hardware device. The specific method is:

[0020] (2-1) According to the device structure declared by the Xdev Device module, set the driver name and driver interrupt number of this device entity; the implementation code is as follows: #define MISC_NAME " / dev / misc" #define IRQ_MISC 30 (2-2) According to the interrupt behavior declared by the Xdev Device module, set the interrupt service routine of this device; the implementation code is as follows: enum itr_return __maybe_unused misc_ihandler(struct itr_handler *handler); static struct itr_handler misc_itr = { .it = IRQ_MISC, .handler = misc_ihandler,}; (2-3) According to the driver behavior declared by the Xdev Device module, set the driver behavior of this device, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; the implementation code is as follows: TEE_Result misc_init(void *priv); void misc_deinit(void); TEE_Result misc_open(XDevDeviceHandle h); void misc_close(XDevDeviceHandle h); size_t misc_read (XDevDeviceHandle h, void * const buffer, constsize_t size); size_t misc_write(XDevDeviceHandle h, const void * buffer, constsize_t size); TEE_Result misc_ioctl(XDevDeviceHandle h, uint32_t cmd, void *buffer,size_t size); (2-4) According to the driver name, driver interrupt number, interrupt service routine and driver behavior of this device, set the driver entity of this device; the implementation code is as follows: xdev_device_ops s_misc_ops = { .init = misc_init, .uninit = misc_deinit, .open = misc_open, .close = misc_close, .read = misc_read, .write = misc_write, .ioctl = misc_ioctl,}; (2-5) Call the device registration interface of Xdev Device to register the device entity; the implementation code is as follows: xdev_device_register( .name = MISC_NAME, .ops = &s_misc_ops, .itrs = {&misc_itr, NULL}, ); (2-6) Provide the driver behavior interface of this device to the user TA (Trust Application).

[0021] Step (3) Set up the Xdev PTA module for communication between the Xdev Device module and the Xdev API module. The specific method is:

[0022] (3-1) Declare the universally unique identifier (UUID) of the Xdev PTA module; the implementation code is as follows: #define XDEV_PTA_UUID { 0x9fb51c74, 0xc67c, 0x4ebf, \ { 0x8c, 0x74, 0x4c, 0xc7, 0x74, 0x65, 0xd0, 0xc3}} (3-2) Set the session behavior interface of the Xdev PTA module, including: session opening interface, session closing interface and session control interface; the implementation code is as follows: TEE_Result xdev_pta_open_session(uint32_t param_types __unused, TEE_Param pParams[TEE_NUM_PARAMS] __unused, void **sess_ctx); void xdev_pta_close_session(void *sess_ctx); TEE_Result xdev_pta_invoke_command(void *sess_ctx, uint32_t cmd_id, uint32_t param_types, TEE_Param params[TEE_NUM_PARAMS]); (3-3) The session control interface calls the driver behavior interface of the Xdev Device module to set the behavior of the session control interface, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; the implementation code is as follows: static const ta_func ta_funcs[] = { [PTA_XDEV_OPEN] = xdev_device_open, [PTA_XDEV_CLOSE] = xdev_device_close, [PTA_XDEV_WRITE] = xdev_device_write, [PTA_XDEV_READ] = xdev_device_read, [PTA_XDEV_IOCTL] = xdev_device_ioctl,}; if (cmd_id < ARRAY_SIZE(ta_funcs) && ta_funcs[cmd_id]) return ta_funcs[cmd_id]((vaddr_t)sess_ctx, param_types, params); (3-4) Register the xdev PTA module into OP-TEE; the implementation code is as follows: pseudo_ta_register(.uuid = XDEV_PTA_UUID, .name = "xdev", .flags = PTA_DEFAULT_FLAGS | TA_FLAG_CONCURRENT, .open_session_entry_point = xdev_pta_open_session, .close_session_entry_point = xdev_pta_close_session, .invoke_command_entry_point = xdev_pta_invoke_command); (3-5) Provides the session behavior interface of this Xdev PTA module to the Xdev API module.

[0023] Step (4) Setting up the Xdev API module for communication between the user TA and the Xdev PTA module. The specific method is:

[0024] (4-1) Call the session opening interface of the Xdev PTA module and set the service opening interface of the Xdev API module to open the Xdev PTA module; the implementation code is as follows: void init_xdev_api(void); (4-2) Call the session control interface of the Xdev PTA module and set the behavior of the service control interface of the Xdev API module, including: device opening, device closing, device reading data, device writing data, and device control; the implementation code is as follows: int open(const char *name, ...); int close(int fd); int ioctl(int fd, int cmd, void *arg, uint32_t len); (4-3) Call the session closing interface of the Xdev PTA module and set the behavior of the service closing interface of the Xdev API module to close the Xdev PTA module; the implementation code is as follows: void deinit_xdev_api(void); (4-4) Register the Xdev API module into OP-TEE; the implementation code is as follows: xdev_api_register(); (4-5) Provide the user TA with the service behavior interface of this Xdev API module, including the opening interface, control interface and closing interface.

Claims

1. An OP-TEE driver development method, characterized in that: The details are as follows: Step (1) First, set up the Device module in the existing OP-TEE to manage the driver entity; the specific method is: (1-1) Declare the device structure, which includes: driver name, driver behavior and driver interrupt number; (1-2) Declare the interrupt behavior of the device; (1-3) Declare the device's driver behavior, which includes: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; (1-4) Set up the device registration interface; (1-5) According to the declared driver behavior, set the driver behavior of the Device module, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data and device control; (1-6) Register the Device module into OP-TEE; (1-7) Provide the Device module calling interface and declaration to the driver entity and PTA module. The calling interface includes the device registration interface and the driver behavior interface; Step (2) sets a driver entity for driving the hardware device; the specific method is: (2-1) According to the device structure declared by the Device module, set the driver name and driver interrupt number of this device entity; (2-2) According to the interrupt behavior declared by the Device module, set the interrupt service routine of this device; (2-3) According to the driver behavior declared by the Device module, set the driver behavior of this device, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; (2-4) Setting the driver entity of the device according to the driver name, driver interrupt number, interrupt service routine and driver behavior of the device; (2-5) Call the device registration interface of Device to register the device entity; (2-6) Providing the device's driving behavior interface to the user TA; Step (3) sets the PTA module for communication between the Device module and the API module; the specific method is: (3-1) declare the universal unique identifier UUID of the PTA module; (3-2) Setting the session behavior interface of the PTA module, including: session opening interface, session closing interface and session control interface; (3-3) The session control interface calls the driver behavior interface of the Device module to set the behavior of the session control interface, including: device initialization, device deregistration, device opening, device closing, device reading data, device writing data, and device control; (3-4) Register the PTA module into OP-TEE; (3-5) Provide the conversation behavior interface of this PTA module to the API module; Step (4) setting up an API module for communication between the user TA and the PTA module; the specific method is: (4-1) Call the session opening interface of the PTA module and set the behavior of the service opening interface of the API module to open the PTA module; (4-2) Call the session control interface of the PTA module to set the behavior of the service control interface of the API module, including: device opening, device closing, device reading data, device writing data, and device control; (4-3) Call the session closing interface of the PTA module and set the behavior of the service closing interface of the API module to close the PTA module; (4-4) Register the API module into OP-TEE; (4-5) Provide the service behavior interface of this API module to the user TA, including the opening interface, control interface and closing interface.