Processor debugging method, system, and system-on-chip

Abstract

The present application provides a debugging method, system, and system-on-chip for a processor, wherein the method comprises: obtaining a debugging request; obtaining a debugging enable signal in response to the debugging request; determining an executable domain that is allowed to enter debugging mode according to the debugging enable signal; and controlling the processor to enter superuser mode to debug the executable domain that is allowed to enter debugging mode. By controlling the processor to enter superuser mode to debug the executable domain, rather than using machine mode to regulate the executable domain, the security of the debugging process can be effectively improved. By setting a debugging enable signal to indicate which executable domains need to be debugged, the need for independent debugging of a single executable domain can be achieved, thereby meeting the need for debugging isolation in secure debugging.

Description

Technical Field

[0001] The present application belongs to the field of semiconductor chip technology, and in particular relates to a debugging method, system, and system-on-chip for a processor. Background Art

[0002] To address security threats faced by smart devices and IoT devices, terminal chipsets typically provide a trusted execution environment (TEE) to prevent system programs, terminal parameters, security data, and user data within the chip from being tampered with or illegally accessed. To this end, hardware-provided isolation mechanisms, coordinated by underlying software, can be used to create multiple independent virtual execution domains (Zones). This ensures that the hardware and software resources within each Zone are protected from unauthorized access by other Zones.

[0003] However, the existing RISC-V-based debugging architecture cannot support independent debugging of zones. This is because, after entering debugging mode, the processor directly enters machine mode, which has the highest execution privileges. Because machine mode has the highest execution privileges, debuggers in machine mode can bypass zone isolation restrictions and access any system resource. Peripheral debugging modules can obtain the operating status and sensitive data of processors in other zones through the debug interface, and can even manipulate the processor to run malicious code with high privileges through the debug interface, posing a security threat to the entire system.

[0004] There is currently no effective solution to the existing problem of how to perform security debugging on different zones. Summary of the Invention

[0005] The purpose of this application is to provide a processor debugging method, system, and system-on-chip that can achieve secure debugging of executable domains.

[0006] This application provides a processor debugging method, system, and system-on-chip, which are implemented as follows:

[0007] A processor debugging method, comprising:

[0008] Get debug request;

[0009] In response to the debugging request, obtaining a debugging enable signal;

[0010] Determining an executable domain that is allowed to enter a debug mode according to the debug enable signal;

[0011] Control the processor to enter the supervisor mode and debug the executable domain that is allowed to enter the debug mode.

[0012] A processor debugging system, comprising:

[0013] The processor virtualizes multiple independent executable domains;

[0014] Debug authentication module, used to set debug enable signal;

[0015] The debugging module is used to receive a debugging request from a debugger, and in response to the debugging request, obtain a debugging enable signal, determine the executable domains allowed to enter the debugging mode according to the debugging enable signal, control the processor to enter the supervisor mode, and debug the executable domains allowed to enter the debugging mode.

[0016] A system-on-chip includes the above-mentioned processor debugging system.

[0017] A computer-readable storage medium stores computer instructions, which implement the steps of the above method when executed.

[0018] The processor debugging method provided in this application debugs the executable domain by controlling the processor to enter the supervisor mode, rather than using the machine mode to regulate the executable domain, thereby effectively improving the security of the debugging process. By setting the debug enable signal to indicate which executable domains need to be debugged, the need for independent debugging of a single executable domain can be realized, thereby meeting the need for debugging isolation in secure debugging. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 This is a method flow chart of an embodiment of a processor debugging method provided by the present application;

[0021] Figure 2 This is an architectural diagram of an embodiment of a processor debugging system provided by this application;

[0022] Figure 3 This is a schematic diagram of the architecture of the signal line setting provided by this application. DETAILED DESCRIPTION

[0023] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0024] To meet the isolation requirements of a Trusted Execution Environment (TEE), multiple virtual execution domains (Zones) are created within the processor architecture. Each Zone can independently run its own operating system and applications based on that operating system. The processor can switch between zones as needed. When switching to a zone, that zone will occupy an entire physical core in real time. Zone switching is performed by Trusted Firmware (TF) running in the highest privilege mode (machine mode).

[0025] Virtualizing multiple execution domains allows different operating systems or services to run in independent execution domains. This isolates services from each other and reduces the possibility that a compromise of a service or OS could lead to the compromise of other services. In the ARM architecture, there are only two execution domains at most, meaning all security services must be placed in the same execution domain. A vulnerability in one service could compromise all services. In this example, by virtualizing multiple execution domains, different services can run in separate execution domains, increasing isolation between services and reducing the possibility that a vulnerability in one service could lead to the compromise of other services. For example, services with high security requirements, such as cryptographic services and secure storage, run in independent execution domains, reducing the possibility of sensitive data theft.

[0026] However, in existing processor architectures, after entering debugging, the processor directly enters machine mode, which has the highest execution privileges. Since machine mode has the highest execution privileges, the debugger can bypass the zone isolation restrictions and access any resources on the system in machine mode. In other words, when debugging each executable domain, the security of data and system cannot be guaranteed.

[0027] To this end, in this example, considering that all debugging of the current zone can be controlled, the processor can only enter superuser mode, that is, it can only access debugging resources with the superuser privileges of the current zone. Furthermore, by setting the debug enable signal, a single zone can be debugged independently to meet the debug isolation requirements of secure debugging. For example, the processor can add a debug enable signal line for each zone to control whether the zone can be debugged. If there are 16 zones, then 16 control signal lines can be added to obtain the debug enable signal ZDBGEN[15:0]. For example: when the debug control signal of a zone is pulled high, the processor allows the zone to enter debug mode; when the debug control signal of a zone is pulled low, the processor does not allow the zone to enter debug mode; when multiple debug control signals are pulled high at the same time, the processor allows all zones with debug control signals pulled high to enter debug mode.

[0028] Furthermore, in order to meet the debugging requirement of debugging with the highest authority, a debugging control signal may be added to control whether the processor enters the debugging mode with the highest authority (machine mode).

[0029] Based on this, a processor debugging method is provided in this example. Figure 1 As shown, the following steps may be included:

[0030] Step 101: Get a debugging request;

[0031] During actual implementation, a debugging request may be obtained through the debugging module. The debugging request may be sent by an external debugger. That is, if the external debugger determines that debugging is required, the debugging request may be sent to trigger debugging.

[0032] Step 102: Responding to the debugging request, obtaining a debugging enable signal;

[0033] After receiving the debug request, a debug enable signal can be obtained, which is used to indicate which executable domain needs to be debugged. For example, the debug enable signal can be implemented through a signal line or a message mechanism.

[0034] If a signal line is used for implementation, a signal line can be set for each executable domain, and whether the signal line is pulled high determines whether the corresponding executable domain needs to be debugged. If a message mechanism is used for implementation, a portion of memory can be allocated to store the debug enable signal, and when needed, it can be read from the memory to determine which executable domains need to be debugged. Considering the hardware implementation cost, in actual implementation, if there are a large number of executable domains, then the message mechanism is more appropriate. If there are a small number of executable domains, then the signal line method is used. The specific method to be used can be selected according to actual needs, and this application does not limit this.

[0035] Step 103: Determine the executable domain that is allowed to enter the debug mode according to the debug enable signal;

[0036] For example, in the signal line mode, there are currently 8 executable domains, and the corresponding debug enable signals are shown in Table 1 below:

[0037] Table 1

[0038] Executable domain 0 1 2 3 4 5 6 7 Value 0 / 1 0 / 1 0 / 1 0 / 1 0 / 1 0 / 1 0 / 1 0 / 1

[0039] Assuming that the current debug enable signal is: 00101000, it can be determined that executable domain 2 and executable domain 4 are executable domains that need to be debugged, that is, executable domains that are determined to be allowed to enter the debug mode.

[0040] For each executable domain, a domain identifier (Zone ID) may be added to each executable domain to distinguish between the executable domains.

[0041] Step 104: Control the processor to enter the supervisor mode, and debug the executable domain that is allowed to enter the debug mode.

[0042] Furthermore, in order to meet the debugging requirements of debugging with the highest authority, a debugging control signal can be added to control whether the processor enters the debugging mode with the highest authority (machine mode). To this end, after obtaining the debugging request, the debugging control signal can be obtained first and judged to determine whether debugging in machine mode is required. If necessary, debugging is performed directly in machine mode. If not, the debugging enable signal is obtained to determine which control domains need to be debugged in super user mode. That is, in response to the debugging request, the debugging control signal is obtained; according to the debugging control signal, it is determined whether the processor needs to enter the debugging state in machine mode; if it is determined that the processor needs to enter the debugging state in machine mode, the processor is controlled to enter the debugging state in machine mode; if it is determined that the processor does not need to enter the debugging state in machine mode but the processor is currently in machine mode, the processor is controlled to enter the debugging waiting state.

[0043] Specifically, the machine mode can be abbreviated as M mode, which is the highest privilege mode that can be executed by HART (hardware thread) under the reduced instruction set architecture.

[0044] A processor may be in machine mode not only during debugging but also during normal processing. Therefore, if it is determined that the processor does not need to enter a debugging state in machine mode, and if the processor is currently in machine mode, it is necessary to wait until the processor is no longer in machine mode before triggering debugging. Accordingly, if it is determined that the processor does not need to enter a debugging state in machine mode, and the processor is not currently in machine mode, a debug enable signal can be obtained to determine which executable domains require debugging.

[0045] Taking into account the simplicity of hardware implementation to reduce complexity, the debug enable signal can be represented by a signal line established between the debug authentication module and the processor, where one signal line can correspond to one executable domain. When the level of the signal line of the target executable domain is pulled high, it indicates that the target executable domain is allowed to enter the debug mode. Alternatively, the ID of the executable domain can be represented by the signal line, and the executable domain that needs to be debugged can be determined based on the ID.

[0046] When there are a large number of executable domains, using signal lines would result in excessively high hardware costs. Therefore, a message mechanism can be used to store the debug enable signal in memory, allowing other modules to access the memory to obtain data. Specifically, obtaining the debug enable signal may include retrieving the debug enable signal from memory, where the debug enable signal is stored in memory via a message mechanism.

[0047] The above-mentioned processor can be a processor that provides the ability to implement a trusted execution environment based on the RISC-V processor architecture. If processors of other architectures are divided into multiple executable domains and require isolated debugging, the method in this example is also applicable.

[0048] Under the coordinated management of trusted firmware (TF) running in machine mode, the processor virtualizes multiple completely independent executable domains. The hardware and software resources within each zone must be protected from unauthorized access by other zones. These resources may include execution, memory, peripherals, and I / O. Processor resources include cache, TLB (Translation Lookaside Buffer), interrupts, and access and execution permissions. After being isolated and managed by the system through PMP (Physical Memory Protection in the processor architecture), the processor will run in different zones in a time-sharing manner. This, in conjunction with other SoC (System on Chip) protection mechanisms (such as IOPMP (Input / Output Physical Memory Protection)), forms a secure system based on collaborative hardware and software.

[0049] In order to implement the above-mentioned processor debugging method, a processor debugging system is also provided in this example. Figure 2 As shown, it may include: a processor 201, which virtually generates multiple independent executable domains; a debug authentication module 202, which is used to set a debug enable signal; a debug module 203, which is used to receive a debug request from a debugger and, in response to the debug request, obtain a debug enable signal, determine an executable domain that is allowed to enter debug mode based on the debug enable signal, control the processor to enter supervisor mode, and debug the executable domain that is allowed to enter debug mode.

[0050] The debug authentication module can be connected to the processor via multiple signal lines, with one signal line corresponding to each executable domain. When the level of the signal line of the target executable domain is raised, it indicates that the target executable domain is allowed to enter debug mode. The debug authentication module can also be used to set a debug enable signal via a signal line between the processor and the debug authentication module. The debug enable signal is used to indicate whether the processor needs to enter a debug state in machine mode. For details on how to perform debugging, please refer to the description of the processor debugging method above and will not be repeated here.

[0051] The above-mentioned processor can be a processor based on RISC-V (reduced instruction set) architecture, for example, it can be a processor of the Xuantie series (for example: Xuantie C908 processor), or other series of processors designed based on the RISC-V architecture.

[0052] The above-mentioned processor debugging system may be provided on a system-on-chip. The above-mentioned method and processor debugging system are particularly suitable for selective debugging of multiple (more than three) zones.

[0053] The above method and system are described below in conjunction with a specific embodiment. However, it is worth noting that this specific embodiment is only for better illustrating the present application and does not constitute an improper limitation on the present application.

[0054] Take the Xuantie C908 processor, for example. Based on the RISC-V processor architecture, the Xuantie C908 provides the capability to implement a trusted execution environment (TEE). Through hardware-based isolation mechanisms and coordinated by underlying software, the Xuantie C908 virtualizes multiple independent execution environments, ensuring that the hardware and software resources within each zone are protected from unauthorized access by other zones. These resources include execution, memory, peripherals, and I / O. The Xuantie C908 processor offers a security extension based on the RISC-V standard architecture. Hardware resources are managed and coordinated by Trusted Firmware (TF) running in machine mode, allowing the processor to virtualize multiple, completely independent executable domains. After being isolated and managed by the PMP (Personalized Partitioning Management) (PMP), the Xuantie C908 processor's resources (such as cache, TLB, interrupts, and access and execution permissions) are time-shared within different zones. This, combined with other SoC protection mechanisms (such as IOPMP), creates a secure system based on collaborative hardware and software collaboration.

[0055] However, the existing RISC-V debugging architecture cannot support independent debugging of zones. Upon receiving a debug request, the debug module (DM) controls the RISC-V processor to enter the debug state of machine mode. Once in debug mode, the debugger can continue to send commands to the debug module, instructing the processor to execute any instructions sent by the debugger. Because the processor operates in the most privileged machine mode after entering debug mode, an external debugger can control the processor's access to any system resources, thereby bypassing the zone's security.

[0056] To support independent debugging of zones by creating multiple virtual zones after adding security extensions to the RISC-V debug architecture, a control signal can be introduced to separate debug permissions. For example, a zone debug enable signal (ZDBGEN[15:0]) can be added.

[0057] Assuming that the processor virtualizes 16 independent zones, the processor can Figure 3 As shown, a new signal line (0, 1, 2...15) is added to each Zone to control whether the Zone is debuggable. The debug enable signal can be expressed as ZDBGEN[15:0]. That is, there are a total of 16 Zones, so 16 new control signal lines are added.

[0058] When a zone's debug enable signal is pulled high, the processor allows that zone to enter debug mode. When a zone's debug enable signal is pulled low, the processor prevents that zone from entering debug mode. When multiple debug enable signals are pulled high simultaneously, the processor allows all zones with high debug enable signals to enter debug mode. For debugging of the current zone, the processor must enter supervisor mode, meaning that debugging resources can only be accessed with the supervisor privileges of the current zone.

[0059] In order to meet the debugging needs of debugging with the highest authority, Xuantie C908 has added the MDBGEN debugging control signal to control whether the processor enters the debugging mode with the highest authority (machine mode).

[0060] like Figure 3 As shown,

[0061] When the processor receives a debug request from the Debug Module (DM), it performs the following additional checks based on the debug permissions controlled by the Debug Auth Module (DAM):

[0062] When MDBGEN=1, the processor enters M-mode debugging mode;

[0063] When MDBGEN=0:

[0064] If the processor is running in machine mode, the processor will enter the debug wait state and will not respond to debug requests;

[0065] If the processor is running in non-machine mode and the debug control signal ZDBGEN of the current zone is 1, the processor will enter the supervisor mode;

[0066] If the processor runs in non-machine mode and the debug control signal ZDBGEN of the current zone is 0, the processor will enter the debug wait state and will not respond to debug requests.

[0067] That is, the debugging permission can be controlled by setting up a debugging authentication module, that is, the MDBGEN and ZDBGEN[15:0] signals are managed to be output to the processor through the debugging authentication module. The debugging authentication module can be customized when implemented, for example, by the system-level chip manufacturer during hardware design.

[0068] The number of bits of the debug control signal ZDBGEN can be determined according to the number of zones. During implementation, the number of bits of the debug control signal ZDBGEN can be implemented by the system-on-chip manufacturer during hardware design.

[0069] Table 2 shows the correspondence between the Zone ID bit width, the number of zones, and the number of ZDBGEN signal lines:

[0070] Table 2

[0071]

[0072] In actual implementation, ZDGBEN can be encoded using a one-hot method, that is, each signal line represents an enable bit, so 16 signal lines are set for 16 zones. ZDGBEN can also be encoded using a multi-hot method, for example, to transmit the zone ID. If ZDBGEN transmits the zone ID, the number of signal lines can be reduced. In the case of 16 zones, the processor decodes the ZID[3:0] signal. That is, based on the received signal, it identifies the corresponding zone ID to determine which zone needs to be debugged.

[0073] For the secure control side (Secure Server), authentication and identification can be performed through login methods such as username / password. After authentication and identification, the MDBGEN and ZDBGEN[15:0] signals can be managed. For example, MDBGEN can be set to 0 / 1, and which bits of ZDBGEN[15:0] are set to 0 and which bits are set to 1, thereby achieving control over the debugging process.

[0074] That is, by controlling the processor to enter the supervisor mode to debug the executable domain, rather than using the machine mode to regulate the executable domain, the security of the debugging process can be effectively improved. By setting the debug enable signal to indicate which executable domains need to be debugged, the need for independent debugging of a single executable domain can be realized, thereby meeting the need for debugging isolation in secure debugging.

[0075] The embodiments of the present application also provide a specific implementation of an electronic device capable of implementing all steps in the processor debugging method in the above embodiments. The electronic device specifically includes the following: a processor, a memory, a communication interface, and a bus; wherein the processor, the memory, and the communication interface communicate with each other via the bus; the processor is configured to call a computer program in the memory, and when the processor executes the computer program, all steps in the processor debugging method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0076] Step 1: Get a debug request;

[0077] Step 2: In response to the debugging request, obtaining a debugging enable signal;

[0078] Step 3: Determine the executable domain that is allowed to enter the debug mode according to the debug enable signal;

[0079] Step 4: Control the processor to enter the supervisor mode and debug the executable domain that is allowed to enter the debug mode.

[0080] From the above description, it can be seen that the embodiment of the present application debugs the executable domain by controlling the processor to enter the supervisor mode, rather than using the machine mode to regulate the executable domain, thereby effectively improving the security of the debugging process. By setting the debug enable signal to indicate which executable domains need to be debugged, the need for independent debugging of a single executable domain can be realized, thereby meeting the need for debugging isolation in secure debugging.

[0081] Embodiments of the present application also provide a computer-readable storage medium capable of implementing all steps of the processor debugging method in the above embodiment. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the computer program implements all steps of the processor debugging method in the above embodiment. For example, when the processor executes the computer program, the following steps are implemented:

[0082] Step 1: Get a debug request;

[0083] Step 2: In response to the debugging request, obtaining a debugging enable signal;

[0084] Step 3: Determine the executable domain that is allowed to enter the debug mode according to the debug enable signal;

[0085] Step 4: Control the processor to enter the supervisor mode and debug the executable domain that is allowed to enter the debug mode.

[0086] From the above description, it can be seen that the embodiment of the present application debugs the executable domain by controlling the processor to enter the supervisor mode, rather than using the machine mode to regulate the executable domain, thereby effectively improving the security of the debugging process. By setting the debug enable signal to indicate which executable domains need to be debugged, the need for independent debugging of a single executable domain can be realized, thereby meeting the need for debugging isolation in secure debugging.

[0087] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other. Each embodiment focuses on the differences between the other embodiments. In particular, the hardware + program embodiments are generally similar to the method embodiments, so their description is relatively simple. For relevant portions, refer to the description of the method embodiments.

[0088] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0089] Although the present application provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative work. The order of steps listed in the embodiments is only one way of executing the steps among many steps and does not represent the only execution order. When the actual device or client product is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, in a parallel processor or multi-threaded processing environment).

[0090] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0091] Although the present specification embodiment provides the method operation steps as described in the embodiment or flow chart, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiment is only one way in the order of execution of many steps and does not represent a unique execution order. When the device or terminal product in practice is executed, it can be performed in sequence or in parallel according to the method shown in the embodiment or the accompanying drawings (such as a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements not only include those elements, but also include other elements not clearly listed, or also include elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements.

[0092] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing the embodiments of this specification, the functions of each module can be implemented in the same or multiple software and / or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0093] Those skilled in the art will also appreciate that, in addition to implementing the controller in pure computer-readable program code, it is entirely possible to implement the same functionality by logically programming the method steps in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, embedded microcontrollers, and the like. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered structures within the hardware component. Alternatively, the devices for implementing various functions can be considered both software modules implementing the method and structures within the hardware component.

[0094] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0095] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0096] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0097] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0098] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0099] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0100] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0101] Embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. Embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0102] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the embodiments in this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0103] The above description is merely an example of the embodiments of this specification and is not intended to limit the embodiments of this specification. For those skilled in the art, various modifications and variations of the embodiments of this specification are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of this specification shall be included within the scope of the claims of the embodiments of this specification.

Claims

1. A method for debugging a processor, characterized in that: include: Get debug request; In response to the debugging request, obtaining a debugging enable signal; Determining an executable domain that is allowed to enter a debug mode according to the debug enable signal; Control the processor to enter the supervisor mode and debug the executable domain that is allowed to enter the debug mode; Among them, based on the processor architecture, multiple executable domains are virtualized, and the processor adds a debug enable signal line for each zone to control whether the executable domain is debuggable.

2. The method according to claim 1, characterized in that After getting the debug request, also include: In response to the debugging request, obtaining a debugging control signal; Determining whether the processor needs to enter a debugging state in machine mode according to the debugging control signal; When it is determined that the processor needs to enter the debugging state in the machine mode, controlling the processor to enter the debugging state in the machine mode; When it is determined that the processor is not required to enter the debug state in the machine mode but the processor is currently in the machine mode, the processor is controlled to enter the debug wait state.

3. The method according to claim 2, characterized in that In response to the debugging request, obtaining a debugging enable signal includes: When it is determined that the processor is not required to enter the debug state in the machine mode and the processor is not currently in the machine mode, a debug enable signal is obtained.

4. The method according to claim 1, wherein The debug enable signal is represented by a signal line established between the debug authentication module and the processor.

5. The method according to claim 4, characterized in that One signal line corresponds to one executable domain. When the level of the signal line of the target executable domain is pulled high, it indicates that the target executable domain is allowed to enter the debug mode.

6. The method according to claim 1, wherein Obtaining debug enable signals includes: The debug enable signal is retrieved from the memory, and the debug enable signal is stored in the memory in the form of a message mechanism.

7. The method according to any one of claims 1 to 6, characterized in that The processor is a processor that provides the ability to implement a trusted execution environment based on the RISC-V processor architecture.

8. A processor debugging system, characterized in that: include: The processor virtualizes multiple independent executable domains; Debug authentication module, used to set debug enable signal; a debugging module configured to receive a debugging request from a debugger, obtain a debugging enable signal in response to the debugging request, determine an executable domain that is allowed to enter debugging mode based on the debugging enable signal, control the processor to enter supervisor mode, and debug the executable domain that is allowed to enter debugging mode; Among them, based on the processor architecture, multiple executable domains are virtualized, and the processor adds a debug enable signal line for each zone to control whether the executable domain is debuggable.

9. The system according to claim 8, characterized in that The debugging authentication module is connected to the processor via a plurality of signal lines, one signal line corresponds to one executable domain, and when the level of the signal line of the target executable domain is pulled high, it indicates that the target executable domain is allowed to enter the debugging mode.

10. The system according to claim 8, wherein: The debugging authentication module is further used to set a debugging enable signal via a signal line between the module and the processor. The debugging enable signal is used to indicate whether the processor needs to enter a debugging state in a machine mode.

11. The system according to claim 8, wherein: The processor is a processor based on a reduced architecture instruction set.

12. A system-on-chip comprising a debugging system for the processor according to any one of claims 8 to 11.

13. A computer-readable storage medium having computer instructions stored thereon, wherein the instructions, when executed, implement the steps of the method according to any one of claims 1 to 7.

Images