CN116522413A

CN116522413A - Method for operating computer system, processor, electronic device, and storage medium

Info

Publication number: CN116522413A
Application number: CN202310442630.3A
Authority: CN
Inventors: 谢俊
Original assignee: Beijing Eswin Computing Technology Co Ltd
Current assignee: Beijing Eswin Computing Technology Co Ltd
Priority date: 2023-04-23
Filing date: 2023-04-23
Publication date: 2023-08-01

Abstract

A method of operation of a computer system, a processor, an electronic device, and a storage medium. The operation method comprises the following steps: providing a plurality of sub-modes having different privilege levels in a machine mode of a computer system; and allowing at least one of the plurality of execution contexts to run in the plurality of sub-modes, respectively. The operation method expands the original machine mode into a plurality of sub-modes with different privilege levels to provide a trusted execution environment, thereby effectively reducing the attack surface and improving the security of the system.

Description

Method for operating computer system, processor, electronic device, and storage medium

Technical Field

Embodiments of the invention relate to a method of operating a computer system, a processor, an electronic device, and a storage medium.

Background

The RISC-V architecture is a modular instruction set architecture defining several optional standard extensions that can provide highly customizable features. RISC-V supports different privilege levels and privilege modes. The privileged modes of RISC-V generally include User Mode (User Mode), supervisor Mode (Supervisor Mode), and Machine Mode (Machine Mode). In markets such as MCU, AIoT, etc., only machine mode or a combination of machine mode and user mode will typically be used, and typically only one execution context such as real-time operating system (Real Time Operating System, RTOS) needs to be run in machine mode, but in products with higher security requirements, it may also be necessary to additionally run one or more other execution contexts in machine mode, but RISC-V architecture existing standards do not provide isolation mechanisms between multiple execution contexts in machine mode, and security vulnerabilities exist that interfere with each other.

Disclosure of Invention

At least one embodiment of the present disclosure provides a method of operating a computer system, comprising: providing a plurality of sub-modes having different privilege levels in a machine mode of the computer system; and allowing at least one of the plurality of execution contexts to run in the plurality of sub-modes, respectively.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the plurality of sub-modes includes a secure supervisory mode and a managed machine mode, the secure supervisory mode having a privilege level greater than a privilege level of the managed machine mode.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the plurality of execution contexts includes a first execution context and a second execution context, the method of operating further comprising: running the first execution context in the secure supervisory mode and the second execution context in the managed machine mode.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the plurality of execution contexts further includes one or more other execution contexts, the method of operating further includes: at least one of the one or more other execution contexts is run in at least one of the secure supervisory mode and the managed machine mode.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the first execution context is a secure supervisory execution context and the second execution context is a real-time operating system context.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the one or more other execution contexts include a secure operating system context or secure firmware.

For example, in an operation method of a computer system provided in at least one embodiment of the present disclosure, the operation method further includes: when an exception or interrupt occurs in an object sub-mode of the plurality of sub-modes, which results in the execution of the currently executed object execution context being interrupted, the exception or interrupt is processed and then returned to the previous object sub-mode.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the plurality of sub-modes includes a secure supervisory mode and a managed machine mode, the secure supervisory mode having a privilege level greater than a privilege level of the managed machine mode, the method of operating further comprising: and before returning to the previous object sub-mode, entering the safety supervision mode to process the exception or the interrupt.

For example, in an operation method of a computer system provided in at least one embodiment of the present disclosure, the operation method further includes: the previous object sub-pattern is represented using a value of a first parameter for returning to the previous object sub-pattern according to the value of the first parameter after the exception or the interrupt is handled.

For example, in an operation method of a computer system provided in at least one embodiment of the present disclosure, the operation method further includes: a user mode is provided in the computer system, wherein the user mode has a privilege level less than a privilege level of the machine mode, the user mode allowing for running at least one application executable in at least one of the plurality of execution contexts.

For example, in an operation method of a computer system provided in at least one embodiment of the present disclosure, the operation method further includes: when an exception or interrupt occurs in object mode resulting in the execution of the currently executing object context being interrupted, the execution returns to the previous object mode after the exception or interrupt is handled.

For example, in an operation method of a computer system provided in at least one embodiment of the present disclosure, the operation method further includes: and before returning to the previous object mode, entering the safety supervision mode to process the exception or the interrupt, wherein the object mode is the user mode or the machine mode.

For example, in an operation method of a computer system provided in at least one embodiment of the present disclosure, the operation method further includes: the previous object pattern is represented using at least one of a value of a first parameter and a value of a second parameter to return to the previous object pattern according to at least one of the value of the first parameter and the value of the second parameter after the exception or the interrupt is handled.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, returning to the previous object mode according to at least one of the value of the first parameter and the value of the second parameter includes: returning to the user mode after the exception or the interrupt is handled when the value of the second parameter corresponds to the user mode; returning to the secure supervisory mode after the exception or interrupt is handled when the value of the second parameter corresponds to the machine mode and the value of the first parameter corresponds to the secure supervisory mode; or returning to the managed machine mode after the exception or the interrupt is handled when the value of the second parameter corresponds to the machine mode and the value of the first parameter corresponds to the managed machine mode.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the computer system operates in the secure supervisory mode when the computer system is powered on.

For example, in a method of operating a computer system provided by at least one embodiment of the present disclosure, the computer system is based on a RISC-V instruction set.

At least one embodiment of the present disclosure also provides a processor comprising: a processor core; a safety supervision unit configured to: providing a plurality of sub-modes having different privilege levels in a machine mode of a computer system; and allowing at least one of the plurality of execution contexts to run in the plurality of sub-modes, respectively.

At least one embodiment of the present disclosure also provides an electronic device including: a memory configured to store computer-executable instructions; and a processor configured to execute the computer-executable instructions, wherein the computer-executable instructions, when executed by the processor, implement the method as in any of the embodiments above.

At least one embodiment of the present disclosure also provides a non-transitory storage medium that non-transitory stores computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method of any of the embodiments above.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings of the embodiments will be briefly described below, and it is apparent that the drawings in the following description relate only to some embodiments of the present disclosure, not to limit the present disclosure.

Fig. 1 is a flowchart of a method of operating a computer system according to some embodiments of the present disclosure.

Fig. 2 is a schematic diagram of a trusted execution environment provided in some embodiments of the present disclosure.

FIG. 3 is a schematic diagram of another trusted execution environment provided by some embodiments of the present disclosure.

Fig. 4 is a flow chart of transitioning between different privilege modes provided by some embodiments of the present disclosure.

Fig. 5 is a state machine diagram of a computer system transitioning between a secure supervisory mode, a managed machine mode, and a debug mode provided by some embodiments of the present disclosure.

Fig. 6 is a state machine diagram of a computer system transitioning between a secure supervisory mode, a managed machine mode, a user mode, and a debug mode provided by some embodiments of the present disclosure.

Fig. 7 is a schematic diagram of a processor provided in some embodiments of the present disclosure.

Fig. 8 is a schematic diagram of an electronic device according to some embodiments of the present disclosure.

Fig. 9 is a schematic diagram of a non-transitory storage medium provided by some embodiments of the present disclosure.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present disclosure more apparent, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present disclosure. It will be apparent that the described embodiments are some, but not all, of the embodiments of the present disclosure. All other embodiments, which can be made by one of ordinary skill in the art without the need for inventive faculty, are within the scope of the present disclosure, based on the described embodiments of the present disclosure.

Unless defined otherwise, technical or scientific terms used in this disclosure should be given the ordinary meaning as understood by one of ordinary skill in the art to which this disclosure belongs. The terms "first," "second," and the like, as used in this disclosure, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" or "comprises", and the like, is intended to mean that elements or items preceding the word are included in the listed elements or items following the word, and equivalents thereof, without excluding other elements or items. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "upper", "lower", "left", "right", etc. are used merely to indicate relative positional relationships, which may also be changed when the absolute position of the object to be described is changed.

In order to keep the following description of the embodiments of the present disclosure clear and concise, the present disclosure omits a detailed description of some known functions and known components.

The RISC-V architecture is an open-source instruction set architecture (Instruction Set Architecture, ISA) that aims to provide a standardized instruction set that can be implemented on a variety of chips and hardware platforms. The design of the RISC-V instruction set is intended to be kept as simple as possible, minimizing the number and complexity of instructions, to facilitate hardware implementation and compiler optimization. The RISC-V design has expandability, and can be subjected to custom expansion according to different application requirements, such as adding custom instructions, adding new hardware characteristics and the like. Due to its scalability, RISC-V can be easily implemented on a variety of different hardware platforms, and can be portable among different operating systems and programming languages.

At the same time, as described above, the RISC-V architecture is also a modular instruction set architecture defining several optional standard extensions that can provide highly customizable features. RISC-V supports different privilege levels and privilege modes. The privileged modes of RISC-V generally include User Mode (User Mode), supervisor Mode (Supervisor Mode), and Machine Mode (Machine Mode).

The user mode is the most basic privilege mode, and programs (or execution contexts) in the user mode can access user-level registers, memory, and device resources, but cannot directly access any privilege-level registers or resources. The supervisor mode, also referred to as supervisor mode, has a higher privilege level than the user mode, and programs in the supervisor mode have access to user-level and supervisor-level registers, memory, and device resources, but cannot directly access any machine-level registers or resources. The supervisor mode may be used for implementation of the operating system kernel for low-level system management operations. The machine mode is the highest privilege level and programs in machine mode have access to all registers and resources, including machine-level registers, memory, and device resources. Machine mode is typically used by a boot program or operating system kernel to configure and manage the entire system.

In addition to the above three modes, a fourth privilege Mode may be further defined in the RISC-V architecture, such as a Hypervisor Mode (Hypervisor Mode), which has a different privilege level than the three modes. For example, the privilege of the supervisor mode is equal to greater than the supervisor mode and less than the machine mode.

In the MCU and AIoT markets, either machine-only mode or a combination of machine and user modes is typically employed. Typically only one execution context needs to be run in machine mode, e.g. a real-time operating system, but in products with higher security requirements, additional execution context or contexts may need to be run in machine mode. However, the current execution context (e.g., real-time operating system (RTOS)) has been run in the highest privilege mode (i.e., machine mode), and none of the higher privilege modes can be used to run other execution contexts. RISC-V architecture existing standards do not provide isolation mechanisms between multiple execution contexts in machine mode, and there are security vulnerabilities that interfere with each other.

At least one embodiment of the present disclosure provides a method of operating a computer system, and a processor, an electronic device, and a storage medium corresponding thereto, the method of operating comprising: providing a plurality of sub-modes having different privilege levels in a machine mode of a computer system; and allowing at least one of the plurality of execution contexts to run in the plurality of sub-modes, respectively.

In the above embodiment of the present disclosure, an extension (e.g., hardware extension) is performed in a machine mode of a RISC-V architecture, so that the machine mode has multiple sub-modes with different privilege levels, and these sub-modes provide a trusted execution environment, and an isolation mechanism is provided between execution contexts, so as to avoid or reduce security vulnerabilities that mutually interfere with each other, thereby effectively reducing an attack surface and improving security of a system.

Various embodiments of the present disclosure will be described below in connection with specific examples.

Fig. 1 is a flowchart of a method of operating a computer system according to some embodiments of the present disclosure. As shown in FIG. 1, the method steps of operating a computer system include the following steps S101-S102.

Step S101, providing a plurality of sub-modes with different privilege levels in a machine mode of a computer system.

Step S102, allowing at least one of a plurality of execution contexts to run in a plurality of sub-modes, respectively.

For example, in one embodiment of the present disclosure, a computer system includes a processor and an operating system, application programs, etc., that are executed by the processor. The computer system includes a user mode, a supervisor mode, and a machine mode, and the computer system extends the machine mode to a plurality of sub-modes having different privilege levels.

For example, in one embodiment of the present disclosure, a computer system may be implemented based on a different instruction set architecture. For example, a computer system may select different instruction set architecture implementations according to different requirements and application scenarios. For example, the computer system may be a RISC-V, X, arm, etc., based instruction set architecture, supporting the RISC-V, X86, arm, etc., instruction sets accordingly, as embodiments of the present disclosure are not limited in this regard.

For example, in at least one example, a hardware extension may be added to the processor accordingly, such as by adding a new register in the processor, for extending the machine mode of the computer system to multiple sub-modes with different privilege levels. For example, the newly added register may be a control and status register (Control and Status Register, CSR) which may be a dedicated register independently used to extend the machine mode of the computer system to multiple sub-modes with different privilege levels. For another example, in at least one example, an existing register in a processor may be multiplexed for expanding a machine mode of a computer system into multiple sub-modes with different privilege levels, so long as the original functionality of the multiplexed register itself is not affected.

For example, in one embodiment of the present disclosure, a new CSR register may be stored that indicates whether a computer system (e.g., a processor in a computer system) is currently operating in multiple sub-privileged modes that are extended from machine mode and in which sub-privileged mode that is extended from machine mode.

For example, the mode parameters stored in the added new CSR register may be used to indicate whether the computer system is currently operating in two sub-privileged modes that extend from machine mode. For example, in the embodiments shown in fig. 2 and 3, as will be described below, the machine mode is extended to two sub-privileged modes: a managed machine mode and a secure supervisory mode. The value of the mode parameter stored in the CSR register may be denoted SM. For example, in one embodiment of the present disclosure, sm=1 means that the computer system is currently operating in a secure supervisory mode, sm=0 means that the computer system is currently operating in a managed machine mode, or sm=0 may also mean that the computer system is currently operating in other privileged modes (e.g., user modes) that are not in a secure supervisory mode. The present disclosure is not limited in this regard and, for example, any parameter that can be distinguished may be used to represent the privilege mode in which the computer system is currently running.

In the above embodiment, the machine mode is extended to two privilege modes, a secure supervisory mode and a managed machine mode, the privilege level of the secure supervisory mode being greater than the privilege level of the managed machine mode. For example, the secure supervisor mode has the highest privilege level and programs in the secure supervisor mode have access to, for example, all registers and resources, including machine-level registers, memory, and device resources.

For example, the secure supervisory mode may have the same privilege level and authority as the normal machine mode (i.e., the machine mode before the extension is not made). In another aspect, the managed machine mode has a privilege level that is only less than the privilege level of the secure supervisory mode. For example, the managed machine mode has a privilege level that is greater than all privilege modes except the secure supervisory mode, and the privilege level of the managed machine mode is less than the privilege level of the secure supervisory mode. For example, a program in managed machine mode may access user-level and supervisor-level registers, memory, and device resources, but not directly access any secure supervisor mode level registers or resources. For example, a program in managed machine mode cannot directly access any machine-level registers or resources.

For example, in one embodiment of the present disclosure, based on the extended multiple (e.g., two) new privilege modes (e.g., secure supervisory mode and managed machine mode) described above, respectively allowed execution contexts may be run in different modes, respectively; for example, for the two new privileged mode scenario described above, multiple execution contexts may be allowed to run in the secure supervisory mode and the managed machine mode. For example, at least one of the plurality of execution contexts is run in a secure supervisory mode, and at least another one of the plurality of execution contexts is run in a managed machine mode.

For example, in one embodiment of the present disclosure, the plurality of execution contexts includes a first execution context and a second execution context, and the above-described operation method further includes: the first execution context is run in a secure supervisory mode and the second execution context is run in a managed machine mode.

For example, in one embodiment of the present disclosure, the first execution context may be a secure supervisory execution context (or referred to as a secure supervisory context) and the second execution context may be a real-time operating system execution context (or referred to as a real-time operating system context). For example, the method of operation of the computer system of the present disclosure further comprises: running a secure supervisory execution context in secure supervisory mode and running a real-time operating system execution context in managed machine mode. Embodiments of the present disclosure are not limited to the above examples, and the first execution context and the second execution context may be any suitable execution context, respectively, so long as the first execution context and the second execution context need to operate in different privilege modes, and each may be adapted to the technical solutions of the present disclosure, so as to meet the security requirements of the corresponding products.

For example, in one embodiment of the present disclosure, the plurality of execution contexts also includes one or more other execution contexts. For example, in one embodiment of the present disclosure, the one or more other execution contexts may include a secure operating system execution context (or referred to as a secure operating system context), secure firmware, and the like. Embodiments of the present disclosure are not limited to this example, and the one or more other execution contexts may each be any other suitable execution context.

For example, in one embodiment of the present disclosure, the real-time operating system may be any computer operating system capable of meeting the requirements of real-time. For example, examples of real-time operating system execution contexts may include, but are not limited to VxWorks, QNX, freeRTOS, etc. By way of example, the secure operating system (Security Operating System, secOS) execution context may be any operating system used to secure computer systems and data. For example, secure operating system execution contexts may include, but are not limited to, SELinux, trusted Solaris, openBSD, qubs OS, and the like. As an example, the security firmware (Security Firmware) may be any embedded system software for securing computer hardware devices and protecting computer systems from malicious attacks. For example, the Secure firmware may include, but is not limited to, intel Boot Guard, AMD Secure Boot, HP Sure Start, and the like. As an example, a secure supervisory execution context may be used to manage other execution contexts. For example, the secure supervisory execution context may be used to manage real-time operating system execution context, secure firmware, and the like.

The trusted execution environment may be a security protection mechanism for protecting software and data in a computer system from malware or unauthorized access. In a trusted execution environment, all components such as hardware, an operating system, an application program and the like must pass verification and are authorized to be executed, so that the attack surface can be reduced, and the security of the system is improved.

In the embodiment shown in FIG. 2, the machine mode is extended to two sub-privileged modes: the managed machine mode and the secure supervisory mode, for example, the method of operating the computer system of the present embodiment further includes: at least one of the one or more other execution contexts is run in at least one of a secure supervisory mode and a managed machine mode.

For example, as shown in FIG. 2, the secure supervisory execution context is run in secure supervisory mode, the real-time operating system execution context, the secure operating system execution context, and the secure firmware are run in managed machine mode. For example, the secure supervisory execution context may be used to control or manage the real-time operating system execution context, the secure operating system execution context, and the secure firmware. In other embodiments of the present disclosure, for example, at least one of the secure operating system execution context and the secure firmware may also operate in a secure supervisory mode with the secure supervisory execution context.

It should be noted that, although only the secure supervisory execution context is illustrated in fig. 2 as being run in the secure supervisory mode, the real-time operating system execution context, the secure operating system execution context, and the secure firmware are run in the managed machine mode, embodiments of the present disclosure are not limited thereto. For example, any suitable number of execution contexts may be run in the secure supervisory mode, and any suitable type of execution context may be run in the secure supervisory mode, the number and type of execution contexts run in the secure supervisory mode being well-defined by different products and the security and/or cost requirements of the products, etc. For example, any suitable number of execution contexts may be run in the managed machine mode, and any suitable type of execution context may be run in the managed machine mode, the number and type of execution contexts run in the managed machine mode being entirely dependent on different products and the security requirements of the products.

For example, in one embodiment of the present disclosure, a secure supervisory execution context may be used to enable isolation of resources used between execution contexts controlled or managed by it. For example, a secure supervisory execution context may enable memory isolation used between execution contexts controlled or managed by it by a logical configuration of memory protection mechanisms. For example, the memory protection mechanisms may include MPU (Memory Protection Unit), MMU (Memory Management Unit), physical memory protection (Physical Memory Protection), and the like. As shown in fig. 2, for example, the secure supervisory execution context may be used to control or manage the real-time operating system execution context, the secure operating system execution context, and the secure firmware, and the secure supervisory execution context may enable memory isolation used between the real-time operating system execution context, the secure operating system execution context, and the secure firmware, etc. by reasonably configuring the memory protection mechanism.

The memory protection mechanism may be a hardware mechanism in the processor for protecting physical memory from modification or reading by unauthorized software or access. For example, memory protection mechanisms are implemented by dividing a memory address space into multiple regions (referred to as regions), each of which may have different access rights. The processor compares each memory access request with the region and decides whether to allow access based on the permissions of the region. If the access request does not agree with the region rights, the processor will trigger an exception and block the access. Memory protection mechanisms may be used to protect operating system kernels from user applications, or to protect sensitive data structures from access by malware.

It should be noted that, a horizontal dashed line between the secure supervisory mode and the managed machine mode shown in fig. 2 indicates that the machine mode is extended or divided, and a vertical dashed line between two execution contexts indicates that different execution contexts running in the managed machine mode are resource-isolated. The horizontal and vertical dashed lines in fig. 3 have a meaning similar to that in fig. 2.

In the embodiment shown in FIG. 3, as such, the machine mode is extended to two sub-privileged modes: the managed machine mode and the secure supervisory mode, for example, the method of operation of the present embodiment further includes: a user mode is provided in the computer system, wherein the user mode has a privilege level that is less than a privilege level of the machine mode, the user mode allowing for running of at least one application that is executable in at least one of the plurality of execution contexts.

The embodiment shown in FIG. 3 differs from the embodiment shown in FIG. 2 in that the computer system in FIG. 3 provides a user mode in addition to providing multiple sub-modes with different privilege levels in the machine mode of the computer system and allowing at least one of the multiple execution contexts to be run in each of the multiple sub-modes. For example, the privilege level of the user mode is less than the privilege level of the machine mode, the user mode allowing for running at least one application that is executable in at least one of a real-time operating system execution context, a secure operating system execution context, and secure firmware.

For example, in one embodiment of the present disclosure, one or more applications may be run in a real-time operating system execution context (which may also be referred to as a sub-execution context). For example, as shown in FIG. 3, task 1 and task 2 may be run in a real-time operating system execution context, and task 1 and task 2 may be any executable application (e.g., a process or thread). For example, in the case of running the execution context in only machine mode (including managed machine mode and secure supervisory mode), task 1 and task 2 may run in managed machine mode; in the case of running the execution context in a combination of machine mode (including managed machine mode and secure supervisory mode) and user mode, task 1 and task 2 are not run in the managed machine mode, but only task 1 and task 2 are allowed to run in the user mode with lower privilege level, which can further effectively reduce the attack surface and improve the security of the system.

It should be noted that, although an example in which only two applications (i.e., task 1 and task 2) are running in the real-time operating system execution context is illustrated in fig. 3 of the present disclosure, the present disclosure does not impose any limitation on the number of applications that can be run in the real-time operating system execution context. For example, any other number of applications may be run in the real-time operating system execution context, or there may be no applications running in the real-time operating system execution context.

For example, in one embodiment of the present disclosure, any number of applications (which may also be referred to as sub-execution contexts) may be run in a secure operating system execution context. For example, the secure operating system execution context may be service 1 and service 2, e.g., service 1 and service 2 may be any executable program (e.g., an application program or a system program). For example, in the case of running the execution context in only machine mode (including managed machine mode and secure supervisory mode), service 1 and service 2 may run in managed machine mode; in the case of running the execution context in a combination of machine mode (including managed machine mode and secure supervisory mode) and user mode, service 1 and service 2 are not run in the managed machine mode, but only service 1 and service 2 are allowed to run in the user mode with lower privilege level, which can further effectively reduce the attack surface and improve the security of the system. It should be noted that, although an example in which only two applications or system programs (i.e., service 1 and service 2) are running in the secure operating system execution context is illustrated in fig. 3 of the present disclosure, the present disclosure does not impose any limitation on the number of applications that can be run in the secure operating system execution context. For example, any other number of applications may or may not be running in the secure operating system execution context.

For example, in one embodiment of the present disclosure, any number of programs may be run in the secure firmware. For example, service 3 and service 4 (which may also be referred to as sub-execution contexts) may be in the secure firmware. For example, in the case of running the execution context in only machine mode (including managed machine mode and secure supervisory mode), service 3 and service 4 may run in managed machine mode; in the case of running the execution context in a combination of machine mode (including managed machine mode and secure supervisory mode) and user mode, service 3 and service 4 are not run in the managed machine mode, but service 3 and service 4 are only allowed to run in the user mode with a lower privilege level, which can further effectively reduce the attack surface and improve the security of the system. It should be noted that, although an example in which only two programs (i.e., service 3 and service 4) are run in the secure firmware is shown in fig. 3 of the present disclosure, the present disclosure does not impose any limitation on the number of applications that can be run in the secure firmware. For example, any other number of applications may or may not be running in the secure firmware.

As shown in fig. 4, the transition of the computer system between different privilege modes includes the following steps S201-S202.

In step S201, in response to an abnormality or an interrupt occurring in the object execution context running in the object mode, the abnormality or the interrupt is handled in the safety supervision mode.

Step S202 returns to the previous object mode after the exception or interrupt is handled.

Herein, an "object execution context" refers to an execution context that is currently running, and an "object mode" refers to a privilege mode in which an execution context that is currently running runs before an exception or interrupt occurs (or before the running is interrupted).

For example, referring again to fig. 2, in the case where the execution context is run in only the machine mode (the machine mode includes the managed machine mode and the secure supervisory mode), the object execution context may be any one of the secure supervisory execution context, the real-time operating system execution context, the secure operating system execution context, and the secure firmware shown in fig. 2, and the object mode may be any one of the secure supervisory mode and the managed machine mode. For example, where the execution context is run in only machine mode (including managed machine mode and secure supervisory mode), the object mode may also be referred to as an object sub-mode.

For example, referring again to fig. 3, in the case of running an execution context in a combination of a machine mode (including a managed machine mode and a secure supervisory mode) and a user mode, the object execution context may be any one of the secure supervisory execution context, the real-time operating system execution context, the secure firmware, and the sub-execution context shown in fig. 3 (e.g., task 1, task 2, service 1, service 2, service 3, or service 4 in fig. 3), and the object mode may be any one of the secure supervisory mode, the managed machine mode, and the user mode.

For example, when an interrupt or exception occurs to the currently running object execution context, the processor automatically saves the current privilege mode to a register called MSTATUS. The MSTATUS register is a privileged mode register that may include status bits associated with the current privileged mode and other privileged modes. For example, in the MSTATUS register, the MPP field stores the privilege mode before an interrupt or exception occurs.

For example, MPP (Machine Previous Privilege) can be a 2-bit register field, with the primary purpose of the MPP field being to be used during exception or interrupt handling. When an exception or interrupt occurs, the processor needs to switch to the appropriate privilege level to handle the exception or interrupt, while the previous privilege level needs to be saved in order to revert to the privilege level before the exception or interrupt occurred after handling the exception or interrupt.

For example, the MPP field contains four values of 00, 01, 10, and 11. When the MPP field is 00 (or may be referred to as mpp=0), it indicates that the previous privilege level is the user mode; when the MPP field is 01 (or may be referred to as mpp=1), it indicates that the previous privilege level is the supervision mode; an MPP field of 10 (or mpp=2) indicates that the previous privilege level is the overseer mode, and an MPP field of 11 (or mpp=3) indicates that the previous privilege level is the machine mode. The present disclosure is not limited thereto, and for example, in the case where the MPP field is 01 (or may be referred to as mpp=1), it may be indicated whether the previous privilege level is the supervised mode or the super-supervised mode in combination with a value of another parameter, for example, another field (e.g., MPV field) in the MSTATUS register.

For example, where the computer system is running the execution context in only machine mode (e.g., including managed machine mode and secure supervisory mode), the value of the MPP is equal to 3.

For example, in one embodiment of the present disclosure, a new CSR may be added that indicates whether or not the computer system (e.g., a processor in the computer system) is operating in both privilege modes extended from the machine mode and in which privilege mode extended from the machine mode before an interrupt or exception occurs. For example, the parameter MPSM stored in the added new CSR can be used to indicate whether to operate in both privilege modes extended from machine mode and in which privilege mode extended from machine mode before an interrupt or exception occurs to the computer system. For example, in one embodiment of the present disclosure, mpsm=1 means that the computer is operating in a secure supervisory mode before an interrupt or exception occurs to the system, mpsm=0 means that the computer system is operating in a managed machine mode before an interrupt or exception occurs, or mpsm=0 may also mean that the computer system is operating in other privileged modes (e.g., user modes) in a non-secure supervisory mode before an interrupt or exception occurs. Embodiments of the present disclosure are not limited to the above examples, and for example, any parameters that can be distinguished may be used to represent the privilege mode under which a computer system is running before an interrupt or exception occurs.

For example, in one embodiment of the present disclosure, when the computer system is powered on, the computer system defaults to operating in a secure supervisory mode; for another example, when the computer system is reset or restarted, the computer system defaults to operating in a secure supervisory mode.

For example, in one embodiment of the present disclosure, a secure supervisory mode is entered to handle an interrupt or exception before returning to the object mode prior to the interrupt or exception. For example, when an interrupt or exception occurs to an object execution context running in a computer system, resulting in the object execution context being interrupted from running, the current privilege mode will first be saved into an extended added register, such that the value of the MPSM indicates the privilege mode before the interrupt or exception occurred; thereafter, the SM will be rewritten to 1 by hardware (for example, a security supervision unit to be described below), switch to a security supervision mode, process an exception or interrupt in the security supervision mode, and return to the previous object mode after the exception or interrupt is processed.

FIG. 5 is a state machine diagram of a computer system transitioning between a secure supervisory mode, a managed machine mode, and a debug mode provided by some embodiments of the present disclosure; fig. 6 is a state machine diagram of a computer system transitioning between a secure supervisory mode, a managed machine mode, a user mode, and a debug mode provided by some embodiments of the present disclosure.

For example, referring to fig. 5 and 6, when an exception or interrupt occurs in an object mode among a plurality of sub-modes, which results in the execution of the currently executed object execution context being interrupted, the previous object mode is returned after the exception or interrupt is processed.

For example, as shown in fig. 5, in the case of running an execution context in only machine mode (e.g., including managed machine mode and secure supervisory mode), a value of a first parameter is used to represent a previous object mode for returning to the previous object mode according to the value of the first parameter after an exception or interrupt is handled. As an example, the first parameter is MPSM. For example, after processing the exception or interrupt, the MRET instruction may be returned to the location where the object execution context was interrupted from running.

For example, as shown in fig. 6, in the case of running an execution context in a combination of a machine mode (e.g., including a managed machine mode and a secure supervisory mode) and a user mode, at least one of a value of a first parameter and a value of a second parameter is used to collectively represent a previous object mode to return to the previous object mode according to at least one of the value of the first parameter and the value of the second parameter after an exception or interrupt is handled. As an example, the first parameter is MPSM and the second parameter is MPP. For example, after processing the exception or interrupt, the MRET instruction may be returned to the location where the object execution context was interrupted from running.

For example, the MRET instruction may be an instruction in a processor (e.g., a processor based on a RISC-V architecture) instruction set for returning from machine mode to a previously run privilege level (e.g., which may be user mode or supervisor mode). For example, prior to using an MRET instruction, execution in a machine mode or debug mode of the processor is required, and it is ensured that the previous privilege mode state has been saved prior to executing the MRET instruction.

For example, if a program generates a debug request, the debug mode may be used to debug and troubleshoot the program, and after the debug request is processed, the program may be switched to the privileged mode that was previously run by the DRET instruction. For example, prior to using a DRET instruction, it is necessary to ensure that the previous privilege mode state has been saved prior to executing the DRET instruction. For example, dcsr.prv in the RISC-V architecture is a field of the debug control and status register (Debug Control and Status Register), the parameters of which represent the privilege level of the processor prior to processing the debug request. The value range of dcsr.prv field is 0-3, specifically, dcsr.prv=0 is user mode, dcsr.prv=3 is machine mode. For example, a register dcsr.sm may be used to store the privilege mode before entering debug mode, with dcsr.sm=0 representing the managed machine mode and dcsr.sm=1 representing the secure supervisory mode.

For example, as shown in fig. 5 and 6, after processing the debug request in the debug mode, the processor switches to the privileged mode that was run before the program according to the value of at least one of dcsr, prv, and dcsr. For example, the user mode is returned when dcsr.prv=0, the secure supervision mode is returned when dcsr.prv=3 and dcsr.sm=0, and the managed machine mode is returned when dcsr.prv=3 and dcsr.sm=1.

For example, in one embodiment of the present disclosure, as shown in fig. 5, where the execution context is run in only machine mode (e.g., including managed machine mode and secure supervisory mode), when an interrupt or exception occurs in the managed machine mode, the object execution context will be caused to be interrupted to run, the value of SM indicating the current managed machine mode will first be saved into the extended added register, such that the value of MPSM indicates the privileged mode before the interrupt or exception occurred, i.e., when the stored MPSM in the extended added register is equal to 0 (i.e., the value of SM of the current managed machine mode saved); the SM will then be rewritten by hardware to 1, switch to secure supervisory mode, the processor handles the exception or interrupt in secure supervisory mode, and after the exception or interrupt is handled, execute the MRET instruction and return to the previous managed machine mode based on mpsm=0.

For example, in one embodiment of the present disclosure, as shown in fig. 5, when an interrupt or exception occurs in the secure supervisory mode, the interrupt or exception is still handled in the secure supervisory mode. For example, when an interrupt or exception occurs in the secure supervisory mode, the object execution context will be caused to be interrupted running, the value of SM indicating the current secure supervisory mode will first be saved into the extended increment register, such that the value of MPSM indicates the privileged mode before the interrupt or exception occurred, i.e., the value of MPSM saved in the extended increment register at this time is equal to 1 (i.e., the value of MPSM is equal to the value of SM of the current secure supervisory mode saved); after that, SM will be rewritten by hardware to 1, switch to secure supervisory mode, processor processes exception or interrupt in secure supervisory mode, and execute MRET instruction after the exception or interrupt is processed, and return to previous secure supervisory mode based on mpsm=1.

For example, in one embodiment of the present disclosure, as shown in fig. 6, where the execution context is run in a combination of machine mode (e.g., including managed machine mode and secure supervisory mode) and user mode, when the value of the second parameter corresponds to user mode, the user mode is returned after the exception or interrupt is handled; returning to the secure supervisory mode after the exception or interrupt is handled when the value of the second parameter corresponds to the machine mode and the value of the first parameter corresponds to the secure supervisory mode; or returning to the managed machine mode after the exception or interrupt is handled when the value of the second parameter corresponds to the machine mode and the value of the first parameter corresponds to the managed machine mode.

For example, as shown in fig. 6, when an interrupt or exception occurs in user mode, the object execution context will be caused to be interrupted, the value of SM indicating the current user mode will first be saved into the extended increment register, so that the value of MPSM indicates the privileged mode before the interrupt or exception occurred, i.e., the MPSM saved in the extended increment register at this time is equal to 0 (i.e., the value of SM of the current user mode saved), and the value of MPP is also equal to 0; after that, the SM will be rewritten by hardware to 1, switch to the secure supervisory mode, the processor processes the exception or interrupt in the secure supervisory mode, and execute the MRET instruction after the exception or interrupt is processed, and return to the previous user mode based on mpp=0, i.e., when mpp=0, return to the user mode regardless of the value of the MPSM.

For example, as shown in fig. 6, when an interrupt or exception occurs in user mode, if a specific execution code needs to run in machine mode sm=0 (i.e., managed machine mode), for example, an ECALL instruction issuing a system call request is executed in user mode, the processor may switch to secure supervisor mode first, then switch to managed machine mode to handle the interrupt or exception, for example, and may execute an MRET instruction after the exception or interrupt is handled, and return from managed machine mode directly to the previous user mode based on mpp=0.

For example, as shown in fig. 6, when an interrupt or exception occurs in managed machine mode, the object execution context will be caused to be interrupted running, the value of SM indicating the current managed machine mode will first be saved into the extended added register, such that the value of MPSM indicates the privileged mode before the interrupt or exception occurred, i.e., the MPSM saved in the extended added register at this time is equal to 0 (i.e., the value of SM of the current managed machine mode saved), and the value of MPP is equal to 3; after that, the SM will be rewritten by hardware into 1, switch to the secure supervisory mode, the processor processes the exception or interrupt in the secure supervisory mode, and execute the MRET instruction after the exception or interrupt is processed, and return to the previous managed machine mode based on mpp=3 and mpsm=0, i.e. when mpp=3, indicate that the privileged mode before the interrupt occurs is the machine mode, and further determine that the privileged mode before the interrupt occurs is the managed machine mode in which the machine mode is extended according to mpsm=0. The processor is thus able to return to the managed machine mode based on mpp=3 and mpsm=0.

For example, as shown in fig. 6, when an interrupt or exception occurs in the secure supervisory mode, the interrupt or exception is still handled in the secure supervisory mode. For example, when an interrupt or exception occurs in the secure supervision mode, the object execution context will be caused to be interrupted running, the value of SM indicating the current secure supervision mode will first be saved into the extended increment register, such that the value of MPSM indicates the privileged mode before the interrupt or exception occurred, i.e., the MPSM saved in the extended increment register at this time is equal to 1 (i.e., the value of SM of the current secure supervision mode saved), and the value of MPP is equal to 3; after that, the SM will be rewritten to 1 by hardware, switch to the secure supervisory mode, the processor processes the exception or interrupt in the secure supervisory mode, and execute the MRET instruction after the exception or interrupt is processed, and return to the previous secure supervisory mode based on mpp=3 and mpsm=1, i.e. indicate that the privileged mode before the interrupt occurs is the machine mode when mpp=3, and further judge that the privileged mode before the interrupt occurs is the secure supervisory mode extended by the machine mode according to mpsm=1. The processor can therefore return to the secure supervisory mode based on mpp=3 and mpsm=1.

In at least some embodiments of the present disclosure, extensions are made in the machine mode of the RISC-V architecture, including hardware extensions, for example, to extend the original machine mode into multiple sub-modes with different privilege levels to provide a trusted execution environment, and to provide an isolation mechanism between execution contexts, so as to avoid or reduce security vulnerabilities that interfere with each other, thereby effectively reducing the attack surface and improving the security of the system.

As shown in fig. 7, some embodiments of the present disclosure also provide a processor 100, the processor 100 including a processor core 110 and a security supervisor unit 120.

For example, in one embodiment of the present disclosure, the processor core 110 of the processor 100 may be based on RISC-V, X, arm, etc. instruction set architecture, supporting the RISC-V instruction set, X86 instruction set, arm instruction set, etc. accordingly, the present disclosure is not particularly limited as to what architecture the processor 100 is based on. The safety supervision unit 120 is configured to: providing a plurality of sub-modes having different privilege levels in a machine mode of a computer system; and allowing at least one of the plurality of execution contexts to run in the plurality of sub-modes, respectively.

For example, the functions and method steps that may be implemented by the processor 100 may be referred to any of the functions and method steps described above with reference to fig. 1 to 6, and the disclosure is not repeated herein.

The above embodiments of the present disclosure provide a processor, which is extended in a machine mode of a RISC-V architecture, so that an original machine mode can be extended into a plurality of sub-modes with different privilege levels, so as to provide a trusted execution environment, and an isolation mechanism is provided between execution contexts, so that security vulnerabilities that mutually interfere with each other are avoided or reduced, thereby effectively reducing attack planes and improving security of a system.

Some embodiments of the present disclosure also provide an electronic device. Fig. 8 is a schematic diagram of an electronic device provided in some embodiments of the present disclosure.

As shown in fig. 8, an electronic device 500 according to an embodiment of the present disclosure includes a processor 501 and a memory 502, the processor 501 and the memory 502 being interconnected by a bus 503. For example, the processor 501 shown in fig. 8 may be the processor 100 shown in fig. 7.

The processor 501 may perform various actions and processes in accordance with programs or code stored in the memory 502. In particular, the processor 501 may be an integrated circuit chip with signal processing capabilities. For example, the processor 501 may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, and may implement or perform the various methods and steps disclosed in embodiments of the present disclosure. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, and may be an X86 architecture or an ARM architecture or the like.

Memory 502 is used for non-transitory storage of computer-executable instructions and processor 501 is used for execution of computer-executable instructions. The computer-executable instructions, when executed by the processor 501, implement the method of operation provided by at least one embodiment of the present disclosure.

For example, the memory 502 may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be Random Access Memory (RAM), which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate synchronous dynamic random access memory (ddr SDRAM), enhanced Synchronous Dynamic Random Access Memory (ESDRAM), synchronous Link Dynamic Random Access Memory (SLDRAM), and direct memory bus random access memory (DRRAM). It should be noted that the memory of the methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

Embodiments of the present disclosure also provide a non-transitory storage medium, which may be a non-transitory computer-readable storage medium. The non-transitory storage medium is used to non-transitory store computer-executable instructions that, when executed by a computer, implement the methods of operation provided by at least some embodiments of the present disclosure.

Fig. 9 is a schematic diagram of a non-transitory storage medium provided by some embodiments of the present disclosure. As shown in fig. 9, the non-transitory storage medium 600 may non-transitory store computer-executable instructions 610, which when executed by a computer, the computer-executable instructions 610 implement the methods of operation provided by any of the embodiments of the present disclosure.

Similarly, the non-transitory storage medium in embodiments of the present disclosure may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. It should be noted that the memory of the methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

Embodiments of the present disclosure also provide a computer program product or computer program comprising computer instructions stored in a non-transitory storage medium. A processor of a computer device reads the computer instructions from a non-transitory storage medium, the processor executing the computer instructions, causing the computer device to perform a method of operation provided in accordance with at least one embodiment of the present disclosure.

The technical effects of the electronic device and the non-transitory storage medium are the same as those of the operation method, and are not described here again.

It is noted that the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises at least one executable instruction for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In general, the various example embodiments of the disclosure may be implemented in hardware or special purpose circuits, software, firmware, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While aspects of the embodiments of the present disclosure are illustrated or described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

For the purposes of this disclosure, the following points are also noted:

(1) The drawings of the embodiments of the present disclosure relate only to the structures related to the embodiments of the present disclosure, and other structures may refer to the general design.

(2) In the drawings for describing embodiments of the present disclosure, thicknesses and dimensions of layers or structures are exaggerated for clarity. It will be understood that when an element such as a layer, film, region or substrate is referred to as being "on" or "under" another element, it can be "directly on" or "under" the other element or intervening elements may be present.

(3) The embodiments of the present disclosure and features in the embodiments may be combined with each other to arrive at a new embodiment without conflict.

The foregoing is merely a specific embodiment of the disclosure, but the scope of the disclosure is not limited thereto and should be determined by the scope of the claims.

Claims

1. A method of operation of a computer system, comprising:

providing a plurality of sub-modes having different privilege levels in a machine mode of the computer system; and

at least one of a plurality of execution contexts is allowed to run in each of the plurality of sub-modes.

2. The method of operation of claim 1, wherein the plurality of sub-modes includes a secure supervisory mode and a managed machine mode,

the privilege level of the secure supervisory mode is greater than the privilege level of the managed machine mode.

3. The method of operation of claim 2, wherein the plurality of execution contexts includes a first execution context and a second execution context,

the operation method further comprises the following steps:

running the first execution context in the secure supervisory mode and the second execution context in the managed machine mode.

4. The method of operation of claim 3, wherein the plurality of execution contexts further comprises one or more other execution contexts,

the operation method further comprises the following steps:

at least one of the one or more other execution contexts is run in at least one of the secure supervisory mode and the managed machine mode.

5. The method of operation of claim 3, wherein the first execution context is a secure supervisory execution context and the second execution context is a real-time operating system context.

6. The method of operation of claim 4, wherein the one or more other execution contexts comprise a secure operating system context or secure firmware.

7. The method of operation of claim 1, further comprising:

when an exception or interrupt occurs in an object sub-mode of the plurality of sub-modes, which results in the execution of the currently executed object execution context being interrupted, the exception or interrupt is processed and then returned to the previous object sub-mode.

8. The method of operation of claim 7 wherein the plurality of sub-modes includes a secure supervisory mode and a managed machine mode, the secure supervisory mode having a privilege level greater than a privilege level of the managed machine mode,

The operation method further comprises the following steps:

and before returning to the previous object sub-mode, entering the safety supervision mode to process the exception or the interrupt.

9. The method of operation of claim 7, further comprising:

the previous object sub-pattern is represented using a value of a first parameter for returning to the previous object sub-pattern according to the value of the first parameter after the exception or the interrupt is handled.

10. The method of operation of claim 2, further comprising:

a user mode is provided in the computer system,

wherein the privilege level of the user mode is less than the privilege level of the machine mode, the user mode allowing for running at least one application that is runnable in at least one of the plurality of execution contexts.

11. The method of operation of claim 10, further comprising:

when an exception or interrupt occurs in object mode resulting in the execution of the currently executing object context being interrupted, the execution returns to the previous object mode after the exception or interrupt is handled.

12. The method of operation of claim 11, further comprising:

before returning to the previous object mode, the secure supervision mode is entered to process the exception or the interrupt,

Wherein the object mode is the user mode or the machine mode.

13. The method of operation of claim 11, further comprising:

the previous object pattern is represented using at least one of a value of a first parameter and a value of a second parameter to return to the previous object pattern according to at least one of the value of the first parameter and the value of the second parameter after the exception or the interrupt is handled.

14. The method of operation of claim 13, wherein returning the previous object pattern according to at least one of the value of the first parameter and the value of the second parameter comprises:

returning to the user mode after the exception or the interrupt is handled when the value of the second parameter corresponds to the user mode;

returning to the secure supervisory mode after the exception or interrupt is handled when the value of the second parameter corresponds to the machine mode and the value of the first parameter corresponds to the secure supervisory mode; or alternatively

When the value of the second parameter corresponds to the machine mode and the value of the first parameter corresponds to the managed machine mode, the managed machine mode is returned after the exception or the interrupt is handled.

15. The method of operation of claim 9 or 13, wherein the computer system operates in the secure supervisory mode when the computer system is powered on.

16. The method of operation of claim 10, wherein the computer system is based on a RISC-V instruction set.

17. A processor, comprising:

a processor core;

a safety supervision unit configured to: providing a plurality of sub-modes having different privilege levels in a machine mode of a computer system; and allowing at least one of the plurality of execution contexts to run in the plurality of sub-modes, respectively.

18. An electronic device, comprising:

a memory configured to store computer-executable instructions; and

a processor configured to execute the computer-executable instructions,

wherein the computer executable instructions, when executed by the processor, implement the method according to any of claims 1-16.

19. A non-transitory storage medium storing non-transitory computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method of any one of claims 1-16.