Memory debugging method and related device

Abstract

According to the memory debugging method for the trusted firmware, in the whole debugging process, data receiving and transmitting are conducted without the help of hardware debugging modules such as a JTAG, and the hardware requirement of memory debugging on a system on a chip and the requirement of memory debugging on other external hardware are lowered. Besides, in the whole memory debugging process, the safety characteristic of the TEE is fully utilized, the second application running in the TEE is used for specific debugging, debugging data cannot be directly displayed to other hardware in a plaintext mode, and the safety of the memory debugging method can be improved.

Description

Technical Field

[0001] The present specification relates to the field of computer application technology, specifically, to trusted firmware technology under the field of computer application technology, and more specifically, to a memory debugging method and related devices. Background Art

[0002] Memory debugging is an important environment in the development of software such as trusted firmware, which involves detecting and resolving various memory-related issues to ensure that the firmware can correctly manage and use memory resources at runtime. The goal of memory debugging is to find and fix memory management errors that may cause system instability or security vulnerabilities, such as memory leaks and buffer overflows.

[0003] Traditional memory debugging methods rely on specific hardware modules (such as JTAG (Joint Test Action Group) modules, etc.), which connect the system-on-chip to the hardware debugger, and perform memory testing on the firmware running in the system-on-chip through the relevant programs of the hardware debugger. This method relies on specific hardware modules and external devices and has high hardware requirements. Summary of the invention

[0004] The embodiments of this specification provide a memory debugging method and related devices to solve the problem that memory debugging has high hardware requirements.

[0005] To achieve the above technical objectives, the embodiments of this specification provide the following technical solutions:

[0006] In a first aspect, an embodiment of the present specification provides a memory debugging method, which is applied to a system on chip, wherein the system on chip includes a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, wherein the REE is used to run a first application and a REE operating system, wherein the REE operating system includes a TEE driver, and the TEE is used to run a second application and a BL31 firmware; the memory debugging method includes:

[0007] The first application calls the TEE driver in response to the memory debugging request carrying the test information, and uses the TEE driver to call the SMC in a secure monitoring mode to send the memory debugging request to the second application through the BL31 firmware;

[0008] The second application debugs the memory data of the target firmware based on the test information in response to the memory debugging request.

[0009] In a second aspect, an embodiment of the present specification provides a system on chip, including: a processor, the processor is used to build a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a first application and a REE operating system, the REE operating system includes a TEE driver, and the TEE is used to run a second application and a BL31 firmware; wherein,

[0010] The processor is configured to: respond to a memory debugging request carrying test information through the first application, call the TEE driver, and use the TEE driver to call the SMC through a secure monitoring mode to send the memory debugging request to the second application through the BL31 firmware;

[0011] The second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information.

[0012] In a third aspect, an embodiment of the present specification further provides a computing device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the memory debugging method as described above when executing the computer program.

[0013] In a fourth aspect, an embodiment of the present specification further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the memory debugging method as described above is implemented.

[0014] In a fifth aspect, an embodiment of the present specification provides a computer program product or a computer program, wherein the computer program product includes a computer program, and the computer program is stored in a computer-readable storage medium; the processor of the computer device reads the computer program from the computer-readable storage medium, and the processor implements the steps of the above-mentioned memory debugging method when executing the computer program.

[0015] It can be seen from the above technical solution that the memory debugging method provided in the embodiment of this specification is implemented based on a system on chip including REE and TEE, REE is used to run the first application and the REE operating system, and the REE operating system includes a TEE driver, and TEE is used to run the second application and BL31 firmware. When the method is implemented, the first application responds to the memory debugging request carrying the test information, calls the TEE driver, and uses the TEE driver to send the memory debugging request to the second application through the SMC through the BL31 firmware, so that the second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information. During the entire debugging process, there is no need to use hardware debugging modules such as JTAG to receive and transmit data, which is conducive to reducing the hardware requirements of the system on chip for memory debugging and the requirements for other external hardware. In addition, the entire memory debugging process makes full use of the security features of TEE, uses the second application running in TEE for specific debugging, and does not directly display the debugging data in plain text to other hardware, which is conducive to improving the security of the memory debugging method. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0017] Figure 1 A schematic diagram of the relationship between the security architecture and the trusted firmware;

[0018] Figure 2 A flowchart of a memory debugging method provided for one embodiment of this specification;

[0019] Figure 3 A schematic diagram of an application scenario of a memory debugging method provided for one embodiment of this specification;

[0020] Figure 4 A flowchart of a memory debugging request including a data read request provided for one embodiment of the present specification;

[0021] Figure 5 A flowchart of a memory debugging request including a data writing request provided for one embodiment of the present specification;

[0022] Figure 6 A schematic diagram of the structure of a computing device provided for one embodiment of the present specification. DETAILED DESCRIPTION

[0023] Unless otherwise defined, the technical terms or scientific terms used in the embodiments of this specification shall have the common meanings understood by persons with ordinary skills in the field to which this specification belongs. The words "first", "second" and similar words used in the embodiments of this specification do not indicate any order, quantity or importance, but are only used to avoid confusion of constituent elements.

[0024] Unless the context requires otherwise, throughout the specification, "plurality" means "at least two", and "including" is interpreted as an open, inclusive meaning, that is, "including, but not limited to". In the description of the specification, the terms "one embodiment", "some embodiments", "exemplary embodiments", "examples", "specific examples" or "some examples" are intended to indicate that a particular feature, structure, material or characteristic associated with the embodiment or example is included in at least one embodiment or example of the specification. The schematic representation of the above terms does not necessarily refer to the same embodiment or example.

[0025] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

[0026] Overview

[0027] As described in the background technology, memory debugging is of great significance to the development of trusted firmware. In the related technology, memory debugging of the on-chip system is performed by relying on specific hardware modules (such as JTAG, etc.). On the one hand, the hardware design is relatively complex. For systems without integrated JTAG modules or scenarios lacking debuggers, memory debugging cannot be effectively implemented. On the other hand, through hardware debugging methods such as JTAG, the operation of the trusted firmware needs to be suspended, which affects the real-time operation of other functions of the trusted firmware.

[0028] In addition, in order to effectively obtain and write memory debugging information, conventional methods use printing or debuggers to directly obtain or write. Although this type of solution can achieve the purpose of memory debugging, the memory data of the trusted firmware does not use the secure storage mechanism provided by the trusted execution environment, and is completely exposed to the visible range. The confidentiality of the trusted firmware memory data cannot be guaranteed, which increases the risk of being stolen by attackers and fails to protect the security of sensitive data.

[0029] In order to solve this problem, the inventors proposed a memory debugging method for trusted firmware. Before introducing the main concept of the method, a brief introduction to trusted firmware is given first:

[0030] Trusted firmware refers to the firmware component used to provide a secure boot and operating environment in a computer system. Trusted firmware unifies the underlying interface standards, such as the power state control interface, secure boot requirements, and the secure monitoring mode call operation for switching between the secure world state and the normal world state. Trusted firmware aims to unify the underlying operations so that the code can be reused and ported. At the same time, as an interface between the operating system and the underlying hardware, trusted firmware is a key component to ensure the security of sensitive data.

[0031] refer to Figure 1 , Figure 1 A secure hardware architecture is shown. The secure hardware architecture is a system architecture designed for computing devices, and its purpose is to build a security framework for computing devices to resist various possible attacks. The implementation of the secure hardware architecture can be to divide the hardware and software resources of the processor into a secure (Secure World) and a normal (NormalWorld) world. All operations that require confidentiality are performed in the secure world (such as fingerprint recognition, password processing, data encryption and decryption, and security authentication, etc.), and the remaining operations are performed in the normal world (such as user operating systems, various ordinary applications, etc.). The secure world and the normal world are converted through a mode called monitor mode (Monitor Mode). In the processor architecture, the physical processor core can be virtualized into two cores, a non-secure core (NS Core), which runs the code of the normal world, and another secure core (Secure Core), which runs the code of the secure world. The specific structural type of the secure hardware architecture can refer to the Trust Zone (TZ for short) and SGX (Software Guard Extensions) technology.

[0032] Trusted Firmware (TF) is a security solution that divides the privilege levels during the startup and operation of computing devices. These privilege levels are combined with the secure hardware architecture to jointly ensure the security of the startup process of computing devices. Specifically, trusted firmware technology divides four privilege levels from EL0 (Exception Level 0) to EL3. From EL0 to EL3, the privilege levels increase in sequence. From high LE to low EL through the ERET (Exit from Exception Return) instruction, from low EL to high EL through exception, so that different privilege levels can be strictly distinguished. Among them, EL0, EL1 and EL2 can be divided into NS-ELx (None Secure ELx, x = 0, 1, 2, i.e. normal world ELx) and S-ELx (Secure ELx, x = 0, 1, 2, i.e. secure world ELx), while EL3 only has secure world EL3. In some cases, the firmware required to run during the startup process of the computing device may include BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware and BL33 firmware.

[0033] Among them, BL1 firmware can be called Trusted Boot ROM (Trusted Boot ROM), which is the earliest firmware running in the boot process and is also the firmware stored in the processor ROM (Read-Only Memory). BL1 firmware is not together with the BIOS of the computing device. In some types of trusted firmware technology, BL1 firmware is the root of trust for everything. BL1 firmware can be used to initialize the core hardware of the computing device (such as Trusted SRAM (Trusted Static Random Access Memory), serial port, etc.) and find BL2 firmware. In some cases, BL1 firmware will verify the signature of BL2 firmware. BL1 firmware runs at the EL3 privilege level.

[0034] BL2 firmware can be called Trusted Boot Firmware. BL2 firmware also runs at the EL3 privilege level. The significant difference between BL2 firmware and BL1 firmware is that BL2 firmware can be stored on an external trusted storage device, and its trustworthiness can be based on the verification of BL1 firmware. BL2 firmware will initialize some key security hardware and software frameworks. After the initialization is completed, BL2 firmware will find BL31.

[0035] BL31 firmware can be called EL3 Runtime Firmware. BL31 firmware also runs at the EL3 privilege level and is the last security bastion of the EL3 privilege level. Unlike BL1 firmware and BL2 firmware, BL31 firmware is not a one-time run. It continuously provides security-related services to the normal world (Non-Secure) through SMC (Secure Monitor Call).

[0036] BL32 firmware can include OP-TEE OS (Open Portable Tee Operate System) and trusted applications. OP-TEE OS can refer to the operating system of the trusted execution environment TEE. BL32 firmware runs on S-EL1, and the trusted application on BL32 firmware runs on S-EL0. In some cases, after OP-TEE OS runs, it returns to EL3's BL31 firmware, BL31 firmware finds BL33 firmware, and BL31 firmware can also verify the signature of BL33 firmware.

[0037] BL33 firmware may include firmware (Non-Trusted Firmware) running in the normal world. BL33 firmware may include UEFI (Unified Extensible Firmware Interface) firmware or U-boot (boot loader for embedded fields) for desktops, servers and other fields. It may also include Linux Kernel (Linux kernel) and basic input output system (BIOS) firmware. In the normal world, the execution permissions of EL0, EL1, EL2, and EL3 increase in sequence. Among them, UEFI firmware is configured to run at the EL2 level of the normal world, and OP-TEE is configured to run at the EL1 level of the secure world. When entering the UEFI (BL33) startup, OP-TEE OS has completed the startup, and UEFI and OP-TEE OS can communicate through the secure monitor call (SMC) interface. Therefore, when performing UEFI booting, when verifying the integrity and security of the image file, the normal world can trigger the SMC method to call the corresponding interface of the OP-TEE OS in the secure world to implement certain functions. In this way, the verification process involving the image file can be passed to the secure world for verification, and the verification result can be returned to the normal world.

[0038] Understandably, Figure 1For the purpose of illustrative purposes only, the trusted firmware and related concepts are introduced. In some embodiments, the trusted firmware includes Figure 1 More or less firmware, for example, in some implementations, the trusted firmware may also include firmware such as STMM (Standalone MM, independent management module), or the boot order of the trusted firmware may also vary, which is not exhaustive in this specification.

[0039] Rich Execution Environment (REE, also known as normal execution environment) subsystem, which can be used to run objects such as the operating system (OS) and normal applications (also known as client applications (CA)) of computing devices. REE can run in the normal world.

[0040] Trusted Execution Environment (TEE) subsystem, which can be used to run trusted applications (TA) to meet the application requirements of digital rights management (DRM), mobile payment and sensitive data protection. TEE can run in the secure world.

[0041] In order to implement memory debugging based on trusted firmware, the inventor sets a first application in REE, integrates a TEE driver in the REE operating system, and sets a second application in TEE for specifically processing memory debugging requests. When the memory debugging method is implemented, the first application responds to the memory debugging request carrying test information, calls the TEE driver, and uses the TEE driver to send the memory debugging request to the second application through the SMC through the BL31 firmware, so that the second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information. During the entire debugging process, there is no need to use hardware debugging modules such as JTAG to receive and transmit data, which is conducive to reducing the hardware requirements of the on-chip system and other external hardware for memory debugging; and during the debugging process, there is no need to suspend the operation of the target firmware, and the memory debugging of the running target firmware can be realized. In addition, the entire memory debugging process makes full use of the security features of TEE, uses the second application running in TEE for specific debugging, and does not directly display the debugging data in plain text to other hardware, which is conducive to improving the security of the memory debugging method.

[0042] Based on the above concept, an embodiment of the present specification provides a memory debugging method. The memory debugging method provided by the embodiment of the present specification will be exemplarily described below in conjunction with the accompanying drawings.

[0043] Exemplary Methods

[0044] To be applied to Figure 2 Taking the system on chip in as an example, some embodiments of this specification exemplarily illustrate the memory debugging method, the system on chip includes a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a first application and a REE operating system, the REE operating system includes a TEE driver, and the TEE is used to run a second application and BL31 firmware; the memory debugging method includes:

[0045] S201: The first application calls the TEE driver in response to the memory debugging request carrying the test information, and uses the TEE driver to call the SMC in the security monitoring mode to send the memory debugging request to the second application through the BL31 firmware;

[0046] S202: The second application debugs the memory data of the target firmware based on the test information in response to the memory debugging request.

[0047] The application scenarios of the memory debugging method can refer to Figure 3 In some implementations, the memory debugging requester can configure the corresponding test information through the first application to generate a memory debugging request carrying the test information. The first application can facilitate the memory debugging requester to configure the test information by providing a human-computer interaction interface. After the memory debugging request is generated, the first application responds to the memory debugging request by calling the TEE driver and using the TEE driver to send the memory debugging request to the second application through the BL31 firmware through the SMC, so that the second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information.

[0048] In this embodiment, the first application may be a user application (Client Application, CA), which runs in REE. The first application may be mainly used to receive a memory debugging request sent by a memory debugging requester, and by calling the TEE driver included in the REE operating system (REE OS), the purpose of sending the memory debugging request in the user state to the TEE driver in the kernel state is achieved. The TEE driver sends the memory debugging request to the second application through the BL31 firmware via the SMC. The second application may be a trusted application (Trusted Application, TA) in the second firmware (specifically, the TEE operating system (OP-TEE OS)). The second application responds to the memory debugging request transmitted by the BL31 firmware, and debugs the memory data of the target firmware at runtime in a trusted environment, thereby ensuring the security and reliability of the memory debugging process.

[0049] The runtime may include all resources, environments, and services required during program execution to enable the program to run and complete predetermined functions. In some embodiments, the target firmware may include runtime firmware, that is, the target firmware may refer to the firmware that constitutes the runtime, such as BL31 firmware and BL32 firmware, etc., which continue to work when the system is running.

[0050] During the entire debugging process, the first application provides a software interface for receiving and / or configuring memory debugging requests, without receiving or configuring memory debugging requests through hardware modules, so that the system-on-chip that is not configured with hardware modules such as JTAG can also receive and respond to memory debugging requests to implement memory debugging. In addition, in some embodiments, in order to prevent the first application in user state from directly accessing or calling BL31 firmware and protect BL31 firmware from being affected by malicious user state programs, the TEE driver can run in kernel state, and after the first application sends the memory debugging request to the TEE driver, the TEE driver sends the memory debugging request to the second application through the BL31 firmware through the SMC. The second application tests the memory data of the target firmware based on the test information based on the security mechanisms such as the secure storage of TEE, thereby achieving the purpose of testing the target firmware without suspending the operation of the target firmware, and the security environment based on TEE is conducive to ensuring the security of memory testing and avoiding the situation where the target firmware obtains memory data and is directly exposed to third parties.

[0051] Memory debugging may include both reading and writing. In one implementation, refer to Figure 4 , describing the test of memory reading, the memory debugging request includes a data reading request, the test information includes a target data identifier, the target data identifier is used to indicate the memory data to be read, and the second application responds to the memory debugging request, and based on the test information, debugs the memory data of the target firmware, including:

[0052] The second application, in response to the memory debugging request, uses the SMC to communicate with the target firmware, maps a page table to the memory corresponding to the target firmware, and reads the memory data corresponding to the target data identifier based on the mapping result and the target data identifier;

[0053] The read memory data is encrypted based on the first target public key to obtain a read result, and the read result is returned to the requester of the data read request; the requester of the data read request has a first target private key corresponding to the first target public key, and the first target private key is used to decrypt the read result.

[0054] In this embodiment, in addition to using the TEE mechanism to ensure the security of the memory data reading process based on the second application running in the TEE, the read memory data is also encrypted using the first target public key, avoiding the risk of plaintext memory data being intercepted and leaked by attackers during transmission to the memory debugging requester.

[0055] Still reference Figure 4 , the system on chip also includes a shared memory, and the first application and the second application have read and write permissions for the shared memory;

[0056] The step of returning the read result to the requester of the data read request comprises:

[0057] The second application writes the read result into the shared memory, and the read result written into the shared memory is used to instruct the first application to read the read result from the shared memory and return the read result to the requester of the data read request.

[0058] During the memory debugging process, when the second application obtains the read result, it writes the read result into the shared memory. The read result written into the shared memory can notify the first application to read the read result from the shared memory, and the first application returns the read result to the requester of the memory debugging request. The requester of the memory debugging request uses the first target private key in its possession to decrypt the read result and obtain the plaintext memory data. Returning the read result in this way fully utilizes the shared memory, which is the communication medium between REE and TEE. Only operations such as data writing and data reading need to be performed, which has the advantage of being simple and easy.

[0059] For memory debugging of memory data writing, refer to Figure 5 , the memory debugging request includes a data write request, the test information includes a target address and data to be written encrypted based on a second target public key, and the second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information, including:

[0060] The second application, in response to the memory debugging request, uses the second target private key to decrypt the data to be written, calls the SMC to communicate with the target firmware, maps a page table to the memory corresponding to the target firmware, and writes the decrypted data to be written to the target address based on the mapping result and the target address;

[0061] The second target private key corresponds to the second target public key.

[0062] In this embodiment, the test information includes the data to be written and the target address corresponding to the data to be written. In order to ensure the security of the data to be written during transmission, the data to be written can be encrypted based on the second target public key. After receiving the encrypted data to be written, the second application uses the second target private key to decrypt the data to be written, and writes the decrypted data to be written to the target address based on the target address to achieve the writing of memory data. After the memory data is written, it can be used as follows Figure 4 The memory data reading process shown reads the memory data of the target firmware after the data to be written is written. The memory data read at this time can represent the effect of the data to be written.

[0063] The second target public key and the second target private key can be generated by the second application, and the second target public key is returned to the requester of the memory debugging request, so that the requester of the memory debugging request can use the second target public key to encrypt the data to be written to ensure the security of the data transmission process.

[0064] Correspondingly, the first target public key and the first target private key can be generated by the requester of the memory debugging request, and the first target public key can be transmitted to the second application, so that the second application uses the first target public key to encrypt the reading result, thereby meeting the security requirements during the transmission of the reading result.

[0065] In one embodiment, the TEE driver calls the SMC through the security monitoring mode to send the memory debugging request to the second application through the BL31 firmware, including:

[0066] The TEE driver triggers the secure payload scheduler of the BL31 firmware through the SMC, uses the secure payload scheduler to save the context of the normal world state, registers the function called by the SMC to the running context of the secure world and restores the secure world, returns to the TEE operating system by calling the target function, and the TEE operating system searches for the second application and sends the memory debugging request to the second application.

[0067] In this embodiment, a feasible method is provided for a TEE driver to trigger the BL31 firmware through the SMC and finally send a memory debugging request to a second application. The Secure Payload Dispatcher (SPD) is a key component in the BL31 firmware, which is responsible for ensuring the secure processing of the SMC. For example, when the code in the normal world (such as the TEE driver) executes the SMC instruction, the processor switches to the Monitor mode and enters the secure world. The SPD then performs the following operations: 1. Save the context of the normal world: For example, the SPD saves context information such as the register state and program counter of the normal world. 2. Parse the SMC call parameters: The SPD identifies the called service or function based on the call parameters, registers the function called by the SMC to the running context of the secure world and restores the secure world. 3. Return to the entry of TEE_OS: The SPD returns to the entry of TEE_OS through a specific return target function (such as SMC_RET4), and the TEE operating system searches for the second application and sends the memory debugging request to the second application.

[0068] In one embodiment, in order to ensure the security of the BL31 firmware and prevent the first application in the user state from directly accessing or calling the BL31 firmware, the TEE driver can be set in the kernel state. In this case, the process of the first application calling the TEE driver includes:

[0069] The first application calls the TEE driver by requesting the hypervisor SVC system.

[0070] In this embodiment, the TEE driver is set in the kernel state, and the first application calls the TEE driver through the SVC system. In this way, the TEE driver can have higher permissions and isolation levels, which helps to protect sensitive operations from malicious user-state programs. In addition, the TEE driver in the kernel state has a shorter calling path for calling the BL31 firmware, which reduces potential vulnerabilities and makes it difficult for attackers to indirectly affect the behavior of the BL31 firmware through user-state programs, which is beneficial to ensuring the security of the BL31 firmware.

[0071] A specific implementation of this specification provides a feasible implementation process of a memory debugging method, which specifically includes:

[0072] S1. The memory debugging requester sends a memory debugging request to the first application. The first application responds to the memory debugging request and calls the TEE driver. The TEE driver parses the passed parameters and reassembles the data according to the requirements of the SMC to obtain a memory debugging request that meets the SMC format requirements, triggering an SMC call.

[0073] The secure payload scheduler of S2 and BL31 firmware executes the SMC call to send the memory debug request to the second application;

[0074] S3. If the memory debugging request includes a data read request, the second application responds to the memory debugging request by using the SMC to communicate with the target firmware, maps a page table of the memory corresponding to the target firmware, and reads the memory data corresponding to the target data identifier based on the mapping result and the target data identifier;

[0075] S4, encrypting the read memory data based on the first target public key to obtain a read result, and returning the read result to the requester of the data read request; the requester of the data read request has a first target private key corresponding to the first target public key, and the first target private key is used to decrypt the read result;

[0076] S5. If the memory debugging request includes a data writing request, the second application responds to the memory debugging request, decrypts the data to be written using the second target private key, calls the SMC to communicate with the target firmware, maps a page table of the memory corresponding to the target firmware, and writes the decrypted data to be written to the target address based on the mapping result and the target address.

[0077] Exemplary Devices

[0078] In an exemplary embodiment of the present specification, a system on chip is also provided, including:

[0079] A processor, the processor is used to build a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a first application and a REE operating system, the REE operating system includes a TEE driver, and the TEE is used to run a second application and a BL31 firmware; wherein,

[0080] The processor is configured to: respond to a memory debugging request carrying test information through the first application, call the TEE driver, and use the TEE driver to call the SMC through a secure monitoring mode to send the memory debugging request to the second application through the BL31 firmware;

[0081] The second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information.

[0082] For the specific limitations on the processor executing the memory debugging method, please refer to the relevant limitations on the "memory debugging method" in the previous article, and this manual will not go into details here.

[0083] Another embodiment of the present application further provides a computing device, see Figure 6 As shown, an exemplary embodiment of the present specification also provides a computing device, including: a memory and a processor, the memory stores a computer program, and the processor executes the steps of the memory debugging method according to various embodiments of the present specification described in the above embodiments of the present specification when executing the computer program.

[0084] The internal structure of the computing device can be as follows Figure 6 As shown, the computing device includes a processor, a memory, a network interface and an input device connected through a system bus. Among them, the processor of the computing device is used to provide computing and control capabilities. The memory of the computing device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computing device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, the steps of the memory debugging method according to various embodiments of the present specification described in the above embodiments of the present specification are performed.

[0085] The processor may include a main processor and may also include a baseband chip, a modem, etc.

[0086] The memory stores a program for executing the technical solution of the present invention, and may also store an operating system and other key services. Specifically, the program may include a program code, and the program code includes computer operation instructions. More specifically, the memory may include a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, a disk storage, a flash, and the like.

[0087] The processor may be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the scheme of the present invention. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0088] The input device may include a device for receiving data and information input by a user, such as a keyboard, a mouse, a camera, a scanner, a light pen, a voice input device, a touch screen, a pedometer, or a gravity sensor.

[0089] Output devices may include means that allow information to be output to a user, such as display screens, printers, speakers, etc.

[0090] The communication interface may include using any transceiver or the like to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0091] The processor executes the program stored in the memory and calls other devices, which can be used to implement each step of any memory debugging method provided in the above embodiments of the present application.

[0092] The computing device may also include a display component and a voice component. The display component may be a liquid crystal display or an electronic ink display. The input device of the computing device may be a touch layer covered on the display component, or a button, trackball or touchpad provided on the housing of the computing device, or an external keyboard, touchpad or mouse.

[0093] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the scheme of this specification, and does not constitute a limitation on the computing device to which the scheme of this specification is applied. The specific computing device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0094] Exemplary computer program products and storage media

[0095] In addition to the above-mentioned methods and devices, the memory debugging method provided in the embodiments of this specification may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the memory debugging method according to various embodiments of this specification described in the above-mentioned "Exemplary Method" section of this specification.

[0096] The computer program product may be written in any combination of one or more programming languages ​​to write program code for performing the operations of the embodiments of the present specification, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0097] In addition, an embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and the computer program is executed by a processor to execute the steps of the memory debugging method according to various embodiments of the present specification described in the above "Exemplary Method" section of the present specification.

[0098] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this specification can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0099] The technical features of the above embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0100] The above-mentioned embodiments only express several implementation methods of this specification, and the descriptions are relatively specific and detailed, but they cannot be understood as limiting the scope of the solutions provided by the embodiments of this specification. It should be pointed out that for ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of this specification, which all belong to the protection scope of this specification. Therefore, the protection scope of the patent of this specification shall be based on the attached claims.

Claims

1. A memory debugging method, characterized in that: Applied to a system on chip, the system on chip includes a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a first application and a REE operating system, the REE operating system includes a TEE driver, and the TEE is used to run a second application and a BL31 firmware; The memory debugging method comprises: The first application calls the TEE driver in response to the memory debugging request carrying the test information, and uses the TEE driver to call the SMC in a secure monitoring mode to send the memory debugging request to the second application through the BL31 firmware; The second application debugs the memory data of the target firmware based on the test information in response to the memory debugging request.

2. The method according to claim 1, characterized in that The memory debugging request includes a data read request, the test information includes a target data identifier, and the target data identifier is used to indicate the memory data to be read. The second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information, including: The second application, in response to the memory debugging request, uses the SMC to communicate with the target firmware, maps a page table to the memory corresponding to the target firmware, and reads the memory data corresponding to the target data identifier based on the mapping result and the target data identifier; The read memory data is encrypted based on the first target public key to obtain a read result, and the read result is returned to the requester of the data read request; the requester of the data read request has a first target private key corresponding to the first target public key, and the first target private key is used to decrypt the read result.

3. The method according to claim 2, characterized in that The system on chip further includes a shared memory, and the first application and the second application have read and write permissions on the shared memory; The step of returning the read result to the requester of the data read request comprises: The second application writes the read result into the shared memory, and the read result written into the shared memory is used to instruct the first application to read the read result from the shared memory and return the read result to the requester of the data read request.

4. The method according to claim 1, characterized in that: The memory debugging request includes a data writing request, the test information includes a target address and data to be written encrypted based on a second target public key, and the second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information, including: The second application, in response to the memory debugging request, uses the second target private key to decrypt the data to be written, calls the SMC to communicate with the target firmware, maps a page table to the memory corresponding to the target firmware, and writes the decrypted data to be written to the target address based on the mapping result and the target address; The second target private key corresponds to the second target public key.

5. The method according to claim 4, characterized in that The second target private key and the second target public key are generated by the second application.

6. The method according to claim 1, characterized in that The TEE driver calls the SMC in a secure monitoring mode to send the memory debugging request to the second application through the BL31 firmware, including: The TEE driver triggers the secure payload scheduler of the BL31 firmware through the SMC, uses the secure payload scheduler to save the context of the normal world state, registers the function called by the SMC to the running context of the secure world and restores the secure world, returns to the TEE operating system by calling the target function, and the TEE operating system searches for the second application and sends the memory debugging request to the second application.

7. The method according to any one of claims 1 to 6, characterized in that: The process of the first application calling the TEE driver includes: The first application calls the TEE driver by requesting the hypervisor SVC system.

8. A system on chip, characterized in that: include: A processor, the processor is used to build a rich execution environment subsystem REE and a trusted execution environment subsystem TEE, the REE is used to run a first application and a REE operating system, the REE operating system includes a TEE driver, and the TEE is used to run a second application and a BL31 firmware; wherein, The processor is configured to: respond to a memory debugging request carrying test information through the first application, call the TEE driver, and use the TEE driver to call the SMC through a secure monitoring mode to send the memory debugging request to the second application through the BL31 firmware; The second application responds to the memory debugging request and debugs the memory data of the target firmware based on the test information.

9. A computing device, characterized in that The invention comprises a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the memory debugging method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the memory debugging method according to any one of claims 1 to 7 is implemented.

Images