A data processing method, a system on chip, an electronic device and a vehicle-mounted intelligent system

Abstract

The application provides a data processing method, a system on chip, an electronic device and a vehicle-mounted intelligent system. The method comprises the following steps: a second hardware domain sends a first data processing request to a first domain; a first driver in the first domain is called, wherein the first driver corresponds to the first data processing request, and the first driver can respectively perform data interaction and cooperative operation with a first trusted application library and a second trusted application library in a driving execution process, so that the first hardware domain and the second hardware domain both have security protection capability; the first driver drives the first domain to execute a trusted application program corresponding to the first data processing request; the trusted application program is located in the first domain; and an execution result of the trusted application program is returned to the second hardware domain.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data processing method, a system-on-a-chip, an electronic device, and an in-vehicle intelligent system. Background Technology

[0002] When different hardware domains run different operating systems, and when some hardware domains have a separate Trusted Execution Environment (TEE), while other hardware domains do not have a TEE but have security tasks to perform, the existing systems and data processing methods cannot meet the above data processing requirements. Summary of the Invention

[0003] The purpose of this application is to provide a data processing method, a system-on-a-chip, an electronic device, and an in-vehicle intelligent system.

[0004] The embodiments of this application adopt the following technical solution: a data processing method, characterized in that it is applied to a system-on-a-chip, the system-on-a-chip including a first hardware domain and a second hardware domain, the first hardware domain including a first domain and a second domain, and the first hardware domain and the second hardware domain are hardware isolated, the first domain and the second domain are isolated at the hardware level; the first domain is provided with a first trusted application library for providing secure storage services and a second trusted application library for providing services to the second hardware domain, so as to provide a trusted execution environment; the second domain and the second hardware domain cannot provide a trusted execution environment;

[0005] The method includes:

[0006] The second hardware domain sends a first data processing request to the first domain;

[0007] The first driver in the first domain is invoked, wherein the first driver corresponds to the first data processing request, and the first driver can perform data interaction and collaborative operation with the first trusted application library and the second trusted application library respectively during driver execution, so that both the first hardware domain and the second hardware domain have security protection capabilities.

[0008] The first driver drives the first domain to execute a trusted application corresponding to the first data processing request; wherein the trusted application is located in the first domain;

[0009] The execution result of the trusted application is returned to the second hardware domain.

[0010] In some embodiments, the first hardware domain runs a first operating system, and the second hardware domain runs a second operating system;

[0011] When the first operating system is different from the second operating system, the first driver drives the first domain to execute a trusted application corresponding to the first data processing request, including:

[0012] The first driver sends a first invocation request to the first target application of the second trusted application library;

[0013] The first target application converts the first call request into a second call request and sends the second call request to the first trusted application library;

[0014] In response to the second invocation request, the first trusted application library invokes the second driver through the core application programming interface within the global platform trusted execution environment;

[0015] The second driver drives the first trusted application library to execute the trusted application corresponding to the first data processing request.

[0016] In some embodiments, the first trusted application library calls the second driver through the core application programming interface within the global platform trusted execution environment, including:

[0017] The first trusted application library converts a first call request that conforms to the core application programming interface standard of the global platform trusted execution environment into a second call request that conforms to the requirements of the second trusted application library framework.

[0018] In some embodiments, the method further includes:

[0019] The second hardware domain sends a first data processing request to the first domain;

[0020] Invoke the third driver in the first domain, wherein the third driver corresponds to the second data processing request;

[0021] The third driver drives the first domain to execute a trusted application corresponding to the second data processing request; wherein the trusted application is located in the first domain;

[0022] The execution result of the trusted application is returned to the second domain.

[0023] In some embodiments, the second hardware domain sends a first data processing request to the first domain of the first hardware domain, including:

[0024] In response to a request to process the first data, the second hardware domain invokes a target library file in the second hardware domain, the target library file corresponding to the first data;

[0025] The target library file drives the front end of the trusted zone of the first hardware domain through a kernel driver;

[0026] The front end of the trust zone sends the first data processing request to the back end of the trust zone;

[0027] The backend of the trusted zone sends the first data processing request to the request processing module;

[0028] The request processing module generates a security monitor invocation instruction corresponding to the first data processing request;

[0029] The first driver is invoked based on the security monitor invocation instruction.

[0030] In some embodiments, the security monitor call includes an opcode and parameter information corresponding to the first data processing request, the opcode and parameter information being used to execute access to the trusted application corresponding to the first data processing request.

[0031] In some embodiments, returning the execution result of the trusted application to a second hardware domain includes:

[0032] Store the execution result of the trusted application to the target register or target memory location;

[0033] The second hardware domain invokes the execution result stored in the target register or the target memory location.

[0034] This application also provides a system-on-a-chip that performs data processing using any of the methods described in the above embodiments.

[0035] This application also provides an electronic device, including the chip described in the above embodiments.

[0036] This application also provides an in-vehicle intelligent system, including the chip described in the above embodiments.

[0037] The beneficial effects of the embodiments of this application are as follows:

[0038] By leveraging a unified information security architecture, information security services can be provided to operating systems in multiple hardware domains with hardware isolation or different domains within a unified hardware domain. This ensures that sensitive data processing and critical business operations in each operating system are under secure protection, enabling secure collaboration across hardware domains. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This is a flowchart of the data processing for this application;

[0041] Figure 2 This is a structural block diagram of the first hardware domain and the second hardware domain of this application. Detailed Implementation

[0042] Various embodiments and features of this application are described herein with reference to the accompanying drawings.

[0043] It should be understood that various modifications can be made to the embodiments described herein. Therefore, the above description should not be considered as limiting, but merely as an example of embodiments. Other modifications within the scope and spirit of this application will be apparent to those skilled in the art.

[0044] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the present application and, together with the general description of the present application given above and the detailed description of the embodiments given below, serve to explain the principles of the present application.

[0045] These and other features of this application will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.

[0046] It should also be understood that although this application has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of this application.

[0047] The above and other aspects, features and advantages of this application will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.

[0048] Specific embodiments of this application are described thereafter with reference to the accompanying drawings; however, it should be understood that the claimed embodiments are merely examples of this application, which can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the application. Therefore, the specific structural and functional details claimed herein are not intended to be limiting, but merely serve as the basis and representative basis for the claims to teach those skilled in the art to use this application in a variety of substantially any suitable detailed structures.

[0049] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” all of which may refer to one or more of the same or different embodiments according to this application.

[0050] First, a brief introduction will be given to the technical terms and related application environments involved in the embodiments of this application.

[0051] A System on Chip (SoC) refers to a system that integrates multiple hardware components, such as a CPU, memory controller, and graphics processing unit (GPU), onto a single chip to create a complete computing system. An SoC can contain a single wafer or multiple identical or different wafers.

[0052] A multi-core heterogeneous system consists of multiple single-core or multi-core processors of different types. The difference in multi-core heterogeneity lies at the hardware level. A multi-core heterogeneous system includes at least two processor cores with different architectures, and the hardware resources connected to each processor core constitute hardware-independent domains.

[0053] A domain is a region or functional block within a chip. Each region or functional block is called a domain.

[0054] TEE: Trusted Execution Environment (TEE) is a hardware-based security technology designed to provide a secure, isolated, and trusted runtime environment for sensitive data and critical applications. It ensures that code executing and data processing within this specific environment can operate in a relatively isolated and protected space. Even if the entire device is in a complex system environment with potential security threats, the data and operations within the TEE are not easily obtained or tampered with by malware, external attackers, or other malicious actors.

[0055] In semiconductor chips, architectures like ARM (a Reduced Instruction Set Computer (RISC) architecture widely used in chips for mobile devices and IoT devices) offer excellent support for TEEs. For example, ARM's TrustZone technology is a typical way to implement a TEE. It divides the processor core of the chip into different areas, isolating the ordinary execution environment (usually called the Rich Execution Environment, or REE, the environment where we use various software daily) from the trusted execution environment at the hardware level. This isolation is like using sturdy walls to separate a secure small room in a large house. Normal system software and applications operate in other spaces (REEs) of the large house, while code and data related to sensitive operations such as cryptographic operations and fingerprint recognition run and are stored in this secure small room (TEE). The two areas have their own independent hardware resource access permissions to ensure security.

[0056] Trusty refers to a secure operating system that provides a Trusted Execution Environment (TEE) for the Android system. Trusty's kernel is based on a lightweight operating system kernel (Little Kernel), which provides fundamental kernel functions such as process scheduling and memory management for the entire system. Within the Linux kernel, there are Trusty-related drivers that primarily handle data interaction between the insecure and secure operating systems, serving as a crucial bridge for communication between them. In Android's user space, there exist specific library files, known as user-space libraries. These libraries communicate with trusted applications running within the Trusty operating system through kernel drivers, enabling collaborative work between the Android and Trusty systems.

[0057] OP-TEE, short for Open Portable Trusted Execution Environment, is an open-source, portable trusted execution environment operating system primarily used to provide security services for Linux-based systems, such as encryption, digital signatures, and key management, to protect sensitive data and critical operations. Based on TrustZone technology: OP-TEE relies primarily on Arm TrustZone technology for hardware-level isolation. TrustZone divides the processor core into a secure world and a non-secure world. OP-TEE runs in the secure world, while the Linux kernel and other ordinary applications run in the non-secure world. This isolation mechanism ensures that sensitive data and operations within OP-TEE cannot be easily accessed or tampered with by malware or attackers in the non-secure world. Communication mechanism: When a Linux application needs to use the security services provided by OP-TEE, it sends a request to tee-supplicant through the TEE client API library. tee-supplicant then forwards the request to the OP-TEE driver, which in turn passes the request to the OP-TEE core via the SMC (Security Monitor Invocation) instruction. The SMC (Security Monitor Call) instruction is a special instruction used to switch and communicate between different execution environments (such as the normal world and the secure world). Here, the OP-TEE driver uses the SMC instruction to notify the hardware's security monitor to switch the request from the normal Linux execution environment to the secure execution environment where the OP-TEE resides, thus passing the request to the OP-TEE core. The OP-TEE core is the core part of OP-TEE; it manages and executes various trusted applications, handling security-related operations and requests. The OP-TEE core executes the corresponding trusted application and returns the result to the Linux application via the reverse path, thus providing the Linux application with the requested security service. Linux applications refer to various software programs running on the Linux operating system, each with different functions and uses. The TEE client API library is a set of functions and interfaces that provide a way for Linux applications to interact with OP-TEE. Applications can initiate requests for security services by calling these API functions. The OP-TEE driver is a software module in the operating system that interacts with the hardware. It is responsible for communicating with the underlying OP-TEE hardware, passing requests from tee-supplicant to the hardware-related OP-TEE parts for further processing. tee-supplicant is a service program running on the Linux system that acts as an intermediary bridge between Linux applications and OP-TEE.It receives requests from Linux applications via the TEE client API library and prepares to forward them further.

[0058] Trusty and OP-TEE are essentially operating systems, and do not strictly require Android or Linux to run.

[0059] After introducing the technical terms and related application environments involved in this application, the design concept of the embodiments of this application will be briefly introduced next.

[0060] Combination Figure 1 This application provides a data processing method applicable to a system-on-a-chip (SoC). The SoC includes a first hardware domain and a second hardware domain. The first hardware domain comprises a first domain and a second domain, and the first hardware domain and the second hardware domain are hardware isolated. Hardware isolation refers to the fact that, in a System-on-a-Chip (SoC), taking a group of CPUs (Central Processing Units) and GPUs (Graphics Processing Units) as an example, the CPUs and GPUs independently support the operating system of one hardware domain and do not directly support the operating system of the other hardware domain. These operating systems can be the same or different operating systems, depending on the requirements. The first hardware domain can be represented as... Figure 2 In AP2, the first hardware domain can correspond to either a Linux system or a QNX system, and the second hardware domain can be represented as... Figure 2 In the example of AP1, the second hardware domain corresponds to the Android system. In this embodiment, the first hardware domain is AP2, the first hardware domain corresponds to the Linux system, and the second hardware domain is AP1, the second hardware domain corresponds to the Android system.

[0061] The first and second domains of the first hardware domain are isolated at the hardware level. The first domain contains a first trusted application library providing secure storage services and a second trusted application library providing services to the second hardware domain, thus providing a trusted execution environment. The second and third hardware domains of the first hardware domain cannot provide a trusted execution environment. Overall, the first and second hardware domains are hardware equivalent; the first hardware domain is simply configured with the permissions to use the information security hardware to provide a trusted execution environment. This separation between the first and second hardware domains can be configured. The first and second domains belong to different applications within the operating system corresponding to the first hardware domain. The first domain is configured with the permission to invoke the information security hardware to achieve secure data transmission and processing by calling the encryption / decryption circuit modules required by the second domain and / or the corresponding hardware domain. The second domain does not have the same access permissions as the first domain. The first and second domains are mutually exclusive; a CPU can only support the execution environment provided by one of the first and second domains, and cannot support both simultaneously. The first hardware domain uses TrustZone technology and is a trusted domain. Therefore, all operations on the information security module are performed only in the first domain of the first hardware domain, and are thus trustworthy.

[0062] Of course, it is understandable that the second hardware domain can also be configured with the permissions and functions of the first hardware domain, while the first hardware domain can be configured with the permissions and functions of the second hardware domain in the above embodiments.

[0063] The data processing method includes:

[0064] S10, the second hardware domain sends a first data processing request to the first domain.

[0065] For example, when a second hardware domain needs to perform a security-related task, since the second hardware domain lacks a trusted execution environment while the first domain of the first hardware domain does, the second hardware domain can send a first data processing request to the first domain of the first hardware domain. For instance, the first data processing request could be a request to decrypt encrypted data or to encrypt data. Of course, the specific content of the first data processing request could also be other processing of sensitive data or operations on critical business processes, etc., without specific limitations here.

[0066] The second hardware domain sends a first data processing request to the first domain, including:

[0067] S101, in response to the request to process the first data, the second hardware domain calls the target library file in the second hardware domain, and the target library file corresponds to the first data.

[0068] For example, the first hardware domain includes a trust zone, which can be further divided into a front-end and a back-end, as well as dedicated request processing modules and drivers. These components work together to perform secure data processing.

[0069] The request to process the first data may originate from other parts of the system, such as upper-layer applications. When an application needs to process specific first data, it sends this request to the second hardware domain.

[0070] The correspondence between target library files and the first data includes the correspondence of data types. For example, target library files may be organized according to data types. If the first data is image data, the corresponding target library file might be a library specifically for image processing, containing various image filtering, enhancement, and compression functions. If the first data is audio data, the corresponding target library file would be an audio processing library, containing audio decoding, noise reduction, and mixing functions. It also includes the correspondence of data identifiers. For example, each piece of first data may have a unique identifier, which the target library file uses to associate with it. For instance, in a database management system, different data records have different IDs. The target library file would contain a mapping table that associates these IDs with corresponding processing functions or modules. When a data processing request for a specific ID is received, the corresponding target library file can be found through the mapping table.

[0071] Upon receiving the request, the second hardware domain will search for the corresponding target library file in its local library file set based on the characteristics of the first data (such as type, identifier, etc.), and load the file into memory in preparation for subsequent processing.

[0072] S102, the target library file drives the front end of the trusted zone of the first hardware domain through a kernel driver.

[0073] For example, a kernel driver is part of the operating system kernel and provides an interface between hardware and software. In this scenario, the object library file needs to communicate with the trusted zone frontend of the first hardware domain through the kernel driver. The kernel driver is responsible for translating the instructions issued by the object library file into a format that the trusted zone frontend can understand and passing it to the trusted zone frontend.

[0074] This step may involve system calls. For example, the target library file may initiate a system call to request services from the kernel driver. System calls are a way for user-space programs to interact with kernel space. For instance, in Linux systems, the target library file can use the ioctl system call to send specific control commands to the kernel driver, informing the kernel driver what operations to drive the trusted zone frontend to perform. Data transfer is also involved. The target library file passes data and parameters related to the initial data processing request to the kernel driver. The kernel driver encapsulates this data and parameters into a specific message format and then sends it to the trusted zone frontend via a hardware interface (such as PCIe, USB, etc.). State synchronization may also be involved. For example, the kernel driver is also responsible for monitoring the state of the trusted zone frontend and feeding back state information to the target library file. For instance, when the trusted zone frontend finishes processing a request, it sends a completion signal to the kernel driver, which then passes this signal to the target library file so that the target library file can continue with subsequent operations.

[0075] S103, the front end of the trust zone sends the first data processing request to the back end of the trust zone.

[0076] For example, the trusted zone frontend is primarily responsible for receiving requests from external sources and performing initial processing and validation. It checks the legitimacy of the request, such as whether the request format is correct and whether the requested permissions are sufficient.

[0077] After successful verification, the trusted zone frontend forwards the first data processing request to the trusted zone backend. This process may involve re-encapsulating and encrypting the data to ensure its security during transmission. For example, the request data may be encrypted using a symmetric encryption algorithm and then sent to the backend through an internal communication channel.

[0078] S104, the backend of the trusted zone sends the first data processing request to the request processing module.

[0079] For example, the trust zone backend is responsible for receiving requests from the frontend and further processing and scheduling them. It assigns requests to the appropriate request handling module based on the request type and priority. A request handling module is a component or class that handles HTTP requests, typically used in web frameworks. Its main function is to receive client requests and generate corresponding responses. This includes parsing request data, routing to the appropriate processing function, and generating responses.

[0080] The trusted zone backend may maintain a request queue, which is ordered according to the priority of the requests. When an idle request processing module is available, the backend will take a request from the queue and send it to that module for processing.

[0081] S105, the request processing module generates a security monitor call instruction corresponding to the first data processing request.

[0082] For example, the request processing module is a component specifically responsible for handling various data processing requests. It analyzes the specific content of the first data processing request, determines the operations to be performed, and generates corresponding security monitor invocation instructions, such as... Figure 2 The diagram illustrates an SMC call instruction. An SMC call is a mechanism for transferring data from the Normal World to the Secure World. Applications running in the Normal World can use SMC calls to request privileged operations from code running in the Secure World, such as accessing system resources and executing system calls. This ensures that sensitive operations are performed in a secure environment, thereby improving system security. SMC calls can be applied to scenarios requiring high security, such as the implementation of Trusted Execution Environments (TEEs). TEEs run in a separate first hardware domain, ensuring the secure storage, transmission, and processing of sensitive data. Through SMC calls, applications in the insecure world can communicate with the TEE to achieve secure data transmission and processing.

[0083] The request processing module converts the first data processing request into instructions that the security monitor can understand, based on predefined rules and algorithms. For example, if the first data processing request is to encrypt sensitive data, the request processing module will generate a security monitor invocation instruction containing information such as the encryption algorithm and key.

[0084] When an application outside the secure view needs to perform a privileged operation, the request handling module initiates an SMC call instruction. This call instruction contains information such as the opcode to be executed and the parameters.

[0085] Upon receiving an SMC call instruction, the ARM processor enters an anomalous state within the secure world. In this secure world, a dedicated SMC processor handles these call instructions.

[0086] The SMC processor executes corresponding operations based on the opcode and parameters. These operations may include accessing system resources, executing system calls, etc.

[0087] After the operation is complete, the SMC processor returns the result to the application outside the secure field of view. This process can be achieved by writing the result to a specific register or memory location.

[0088] S106, the first driver is invoked based on the security monitor invocation instruction.

[0089] For example, a security monitor is a critical component in a semiconductor system, responsible for monitoring and managing the system's secure operations. The security monitor verifies and authorizes commands invoked by the security monitor, ensuring the legitimacy and security of those commands.

[0090] After successful verification, the security monitor will invoke the first driver according to the instructions. The first driver will then interact with the hardware device to perform specific operations, such as encrypting, decrypting, and storing the first data.

[0091] The security monitor call includes an opcode and parameter information corresponding to the first data processing request, and the opcode and parameter information are used to execute access to the trusted application corresponding to the first data processing request.

[0092] The opcodes and parameters contained in the security monitor call serve as a crucial bridge connecting the initial data processing request with the trusted application. The opcodes specify the exact type of operation to be performed, while the parameters provide the detailed data required to execute that operation. Together, they enable the trusted application to process the initial data accurately.

[0093] Opcodes are typically represented using fixed-length binary encoding. For example, in a simple system, an opcode might be represented using an 8-bit binary number. Different binary combinations correspond to different operation types, as shown in the table below:

[0094] Opcode (binary) Operation type 00000001 Data encryption 00000010 Data Decryption 00000011 Data storage 00000100 Data reading

[0095] This fixed-length encoding method facilitates rapid identification of operation types by security monitors, improving processing efficiency. The encoding rules for opcodes are typically predefined by the system developers.

[0096] The format of parameter information varies depending on the opcode. Generally, it consists of multiple fields, each representing a different meaning. For example, in data encryption operations, parameter information might include the following fields:

[0097]

[0098] Each opcode corresponds to a specific function or method within a trusted application. Upon receiving an opcode, the security monitor uses a predefined mapping table to locate the corresponding function or method within the trusted application. For example, when the opcode is 00000001 (data encryption), the security monitor will call the function named `encrypt_data` within the trusted application. Parameter information serves as input to the function or method in the trusted application. When calling the function or method, the security monitor passes the parameter information according to the function's or method's parameter list. For instance, when calling the `encrypt_data` function, the starting address of the data, the data length, the encryption algorithm identifier, and the key number are passed as parameters to the function so that it can correctly encrypt the initial data.

[0099] S20, invoke the first driver in the first domain, wherein the first driver corresponds to the first data processing request, and the first driver can perform data interaction and collaborative operation with the first trusted application library and the second trusted application library respectively during driver execution, so that both the first hardware domain and the second hardware domain have security protection capabilities.

[0100] For example, for the first domain to perform corresponding processing operations on the first data processing request, it needs to call the first driver program corresponding to the first data processing request. Here, the correspondence between the first driver program and the first data processing request means that the execution of the first driver program can realize the processing of the first data processing request. For example, if the second hardware domain needs to encrypt data, the first driver program can be, but is not limited to, a Crypto driver. A Crypto driver is a software driver program used to control and manage encryption-related hardware or functions. A Crypto driver can implement encryption functions; for example, it can call hardware encryption modules or execute software encryption algorithms to encrypt and decrypt data, ensuring data confidentiality. For example, when storing sensitive data, the Crypto driver can use algorithms such as the Advanced Encryption Standard (AES) to encrypt the data, storing it in ciphertext form, and the original data can only be obtained through the corresponding decryption operation.

[0101] Alternatively, if the first data processing request is to launch software with high security requirements, the Crypto driver can perform authentication and authorization. That is, the Crypto driver supports authentication mechanisms such as digital signatures and hash calculations to verify the identity and integrity of devices, users, or data, preventing unauthorized access and data tampering. By verifying the digital signature of the software being launched through the Crypto driver, it ensures that the software has not been tampered with, thereby achieving secure startup.

[0102] Of course, it is understandable that the first data processing request can also be other types of data processing requests, and the first driver can also be other drivers (e.g., Figure 2 The various drivers shown in the document—Crypto driver, "watchdog driver" (a driver for controlling and managing watchdog timers), "Fuse driver" (a driver for controlling and operating eFuse), "Firewall driver" (a driver for controlling and managing firewall functions), "RTC driver" (a driver for controlling and managing RTC), "COM driver" (a driver for enabling data transfer and interaction between semiconductor devices and external devices or systems), and "RPMB" (Replay Protection Block)—are merely examples and do not constitute a limitation on the scope of the claims.

[0103] Taking automotive electronics as an example, with the development of vehicle intelligence and connectivity, a large amount of sensitive data in vehicles needs protection, such as vehicle control commands and user personal information. For example, in autonomous driving scenarios, the vehicle's control room can use the aforementioned system-on-a-chip. If the second hardware domain wants to achieve communication with the outside world and in reverse, and this communication data needs to be encrypted, then the second hardware domain can send a request to the first domain of the first hardware domain, which has a trusted execution environment, to encrypt the communication data. At this time, the Crypto driver can be called to encrypt the data of vehicle communication with the outside world, preventing hacker attacks from causing the vehicle to lose control. At the same time, its identity authentication function ensures that only authorized devices can communicate with the vehicle's electronic control unit (ECU).

[0104] Of course, there may be other specific application scenarios. This is only used as an example and does not constitute a limitation on the scope of protection of the claims.

[0105] During driver execution, the first driver can interact and collaborate with the first and second trusted application libraries set in the first domain of the first hardware domain, respectively, to ensure that both the first and second hardware domains have security protection capabilities. For example, the first trusted application library can be a key application library, and the second trusted application library can be a secure storage application library. The first domain includes the Trusty application library and the OP-TEE application library. The trusted execution environment of the first domain can provide services to Linux system-side applications and Android system-side applications through the second trusted application library of the OP-TEE. On devices that need to utilize the rich application ecosystem of Android while relying on specific services of the Linux system (such as applications requiring data storage and encrypted transmission under a Linux environment), such as hybrid smart devices and in-vehicle intelligent systems, this driver can effectively balance the information security needs of applications in both ecosystems, providing corresponding secure storage, encrypted computation, and other security services for both Android and Linux system-side applications.

[0106] The first and second trusted application libraries can be converted and called. For example, for some functions unique to the first trusted application library, they will be directly connected to the Trusty TEE driver layer through the native driver interface of Trusty TEE. For the second trusted application library, function call requests conforming to the General Internal Application Programming Interface (GP InternalAPI) standard can also be translated into driver call requests conforming to the Trusty TEE framework through the translated interface. This ensures that third-party secure storage applications conforming to the General (GP) standard can also run directly in this trusted execution environment without any modification.

[0107] S30, the first driver drives the first domain to execute a trusted application corresponding to the first data processing request; wherein the trusted application is located in the first domain.

[0108] Instance-wise, when the first driver is invoked, it drives the execution of one or more trusted applications within the first domain to fulfill a first data processing request. For example, if the first data processing request is to encrypt data, the first driver may be, but is not limited to, a software driver (Crypto driver) for controlling and managing encryption-related hardware or functions. The Crypto driver can implement data encryption functionality. For instance, it can invoke hardware encryption modules or execute software encryption algorithms to encrypt and decrypt data, ensuring data confidentiality. For example, when storing sensitive data, the Crypto driver can encrypt the data using algorithms such as the Advanced Encryption Standard (AES), storing the data in ciphertext form, where the original data can only be retrieved through appropriate decryption operations.

[0109] In some embodiments, the first hardware domain runs a first operating system, and the second hardware domain runs a second operating system.

[0110] In cases where the first operating system and the second operating system differ, the first driver drives the first domain to execute a trusted application corresponding to the first data processing request, including:

[0111] S31, the first driver sends a first call request to the first target application of the second trusted application library.

[0112] For example, if the first driver needs to call a trusted application in the first trusted application library, but the first driver cannot directly call the trusted application in the first trusted application library, then the first driver can call the trusted application in the first trusted application library through the data conversion and calling relationship between the second trusted application library and the first trusted application library.

[0113] For example, the first driver can first call the second trusted application library (to... Figure 2 Taking a trusted application in the OP-TEE trusted application library as an example, and taking this trusted application as a secure storage trusted application, then the first target application is the secure storage trusted application. Of course, it is understood that the first target application can also be other trusted applications in the second trusted application library (not shown in the figure), this is only used as an example and does not constitute a limitation on the scope of protection of the claims. The invocation of the trusted application in the first trusted application library corresponding to the first data processing request requires the execution of the first target application. Therefore, the first driver can send the first invocation request to the first target application of the second trusted application so that the first target application can be executed.

[0114] S32, the first target application converts the first call request into a second call request and sends the second call request to the first trusted application library.

[0115] For example, the first target application can first convert the first call request into a second call request that can call the second driver, and then send the converted second call request to the first trusted application library.

[0116] S33, in response to the second call request, the first trusted application library calls the second driver through the core application programming interface inside the global platform trusted execution environment.

[0117] For example, upon receiving the second invocation request, the first trusted application library can invoke the second driver in response. For instance, the first trusted application library can invoke the second driver through the core application programming interface within the Trusted Execution Environment (TEE) of the global platform. Of course, it is understood that the first trusted application library can also invoke the second driver in other ways, as long as the invocation requirements of the second driver are met.

[0118] S34, the second driver drives the first trusted application library to execute the trusted application corresponding to the first data processing request.

[0119] For example, after receiving the second invocation request, the second driver can drive the first trusted application library to execute a trusted application within the first trusted application library, which corresponds to the first data processing request. For instance, if the first data processing request is to retrieve a key from the key application library within the first trusted application library, then the second driver is the driver that drives the key application library to execute.

[0120] Of course, the above steps S31 to S34 are illustrated by taking the example of the first data processing request calling a trusted application in the first trusted application library through the conversion call relationship between the second trusted application library and the first trusted application library. In specific applications, if the first data processing request requires the trusted application in the second trusted application library to be executed, but the first data processing request cannot directly call the trusted application in the second trusted application library through the driver, a third call request can be sent to the first trusted application library first, and then a call conversion method similar to steps S31 to S34 can be used to convert the third call request into a fourth call request through the first trusted application library, and then the trusted application in the second trusted application library can be called through the fourth call request.

[0121] In some embodiments, the first trusted application library calls the second driver through the core application programming interface within the global platform trusted execution environment, including:

[0122] The first trusted application library (TPL) converts a first invocation request conforming to the global platform's trusted execution environment (TEX) internal core application programming interface (API) standard into a second invocation request conforming to the requirements of the second trusted application library framework. The internal core application programming interface (API) is a set of predefined functions used to enable interaction between different software. Specifically, when the first trusted application library initiates a call, it generates a first invocation request conforming to the global platform's TEX internal core API standard. This request is like a detailed "task list," containing information about the operation to be performed, such as reading data, writing data, or performing a calculation, as well as information about the data involved and the target address of the operation. Because the second trusted application library framework has its own unique requirements, the first invocation request cannot be directly used by the second trusted application library framework and therefore needs to be converted. For example, data format conversion is necessary; different application library frameworks may have different requirements for data format. For instance, the data in the first invocation request might be represented as a hexadecimal string, while the second trusted application library framework requires a binary array format. In this case, the hexadecimal string needs to be converted to a binary array. Assuming the data in the first call request is a hexadecimal string like "0A1B", the conversion can be performed by grouping each pair of characters together and converting them into corresponding 8-bit binary numbers, ultimately resulting in a binary array. Parameter order adjustments may also be involved, as the two frameworks may have different rules regarding parameter arrangement. For example, in the first call request, the parameter order might be [operation type, data, target address], while the second trusted application library framework requires [target address, operation type, data]. In this case, the parameter order needs to be adjusted to meet the requirements of the second framework. Additionally, keyword substitution may be involved, as different frameworks may use different keywords to represent the same or similar operations. For instance, the first call request might use "READ" to represent a read operation, while the second trusted application library framework uses "FETCH" to represent the same operation. Therefore, "READ" needs to be replaced with "FETCH" during the conversion.

[0123] The conversion between the first and second call requests may involve data encoding conversion algorithms, such as the conversion from hexadecimal strings to binary arrays mentioned above. In Python, this can be achieved using the following code:

[0124] Python

[0125] hex_string = "0A1B"

[0126] binary_array=bytes.fromhex(hex_string)

[0127] print(binary_array)

[0128] Keyword replacement may involve regular expression matching and replacement algorithms. Regular expressions can be used when keyword replacement is required. For example, using Python's `re` module to replace "READ" with "FETCH":

[0129] Python

[0130] import re

[0131] original_request="READ data from address"

[0132] new_request=re.sub(r'READ','FETCH',original_request)

[0133] print(new_request)

[0134] The above process may utilize scripting languages ​​such as Python and JavaScript, which can easily implement various conversion logics. Scripts can be written to perform operations such as data format conversion, parameter order adjustment, and keyword replacement.

[0135] After the above conversion process, a second invocation request that conforms to the requirements of the second trusted application library framework is obtained. This request can be correctly identified and processed by the second trusted application library framework, thereby completing the corresponding operation.

[0136] The first trusted application library transforms a first call request that conforms to the core application programming interface standard of the global platform trusted execution environment into a second call request that conforms to the requirements of the second trusted application library framework, thereby enabling the call to the second driver.

[0137] S40, the execution result of the trusted application is returned to the second hardware domain.

[0138] In practice, once the trusted application runs, it will produce an execution result, which will be returned to the second hardware domain so that the second hardware domain can achieve its desired functionality through the execution of the trusted application in the trusted execution environment of the first domain in the first hardware domain.

[0139] In some instances, returning the execution result of the trusted application to a second hardware domain includes:

[0140] S401, store the execution result of the trusted application into the target register or target memory location.

[0141] For example, after a trusted application completes data processing and generates execution results, if the amount of data is small, a target register storage method is suitable. The system pre-allocates specific registers for storing execution results. These registers have high-speed read / write capabilities, enabling rapid response to data storage and retrieval operations. For instance, the system specifies register R5 to store processing status flags (e.g., 0 indicates success, 1 indicates failure). The trusted application writes the processing status flags to this register using specific instructions. During the writing process, the register can be cleared first to ensure that the latest execution result is stored.

[0142] If the execution result data is large, such as a large amount of encrypted user privacy data, a target memory location storage method can be used. A secure memory region can be specifically allocated within the first hardware domain as the target memory location to store the execution result. During storage, the trusted application first sends a request to the memory management unit to obtain access permissions to this memory region. Then, the execution result is written to this region sequentially according to memory address order. To improve storage efficiency, a paging storage method may be used, dividing the execution result into multiple fixed-size pages and storing them sequentially in different pages of memory.

[0143] For target register storage, due to the limited storage space of registers, a simple binary encoding format is usually used. For example, a 1-bit binary number is used to represent the processing status (0 or 1), and an 8-bit binary number is used to represent a simple error code. This allows for efficient storage of critical information within the limited register space.

[0144] Since the target memory location stores a large amount of data, a more complex storage format can be used. For example, a structure format can be used, dividing the execution result according to different fields. For instance, for encrypted data processing results, the structure might contain the following fields: a data length field, indicating the number of bytes in the encrypted data; an encryption algorithm identifier field, indicating the type of encryption algorithm used; an encrypted data field, storing the actual encrypted data; and a hash value field, storing the hash value obtained by hashing the encrypted data, used for subsequent data integrity verification. These fields are stored sequentially in the target memory location in a fixed order so that the second hardware domain can accurately parse them.

[0145] S402, the second hardware domain calls the execution result stored in the target register or the target memory location.

[0146] For example, the second hardware domain accesses the execution result in the target register. Specifically, after initiating a data processing request, the second hardware domain can periodically send a query signal to the first hardware domain via a hardware interface to inquire whether the execution result is ready. When the first hardware domain detects that the execution result has been stored in the target register, it will send a result ready signal to the second hardware domain via a hardware interface.

[0147] After receiving the result-ready signal, the second hardware domain reads the execution result from the target register using a specific read instruction. For example, a dedicated register read instruction is used to read the processing status flag in register R5. After reading, the second hardware domain can parse and process the read result, determine whether the data processing was successful based on the processing status flag, and perform corresponding follow-up operations, such as notifying the user or proceeding to the next data processing step.

[0148] Similarly, the second hardware domain can continuously check whether the result is ready after sending a data processing request. When it receives a result ready signal from the first hardware domain and knows that the execution result is stored in the target memory location, the second hardware domain can send a memory read request to the first hardware domain through the hardware interface. This request contains the starting address and data length information of the target memory location to be read.

[0149] Upon receiving a request, the first hardware domain reads the corresponding data from the target memory location based on the starting address and data length specified in the request. During the reading process, a data integrity check is performed to ensure that the read data matches the stored data. Then, the read data is transmitted to the second hardware domain via the hardware interface.

[0150] After receiving the data, the second hardware domain first parses the data according to its storage format. For example, it extracts the data length field, encryption algorithm identifier field, encrypted data field, and hash value field. Then, it performs a hash calculation on the encrypted data and compares the calculated hash value with the received hash value to verify the data's integrity. If the verification passes, the data is considered unaltered during transmission and the result can be used; if the verification fails, an error feedback is sent to the first hardware domain, requesting a retransmission of the data.

[0151] In some embodiments, a second domain in the first hardware domain that does not have a trusted execution environment can also perform security-related data processing through the first domain that has a trusted execution environment. That is, the method further includes:

[0152] The second domain sends a second data processing request to the first domain.

[0153] For example, the second domain may include a secure storage client that requires secure data storage. However, the second domain lacks a trusted execution environment and needs to collaborate with the first domain to ensure data security. For instance, when the secure storage client receives an instruction to securely store data, the second domain may send a second data processing request to the first domain to request secure data storage.

[0154] For example, the secure storage client in the second domain is responsible for receiving sensitive user data, such as user ID card numbers and bank card information. Because this data is highly sensitive, it needs to be stored securely. However, the second domain itself lacks a trusted execution environment and cannot guarantee the security of the data during storage.

[0155] Once the secure storage client receives an instruction to securely store this data, the second domain will send a second data processing request to the first domain according to a predefined communication protocol. This second data processing request may include the following information:

[0156] Data content: This refers to sensitive user data that needs to be stored securely.

[0157] Request type: This explicitly indicates that this is a secure storage request.

[0158] Target storage location: Specifies the specific location where the data needs to be stored, for example, a specific secure storage area in the first domain.

[0159] To ensure the security of the request during transmission, the second domain can encrypt the second data processing request, for example, using a symmetric encryption algorithm, or using a pre-negotiated key. Furthermore, to guarantee the integrity of the request, a digital signature can be added, such as signing the hash value of the request using the private key of the second domain.

[0160] Based on the second data processing request, the third driver in the first domain is invoked.

[0161] Upon receiving the encryption request from the second domain, the first domain first decrypts the request using a pre-agreed key. Then, it verifies the validity of the digital signature to ensure the request has not been tampered with during transmission.

[0162] Once verification is successful, the first domain will search for the corresponding third driver in its driver set based on the request type. In this embodiment, since it is a secure storage request, a third driver specifically designed for handling secure storage requests will be found. The third driver contains the underlying logic for interacting with the storage device, as well as the interface for communicating with trusted applications.

[0163] The third driver drives the first domain to execute the trusted application corresponding to the second data processing request.

[0164] After receiving the second data processing request, the third driver will further parse the request into instructions and parameters that the trusted application can understand. Specifically, it will pass information such as the data content and the target storage location to the trusted application.

[0165] Trusted applications run within a trusted execution environment in the first domain, providing a high level of security. For secure storage requests, trusted applications can perform the following actions:

[0166] Data encryption: The data is further encrypted using more advanced encryption algorithms, such as the RSA asymmetric encryption algorithm. This is to further enhance data security, ensuring that even if the data is illegally obtained during storage, it cannot be recovered without the corresponding decryption key.

[0167] Storage operation: Stores encrypted data to the specified target storage location. Strict access control is implemented during the storage process; only authorized programs and users can access the storage location.

[0168] Return the execution result of the trusted application to the second domain.

[0169] After a trusted application completes its data storage operation, it generates an execution result. The result may include status information indicating whether the storage was successful or failed. If the storage was successful, it may also contain a unique identifier for the stored data.

[0170] The first domain will encrypt and digitally sign the execution result using the same communication protocol as the second domain before sending it to the second domain. Upon receiving the execution result, the second domain will also decrypt and verify the signature. If the execution result indicates successful storage, the second domain can notify the enterprise's business system that the data has been securely stored; if storage fails, the second domain can take appropriate action based on the reason for the failure, such as resending the request or notifying the administrator to investigate.

[0171] This application also provides a system-on-a-chip (SoC) that performs data processing using any of the methods described in the above embodiments.

[0172] This application also provides an electronic device, which includes the chip described in the above embodiments.

[0173] This application also provides an in-vehicle intelligent system, which includes the chip described in the above examples.

[0174] Electronic devices may further include a processor and a memory, wherein the memory stores an executable program, and the memory executes the executable program to perform the steps of the method described above. Embodiments of this application also provide a storage medium carrying one or more computer programs, which, when executed by a processor, implement the steps of the method described above. It should be understood that, in embodiments of this application, the processor may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It should also be understood that the memory mentioned in embodiments of this application may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory (storage module) is integrated into the processor. It should be noted that the memory described herein is intended to include, but is not limited to, these and any other suitable types of memory. It should also be understood that the first, second, third, fourth, and various numerical designations used herein are merely for descriptive convenience and are not intended to limit the scope of this application. It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects are in an "or" relationship. In implementation, the steps of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the method disclosed in the embodiments of this application can be directly embodied as being executed by a hardware processor, or by a combination of hardware and software modules in the processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here. In the various embodiments of this application, the sequence numbers of the above processes do not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. Those skilled in the art will recognize that the various illustrative logical blocks (ILBs) and steps described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. In the several embodiments provided in this application, it should be understood that the disclosed methods and chips can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be indirect couplings or communication connections between devices or units through some interfaces, and may be electrical, mechanical, or other forms.The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. In the above embodiments, they can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, they can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the process or function described in the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data processing method, characterized in that, The system-on-a-chip (SoC) is applied to a system-on-a-chip (SoC) comprising a first hardware domain and a second hardware domain. The first hardware domain includes a first domain and a second domain, and the first hardware domain and the second hardware domain are hardware isolated from each other at the hardware level. The first domain is provided with a first trusted application library for providing secure storage services and a second trusted application library for providing services to the second hardware domain, thereby providing a trusted execution environment. The second domain and the second hardware domain cannot provide a trusted execution environment; The method includes: The second hardware domain sends a first data processing request to the first domain; The first driver in the first domain is invoked, wherein the first driver corresponds to the first data processing request, and the first driver can perform data interaction and collaborative operation with the first trusted application library and the second trusted application library respectively during driver execution, so that both the first hardware domain and the second hardware domain have security protection capabilities. The first driver drives the first domain to execute a trusted application corresponding to the first data processing request; wherein the trusted application is located in the first domain; The execution result of the trusted application is returned to the second hardware domain.

2. The method according to claim 1, characterized in that, The first hardware domain runs a first operating system, and the second hardware domain runs a second operating system. When the first operating system is different from the second operating system, the first driver drives the first domain to execute a trusted application corresponding to the first data processing request, including: The first driver sends a first invocation request to the first target application of the second trusted application library; The first target application converts the first call request into a second call request and sends the second call request to the first trusted application library; In response to the second invocation request, the first trusted application library invokes the second driver through the core application programming interface within the global platform trusted execution environment; The second driver drives the first trusted application library to execute the trusted application corresponding to the first data processing request.

3. The method according to claim 2, characterized in that, The first trusted application library calls the second driver through the core application programming interface within the global platform trusted execution environment, including: The first trusted application library converts a first call request that conforms to the core application programming interface standard of the global platform trusted execution environment into a second call request that conforms to the requirements of the second trusted application library framework.

4. The method according to claim 2, characterized in that, The method further includes: The second domain sends a second data processing request to the first domain; Invoke the third driver in the first domain, wherein the third driver corresponds to the second data processing request; The third driver drives the first domain to execute a trusted application corresponding to the second data processing request; wherein the trusted application is located in the first domain; The execution result of the trusted application is returned to the second domain.

5. The method according to claim 1, characterized in that, The second hardware domain sends a first data processing request to the first domain, including: In response to a request to process the first data, the second hardware domain invokes a target library file in the second hardware domain, the target library file corresponding to the first data; The target library file drives the front end of the trusted zone of the first hardware domain through a kernel driver; The front end of the trust zone sends the first data processing request to the back end of the trust zone; The backend of the trusted zone sends the first data processing request to the request processing module; The request processing module generates a security monitor invocation instruction corresponding to the first data processing request; The first driver is invoked based on the security monitor invocation instruction.

6. The method according to claim 5, characterized in that, The security monitor call includes an opcode and parameter information corresponding to the first data processing request, and the opcode and parameter information are used to execute access to the trusted application corresponding to the first data processing request.

7. The method according to claim 1, characterized in that, Returning the execution result of the trusted application to the second hardware domain includes: Store the execution result of the trusted application to the target register or target memory location; The second hardware domain invokes the execution result stored in the target register or the target memory location.

8. A system-on-a-chip, characterized in that, Data processing is performed using the method described in any one of claims 1-7.

9. An electronic device, characterized in that, Includes the chip as described in claim 8.

10. An in-vehicle intelligent system, characterized in that, Includes the chip as described in claim 8.

Images