Memory protection method, apparatus, device, and storage medium

Abstract

The application discloses a memory protection method and device, equipment and a storage medium, and relates to the technical field of computers. The method comprises the following steps: receiving a memory access request initiated by a first kernel of an operating system, wherein the memory access request is used for requesting to access a first region of a memory; performing a kernel-level barrier check on the first kernel according to the memory access request, obtaining a first check result, and the kernel-level barrier check is used for determining whether the first kernel has access permission of the first region; in the case that the first check result is that the first kernel has the access permission of the first region, performing a token permission check on the first kernel, obtaining a second check result; and in the case that the second check result is that the first kernel has a valid authorization token corresponding to the first region, performing an access operation on the first region according to the memory access request. The method realizes memory protection and improves the security of memory access.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a memory protection method, apparatus, device, and storage medium. Background Technology

[0002] The kernel, as a crucial component of the operating system, is the core program used to control hardware and other components. For example, an operating system includes a host kernel and virtual machines, with the host kernel having control over the virtual machine's memory.

[0003] In related technologies, the host kernel is allowed to directly access the virtual machine's memory, and the host kernel has access rights and control over the virtual machine's memory.

[0004] However, if the host kernel is compromised by an attacker, it is highly likely that the virtual machine's memory can be accessed, read, and modified. Therefore, the security of memory access in related technologies is relatively low. Summary of the Invention

[0005] This application provides a memory protection method, apparatus, device, and storage medium, which can achieve memory protection and improve the security of memory access. The technical solution provided by this application includes the following aspects.

[0006] According to one aspect of the embodiments of this application, a memory protection method is provided, the method comprising the following steps.

[0007] Receive a memory access request initiated by the first kernel of the operating system, the memory access request being used to request access to a first region of memory.

[0008] Based on the memory access request, a kernel-level barrier check is performed on the first kernel to obtain a first check result; wherein, the kernel-level barrier check is used to determine whether the first kernel has access rights to the first region.

[0009] If the first check result indicates that the first kernel has access permissions to the first region, a token permission check is performed on the first kernel to obtain a second check result; wherein, the token permission check is used to determine whether the first kernel has a valid authorization token corresponding to the first region.

[0010] If the second check result indicates that the first kernel possesses a valid authorization token corresponding to the first region, an access operation is performed on the first region according to the memory access request.

[0011] According to one aspect of the embodiments of this application, a memory protection device is provided, the device comprising the following modules.

[0012] The request receiving module is used to receive a memory access request initiated by the first kernel of the operating system, wherein the memory access request is used to request access to a first region of memory.

[0013] The barrier checking module is used to perform a kernel-level barrier check on the first kernel according to the memory access request, and obtain a first check result; wherein, the kernel-level barrier check is used to determine whether the first kernel has access rights to the first region.

[0014] The token checking module is used to perform a token permission check on the first kernel if the first check result indicates that the first kernel has access permissions to the first region, and obtain a second check result; wherein, the token permission check is used to determine whether the first kernel has a valid authorization token corresponding to the first region.

[0015] The request execution module is used to perform an access operation on the first region according to the memory access request if the second check result indicates that the first kernel has a valid authorization token corresponding to the first region.

[0016] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described memory protection method.

[0017] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the above-described memory protection method.

[0018] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described memory protection method.

[0019] The technical solutions provided in this application can bring the following beneficial effects.

[0020] This application performs a double-checked check upon receiving a memory access request before executing the corresponding access operation. Specifically, for a memory access request to a first region of memory initiated by the first kernel, a kernel-level barrier check is first performed on the first kernel to check if it has the necessary access permissions for the first region. If the first kernel has the necessary access permissions, a token permission check is then performed on the first kernel to check if it possesses a valid authorization token corresponding to the first region. If the first kernel possesses a valid authorization token corresponding to the first region, the access operation to the first region is executed according to the memory access request. Through this double-checked check, access operations to the first region can only be executed according to a memory access request if both the first kernel has the necessary access permissions and a valid authorization token corresponding to the first region, thus achieving the purpose of memory protection.

[0021] The kernel-level barrier in this application is responsible for isolation, and the token permission is responsible for authorization. Through the coordinated control between the two, it is ensured that memory access requests are only allowed if they are not isolated (have access rights) and hold the corresponding token (have a valid authorization token), thus realizing memory protection and improving the security and reliability of memory access. Attached Figure Description

[0022] Figure 1 This is a structural block diagram of a computer system provided in one embodiment of this application;

[0023] Figure 2 This is a schematic diagram of a memory protection method provided in one embodiment of this application;

[0024] Figure 3 This is a flowchart of a memory protection method provided in one embodiment of this application;

[0025] Figure 4 This is a flowchart of a memory protection method provided in another embodiment of this application;

[0026] Figure 5 This is a flowchart of a memory protection method provided in another embodiment of this application;

[0027] Figure 6 This is a schematic diagram of a memory protection method provided in another embodiment of this application;

[0028] Figure 7 This is a schematic diagram of an operating system provided in one embodiment of this application;

[0029] Figure 8 This is a schematic diagram of an operating system provided in another embodiment of this application;

[0030] Figure 9This is a schematic diagram of a memory protection method provided in another embodiment of this application;

[0031] Figure 10 This is a block diagram of a memory protection device provided in one embodiment of this application;

[0032] Figure 11 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0034] Figure 1 This is a structural block diagram of a computer system provided in one embodiment of this application. The computer system may include: electronic device 10.

[0035] Electronic device 10 can be at least one of the following: a terminal device, a server. Optionally, if electronic device 10 is a terminal device, then the terminal device can be at least one of the following: a PC (Personal Computer), a mobile phone, a tablet computer, a smart voice interaction device, a wearable device, an industrial control device, rail transit-related equipment, power energy-related equipment, a multimedia playback device, an in-vehicle terminal, etc. Optionally, if electronic device 10 is a server, then the server can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0036] In this embodiment, the operating system of the electronic device 10 can be a Kylin operating system (or Linux operating system) built on a Linux kernel (also referred to as Linux). Optionally, the operating system of the electronic device 10 includes at least one kernel. Optionally, as... Figure 1 As shown, the operating system of electronic device 10 includes a low-level kernel and a high-level kernel. Optionally, the low-level kernel can be a host kernel, and the high-level kernel can be a security kernel. Optionally, when the low-level kernel initiates a memory access request for a certain region of memory, the high-level kernel performs memory protection. Specifically, the high-level kernel performs kernel-level barrier checks and token permission checks on the memory access request.

[0037] In one possible implementation, an operating system is used to implement the memory protection method mentioned in this application. Optionally, at least one kernel exists within the kernel to implement the memory protection method mentioned in this application. Optionally, the kernel used to implement the memory protection method is also called a memory protection kernel. Optionally, memory protection is implemented through a high-level kernel in the operating system. Optionally, memory protection is implemented through a secure kernel.

[0038] In another possible implementation, the electronic device 10 includes a memory protection module. This memory protection module is used to implement the memory protection method mentioned in this application.

[0039] In another possible implementation, the electronic device 10 has a client installed for an application that implements memory protection, which runs to implement the memory protection method mentioned in this application.

[0040] The method provided in this application can be executed by the aforementioned electronic device 10, the operating system of the electronic device 10, the memory protection kernel (e.g., the security kernel) in the operating system, the memory protection module in the electronic device 10, or the client of the application used to implement memory protection in the electronic device 10. In the following embodiments of this application, a computer device is used as an example to illustrate the method.

[0041] Before introducing the specific implementation method of this application, the operating system and other related information will be explained.

[0042] In operating system architecture, exception levels (EL) include EL0, EL1, EL2, and EL3. Optionally, EL0 is the lowest privilege level, the level at which user-mode programs run. Optionally, EL3 is the highest privilege level, the level where some security-related firmware (such as SoC vendors and TrustZone components) reside; the Linux operating system cannot directly enter EL3. Common operating system kernels (such as Linux) run at EL1, and can access most system registers, Memory Management Unit (MMU) configurations, exception vector tables, and page tables. In non-virtualized systems, Linux's highest privilege level is EL1. After the system is configured for virtualization, EL2 is the virtualization management level of the hypervisor (such as KVM (Kernel-based Virtual Machine)), primarily handling virtualization-related isolation and control. The advent of virtualization makes dual-kernel parallelism possible; running kernels with different characteristics at different levels constitutes a dual-kernel architecture.

[0043] A dual-kernel architecture consists of two kernels at different privilege levels: a secure / trusted kernel (also known as a secure kernel) and a normal, rich operating system kernel (also known as a rich kernel). The secure / trusted kernel runs at a higher privilege level (EL2), providing memory isolation, access control, privacy encryption, and trusted boot functionality. The rich kernel, in related technologies, runs at a normal privilege level (EL1), providing a regular application runtime environment and subject to the constraints and isolation of the secure kernel. The dual-kernel memory protection design determines whether kernels at different security levels can communicate with each other, ensuring that the higher-privileged kernel is not attacked by the lower-privileged kernel, supporting controlled secure shared memory, and providing secure inter-process communication (IPC), direct memory access (DMA) isolation, and page table isolation.

[0044] The KVM virtualization subsystem within the kernel, running in VHE (Virtualization Host Extensions) and nVHE (non-VHE) modes, operates on the core design principle that the Guest (virtual machine) runs on top of the Host kernel (also known as the Host kernel or host machine kernel), with the Host kernel providing resource management and address space control for the Guest. This architecture strikes a good balance between performance, engineering feasibility, and complexity, but it suffers from some structural design limitations regarding memory security and isolation. These limitations result in the Host inherently possessing complete access to the Guest's memory within KVM. Whether through intentional management or attacker control, the Host can directly read or modify the Guest's memory. This structural limitation, if the Host is completely compromised or a high-risk vulnerability exists in the Host layer, prevents the Guest from being considered a Trusted Execution Environment (TEE) or a privacy isolation zone. In KVM, the "Physical Memory (Intermediate Physical Address, IPA)" seen by the Guest is merely a virtual concept; its essence is ordinary pages allocated by the Host kernel, belonging to the Host. In other words, the Guest's physical memory is actually just the Host's ordinary physical pages. There is no absolute memory barrier between cores, which means that the Host has the initial allocation right to this memory and can establish mappings to access, reclaim, replace, and migrate this memory at any time. The Guest does not have ownership of the actual physical memory.

[0045] In a virtualization system, the Guest's address undergoes two levels of page table translation. Stage 1 translates the Guest's virtual address to its intermediate physical address, while Stage 2 translates it to the Host's physical address. The Stage 2 page table is created and maintained by KVM running in the Host kernel. This means the Host can write arbitrary entries to the Stage 2 page table, determining which actual physical address each intermediate physical address maps to. The Host can expose any memory to the Guest, or point the Guest's intermediate physical address to any physical address the Host wants to expose / deceive the Guest. Furthermore, the Guest requires Host involvement when modifying its own Stage 1 page table, further expanding the Host's control over the Guest's address space. The Guest's memory security is highly dependent on the integrity of the Host kernel. The Guest's "physical memory" is actually ordinary physical pages allocated by the Host process. The Guest's second-level page table is built and controlled by the Host. The Host kernel can directly mmap (memory map) or memcpy (memory copy) to the Guest pages, and the Stage 2 page table can also be arbitrarily modified by the Host. The Host always has complete access to and control over the Guest's memory within KVM, with no form of hardware-level or hypervisor-level protection. Once an attacker gains control of the Host kernel, they can unconditionally read, modify, and even rewrite the Guest's memory space. Therefore, the Guest is not entirely independent in terms of security.

[0046] In related technologies, the trusted execution environment strategy based on hardware isolation and trusted environment in the operating system architecture is absolutely dependent on the hardware side, and the development of trusted security at the operating system kernel level is greatly limited by hardware compatibility. Alternatively, the systemic immunity of Trusted Computing 3.0 constitutes a "computing + trusted" dual-component trusted platform architecture. While the computing component performs operations, the trusted component achieves proactive immunity and active protection against network information systems. However, for dual-kernel systems that run together and share a portion of memory resources, there are structural problems such as blurred kernel boundaries and privilege escalation risks, which can easily lead to the accidental exposure of high-privileged memory and the risk of potential security boundary breaches. In related technologies, permissions in the system are controlled by a single point of the operating system kernel, and page tables and mapping relationships are constructed by the host kernel. This "coarse-grained" permission allocation allows the host to access any region, and when the host changes the page table, the secure kernel has difficulty auditing and rolling back. When physical pages move between two kernels, there is a risk of pages being incorrectly shared in multiple places and information leakage caused by other entities reading old data again after memory reclamation.

[0047] To address the problems existing in related technologies, under the requirements of a Trusted Execution Environment (TEE), the goal is to make the Guest's memory independently owned by the Guest. The Stage 2 page tables are entirely managed by the EL2 layer, ensuring that even if the Host kernel is completely compromised, it cannot access or interfere with the Guest's memory. This creates a hardware-like "virtual barrier." The dual-system architecture cleverly solves this problem at the structural level. In a dual-kernel operating system, both kernels must share a set of physical memory, but each has different privileges, preventing lower-privileged kernels from accessing the memory of higher-privileged kernels. Even when cross-kernel shared memory access is necessary, it must be within a controllable range to avoid the risk of data leakage and attacks. Furthermore, it protects sensitive data (such as keys, TEE applications, and monitoring code), ensuring that even if the normal operating system kernel is compromised, the secure and trusted kernel remains secure.

[0048] Since the trusted domain of the Guest is directly placed under the Host kernel, its security is heavily reliant on the integrity of the Host kernel. This application introduces a dual-kernel architecture, dividing the single Host kernel in related technologies into a host kernel focused on management functions and a security kernel that controls resource ownership. By constructing a virtualization-level "kernel-level barrier" between the two, the Guest's memory becomes subordinate to the security kernel, which is responsible for allocation, mapping, and access arbitration. The ordinary Host kernel no longer directly possesses read and write permissions for the Guest's memory. When the Host kernel is attacked, the attack surface cannot cross the virtual barrier to reach the Guest's confidential data, fundamentally achieving strong isolation and proactive protection of the Guest's memory, forming an efficient, secure, and reliable memory protection system.

[0049] This application provides a memory protection method, apparatus, device, and storage medium designed to prevent low-privileged kernels from accessing high-privileged kernel memory. An insurmountable "safety belt" is established between different kernels, forming a core-level memory barrier. This provides memory access between kernels, but access events must be within a controllable range. The secure kernel is used to protect sensitive data, such as keys, TEE applications, and code monitoring, ensuring that the secure kernel remains secure even if the normal kernel is compromised. Furthermore, to address the memory protection problem in a dual-kernel architecture, a hierarchical token (HT) authorization system is implemented. This transforms the original "single-point control" access permissions into a "hierarchical authorization" management system. The high-privileged kernel creates page table mappings, marks ownership, and uses the Stage2 page table to control access, preventing the host from directly accessing the guest memory.

[0050] like Figure 2 As shown, for a memory access request from the first kernel to the first region, a kernel-level barrier check and a token permission check need to be performed. Optionally, if the kernel-level barrier check and token permission check determine that the first kernel has access rights to the first region and has a valid authorization token corresponding to the first region, then the access operation corresponding to the memory access request is performed for the first region.

[0051] In this application, a kernel-level barrier handles isolation, while multi-level tokens handle authorization. Through coordinated control between the two, access is guaranteed only when the corresponding token is held, determining whether kernels with different security levels can access each other. This ensures that a high-privileged kernel is not attacked by a low-privileged kernel and supports controlled secure shared memory. It enhances the memory protection capabilities of dual-kernel operating systems, improves kernel security and trustworthiness, and more efficiently addresses complex security scenarios.

[0052] Please refer to Figure 3 The diagram illustrates a flowchart of a memory protection method according to an embodiment of this application. The execution entity for each step of this method can be the aforementioned computer device. The method may include at least one of the following steps (310-340).

[0053] Step 310: Receive a memory access request initiated by the first kernel of the operating system. The memory access request is used to request access to the first region of memory.

[0054] The operating system types mentioned in this application include at least one of the following: desktop operating system, server operating system, intelligent computing operating system, industrial operating system, and IoT operating system. This application does not limit the specific type of operating system. Optionally, the operating system in this application is also called the Kylin operating system, which is an operating system built on the Linux kernel. This application does not strictly limit the operating system; any operating system that can implement the memory protection method proposed in this application can be considered as the operating system in this application.

[0055] Optionally, the operating system in this application includes at least one kernel. Optionally, the kernel is the core program of the operating system, used to implement control over hardware, etc. Optionally, when the operating system includes only one kernel, the operating system can also be called a kernel. Optionally, the first kernel in this application is any one or more of the kernels included in the operating system. Optionally, the first kernel in this application is a low-level kernel in the operating system. Optionally, the first kernel in this application is the host kernel in the operating system.

[0056] In some embodiments, the operating system includes two or more kernels; and / or, the memory includes at least two of the following regions: physical memory region, virtual memory region, MMIO (Memory-Mapped Input / Output) region, page table region, shared region, and private security region.

[0057] In some embodiments, the operating system includes two kernels. Optionally, the operating system includes two kernels: a security kernel for handling the first type of tasks and a host kernel for handling the second type of tasks; wherein the security requirements for the first type of tasks are higher than those for the second type of tasks.

[0058] For example, a secure kernel is used to handle the first type of task. Optionally, the secure kernel is used to protect sensitive data, such as at least one of keys, TEE applications, and code monitoring, ensuring that the secure kernel remains secure even if the normal kernel is compromised. Optionally, the first type of task has higher security requirements.

[0059] For example, the host kernel is used to handle the second type of task. Optionally, the host kernel is used to handle other system tasks besides the first type of task. Optionally, the second type of task has lower security requirements.

[0060] For example, the tasks to be executed by the operating system are categorized in advance. Tasks with high security requirements are classified as the first category and processed by the security kernel. Tasks with low security requirements are classified as the second category and processed by the host kernel.

[0061] In other embodiments, the operating system includes more than two kernels. Optionally, in addition to a security kernel and a host kernel, the operating system also includes at least one of the following kernels: a real-time kernel, a service kernel, a virtualization kernel, and a distributed kernel. The real-time kernel provides deterministic and accurate response times for tasks, the service kernel performs tasks related to operating system services, and the virtualization kernel creates and manages virtual machines and performs tasks related to virtual resource allocation.

[0062] This application does not limit the specific number of kernels included in the operating system; the first kernel is any one or more of the at least one kernel included in the operating system. In some embodiments, the kernels of the operating system are represented as a set.

[0063] Optionally, if the operating system includes a security kernel and a host kernel, then the operating system includes a kernel body. The set is defined as follows:

[0064]

[0065] in, Indicates a secure kernel. This refers to the host kernel.

[0066] In some embodiments, the "domain" or "region" in this application is considered to be a region in memory. Optionally, this application divides memory to obtain at least one region. Optionally, a region in memory may also be referred to as a memory domain.

[0067] Optionally, the memory includes at least two of the following regions: physical memory region, virtual memory region, MMIO region, page table region, shared region, and private security region.

[0068] Physical memory domains are areas in memory allocated to physical memory. Virtual memory domains are areas in memory allocated to virtual memory. MMIO domains are memory areas in memory mapped to peripherals. Page table domains are memory areas in memory allocated to page tables. Shared domains are memory areas shared by at least two kernels. Private security domains are memory areas private (dedicated) to one or at least two kernels.

[0069] This application does not impose restrictions on the division of memory regions. Optionally, different regions may or may not intersect. Optionally, the union of all regions equals the total memory space.

[0070] For example, memory includes the following regions: physical memory domain, virtual memory domain, MMIO domain, page table domain, shared domain, and private security domain. Optionally, memory M represents the following:

[0071]

[0072] in, Represents physical memory domain, Represents virtual memory domain, Indicates MMIO field, Represents page table fields, Indicates shared domain, This indicates a private security domain. Optionally, It can correspond to any level of page table, including the Stage 1 page table mentioned above, and / or the Stage 2 page table. Optionally, In operating systems with two kernels, this could be a memory region shared (co-mapped) by both kernels. Optionally, It can be a private domain of a high-privilege kernel, for example It can be a private domain of a secure kernel.

[0073] Compared to partitioning memory at the physical page level, this application partitions memory space at the domain level, effectively reducing the number of domains. This avoids excessive resource consumption during kernel-level barrier checks by configuring labels (or identifiers) and kernel-level barrier information for each domain. While adhering to the operating system's isolation granularity, this approach reduces the cost and improves the efficiency of kernel-level barrier checks.

[0074] A memory access request is a request to access a first region of memory. Optionally, the memory access request carries at least one of the following information: identification information of the first region, identification information of the first kernel, and content information of the request. The identification information of the first region identifies the first region, the identification information of the first kernel identifies the first kernel, and the content of the request includes the first kernel's operation permissions for the first region.

[0075] In some embodiments, a memory access request includes at least one of the following: subject information, used to indicate that the subject initiating the memory access request is a first kernel; region information, used to indicate that the region requested for access is a first region; and operation permission information, used to indicate the operation permissions that the first kernel has for the first region.

[0076] Optionally, the memory access request includes subject information, region information, and operation permission information. Optionally, the memory access request can be represented in the form of a triple. For example, a memory access request can be represented as: .in, This is the main information used to indicate the kernel entity (such as the first kernel) that initiated the memory access request. 'i' can be the identifier or sequence number of the kernel entity. This is region information, used to indicate the memory region (such as the first region) to be accessed by the memory access request. j can be the region identifier or sequence number. This is operation permission information, used to indicate the operation permissions that the kernel body has for the memory region.

[0077] The subject information is used to indicate that the subject initiating the memory access request is the first kernel. That is, the subject information is used to indicate the first kernel. Optionally, the subject information is the identification information of the first kernel. Optionally, the subject information uses... This indicates that the first kernel can be any one or more kernels, such as a security kernel or a host kernel.

[0078] The area information is used to indicate that the requested area is the first area. That is, the area information is used to indicate the first area. Optionally, the area information is the identification information of the first area. Optionally, the area information uses... Optionally, the first region can be any one or more of the physical memory region, virtual memory region, MMIO region, page table region, shared region, and private security region mentioned above.

[0079] Operation permission information indicates the operation permissions that the first kernel possesses for the first region. Optionally, these operation permissions include, but are not limited to, at least one of the following: read permission, write permission, read-write permission, and execute permission. Optionally, the operation permission information uses... express.

[0080] Optionally, .in, Indicates read permission. Indicates write permission. Indicates execution permission. Indicates read and write permissions. Indicates read and execute permissions. Indicates read, write, and execute permissions.

[0081] In this embodiment, the memory access request includes subject information, region information, and operation permission information. This comprehensive content facilitates subsequent kernel-level barrier checks and token permission checks, improving check efficiency. Furthermore, the memory access request can be represented as a triple, simplifying its representation and enhancing its efficiency.

[0082] Step 320: Based on the memory access request, perform a kernel-level barrier check on the first kernel to obtain the first check result; wherein, the kernel-level barrier check is used to determine whether the first kernel has access rights to the first region.

[0083] Optionally, a kernel-level barrier check is used to determine whether the first kernel has access permissions to the first region. Optionally, a kernel-level barrier check is performed on the first kernel based on the memory access request. Optionally, a kernel-level barrier check is performed on the first kernel based on at least one of the subject information, region information, and operation permission information carried in the memory access request to determine whether the first kernel has access permissions to the first region. Optionally, a kernel-level barrier check is performed on the first kernel based on at least one of the subject information and region information carried in the memory access request to determine whether the first kernel has access permissions to the first region. Optionally, a kernel-level barrier check is performed on the first kernel based on the subject information and region information carried in the memory access request to determine whether the first kernel has access permissions to the first region.

[0084] In one possible implementation, first indication information of all kernels with access rights to the first region is obtained. Optionally, based on the subject information carried in the memory access request, it is determined whether the first kernel belongs to the kernel indicated by the first indication information. If it does, then the first kernel is determined to have access rights to the first region. If it does not, then the first kernel is determined not to have access rights to the first region.

[0085] In another possible implementation, second indication information of the memory regions accessible to the first kernel is obtained. Optionally, based on the region information carried in the memory access request, it is determined whether the first region belongs to the region indicated by the second indication information. If it does, it is determined that the first kernel has access rights to the first region. If it does not, it is determined that the first kernel does not have access rights to the first region.

[0086] For an explanation of nuclear-grade barrier inspection, please refer to the following examples, which will not be elaborated further here.

[0087] Optionally, the first check result includes at least one of the following: the first kernel has access to the first region; the first kernel does not have access to the first region. Optionally, the first check result can be represented in numerical form. For example, if the first check result is a first numerical value, then the first check result is that the first kernel has access to the first region. For example, if the first check result is a second numerical value, then the first check result is that the first kernel does not have access to the first region. Optionally, the first numerical value is 1, and the second numerical value is 0. Of course, the first numerical value and the second numerical value can also be other numerical values, and this application does not limit the specific numerical values ​​of the first numerical value and the second numerical value.

[0088] Step 330: If the first check result indicates that the first kernel has access permissions to the first region, perform a token permission check on the first kernel to obtain a second check result; wherein, the token permission check is used to determine whether the first kernel has a valid authorization token corresponding to the first region.

[0089] Optionally, if the first check result indicates that the first kernel has access rights to the first region, then a token permission check is performed on the first kernel. Optionally, if the first check result indicates that the first kernel does not have access rights to the first region, then it is not necessary to continue performing a token permission check on the first kernel. Optionally, if the first check result indicates that the first kernel does not have access rights to the first region, then the step of performing an access operation on the first region based on the memory access request is not executed. Optionally, if the first check result indicates that the first kernel does not have access rights to the first region, then the memory access request is rejected.

[0090] Optionally, the token permission check is a check used to determine whether the first kernel has a valid authorization token corresponding to the first region.

[0091] In one possible implementation, a token permission check is performed on the first kernel based on the memory access request. Optionally, the token permission check is performed on the first kernel based on at least one of the subject information, region information, and operation permission information carried in the memory access request to determine whether the first kernel possesses a valid authorization token corresponding to the first region.

[0092] In another possible implementation, the identification information of the token possessed by the first kernel is obtained. Optionally, based on the identification information of the token possessed by the first kernel, it is determined whether the token possessed by the first kernel is a valid authorization token corresponding to the first region. Optionally, if the token possessed by the first kernel includes a valid authorization token corresponding to the first region, it is determined that the first kernel possesses a valid authorization token corresponding to the first region. Optionally, if the token possessed by the first kernel does not include a valid authorization token corresponding to the first region, it is determined that the first kernel does not possess a valid authorization token corresponding to the first region. For example, the token possessed by the first kernel is obtained based on the first kernel indicated by the subject information carried in the memory access request. Optionally, the token possessed by the first kernel is also the token held by the first kernel.

[0093] In another possible approach, the token possessed by the first kernel is obtained. For example, if a condition is satisfied between the token possessed by the first kernel and the valid authorization token corresponding to the first region, then it is determined that the first kernel possesses the valid authorization token corresponding to the first region. Optionally, the condition includes at least one of the following: the token level held by the first kernel is greater than or equal to the token level of the valid authorization token corresponding to the first region; the token possessed by the first kernel includes the valid authorization token corresponding to the first region; and the token possessed by the first kernel and the valid authorization token corresponding to the first region belong to the same token type or the same token set.

[0094] The valid authorization token corresponding to the first region refers to the token that grants access to the first region to a kernel subject if the kernel subject possesses it. Conversely, if a kernel subject does not possess the token, it is not allowed to access the first region. Optionally, the valid authorization token is pre-defined for the first region and can be distributed to kernel subjects. If a kernel subject is issued a valid authorization token, it is considered that the kernel subject possesses the valid authorization token corresponding to the first region.

[0095] Optionally, each kernel entity in the operating system possesses a token. Optionally, these tokens are distributed to the kernel entities in advance. Optionally, different tokens differ in at least one of the following: token identification information, token validity period, token corresponding permissions, and token level. Optionally, the tokens possessed by the kernel entities are used to indicate at least one of the kernel entity's operation permissions, operation time, and operation target.

[0096] For an explanation of token permission checks, please refer to the following examples; further details will not be provided here.

[0097] Optionally, the second check result includes at least one of the following: the first kernel possesses a valid authorization token corresponding to the first region; the first kernel does not possess a valid authorization token corresponding to the first region. Optionally, the second check result can be represented in numerical form. For example, if the second check result is a third numerical value, then the second check result is: the first kernel possesses a valid authorization token corresponding to the first region. For example, if the second check result is a fourth numerical value, then the second check result is: the first kernel does not possess a valid authorization token corresponding to the first region. Optionally, the third numerical value is 1, and the fourth numerical value is 0. Of course, the third and fourth numerical values ​​can also be other numerical values, and this application does not limit the specific values ​​of the third and fourth numerical values.

[0098] Step 340: If the second check result indicates that the first kernel has a valid authorization token corresponding to the first region, perform an access operation on the first region according to the memory access request.

[0099] Optionally, if the second check result indicates that the first kernel possesses a valid authorization token corresponding to the first region, then an access operation is performed on the first region according to the memory access request. Optionally, if the second check result indicates that the first kernel does not possess a valid authorization token corresponding to the first region, then the step of performing an access operation on the first region according to the memory access request is not executed. Optionally, if the second check result indicates that the first kernel does not possess a valid authorization token corresponding to the first region, then the memory access request is rejected.

[0100] Optionally, there is no limitation on how the access operation is performed. Optionally, the access operation is performed on the first region based on the access address in the first region carried in the memory access request.

[0101] In the technical solution provided in this application embodiment, by first performing a kernel-level barrier check on the memory access request and then performing a token permission check, the security of the first kernel's memory access to the first region is maximized through the double check.

[0102] This application performs a double-checked authentication process upon receiving a memory access request before executing the corresponding access operation. Specifically, for a memory access request to a first region of memory initiated by a first kernel, a kernel-level barrier check is first performed on the first kernel to check if it has access permissions to the first region. If the first kernel has access permissions to the first region, a token permission check is then performed on the first kernel to check if it possesses a valid authorization token corresponding to the first region. If the first kernel possesses a valid authorization token corresponding to the first region, the access operation to the first region is executed according to the memory access request. Through this double-checked authentication, access operations to the first region can only be executed according to the memory access request if the first kernel has both access permissions to the first region and a valid authorization token corresponding to the first region, thus achieving memory protection. In this application, the kernel-level barrier is responsible for isolation, and the token permission is responsible for authorization. Through the coordinated control between the two, it is ensured that memory access requests are only permitted if they are not isolated (have access permissions) and possess the corresponding token (have a valid authorization token), thereby achieving memory protection and improving the security and reliability of memory access.

[0103] Please refer to Figure 4 The diagram illustrates a flowchart of a memory protection method provided in another embodiment of this application. The execution entity for each step of this method can be the aforementioned computer device. The method may include at least one of the following steps (410-450).

[0104] Step 410: Receive a memory access request initiated by the first kernel of the operating system. The memory access request is used to request access to the first region of memory.

[0105] Step 420: Based on the subject information and region information included in the memory access request, obtain the first barrier information from the kernel-level barrier information.

[0106] In some embodiments, kernel-level barrier information includes at least one barrier information, each barrier information indicating whether a kernel of the operating system has access to a region of memory; the first barrier information is the barrier information corresponding to the first kernel and the first region.

[0107] For example, the number of barrier information entries is determined based on the number of kernels included in the operating system and the number of memory regions. Optionally, where I represents the number of kernels included in the operating system and J represents the number of memory regions, the number of barrier information entries is I*J, where I and J are positive integers.

[0108] Optionally, each barrier information can also be used to indicate whether an operating system kernel has access to at least two regions of memory. Optionally, in this case, the number of barrier information is less than I*J.

[0109] Optionally, each barrier message can also be used to indicate whether at least two kernels of the operating system have access to a region of memory. Optionally, the number of barrier messages is less than I*J.

[0110] This application does not limit the representation format of nuclear-level barrier information. Optionally, nuclear-level barrier information may be in matrix form, tabular form, or database form at least one of these.

[0111] Optionally, the kernel-level barrier information is an I*J kernel-level barrier matrix, where I and J are positive integers, I representing the number of kernel bodies included in the operating system, and J representing the number of memory regions. Optionally, the matrix element in the i-th row and j-th column of this kernel-level barrier matrix corresponds to a barrier information, where i is a positive integer less than or equal to I, and j is a positive integer less than or equal to J. Optionally, the i-th row corresponds to the i-th kernel body in the operating system, and the j-th column corresponds to the j-th region in memory. Optionally, the matrix elements in the i-th row and j-th column are used to indicate whether the i-th kernel body has access rights to the j-th region of memory.

[0112] Optionally, the kernel-level barrier information is an I-row, J-column kernel-level barrier table, where I and J are positive integers, I representing the number of kernel bodies included in the operating system, and J representing the number of memory regions. Optionally, the table element (one cell) in the i-th row and j-th column of this kernel-level barrier matrix corresponds to one barrier information, where i is a positive integer less than or equal to I, and j is a positive integer less than or equal to J. Optionally, the i-th row corresponds to the i-th kernel body in the operating system, and the j-th column corresponds to the j-th region in memory. Optionally, the table elements in the i-th row and j-th column are used to indicate whether the i-th kernel body has access rights to the j-th region of memory.

[0113] Optionally, kernel-level barrier information is a portion of data recorded in a database. Optionally, this database can be a static database or a dynamic database. Optionally, kernel-level barrier information includes at least one barrier piece of information, each barrier piece of information used to indicate whether an operating system kernel has access rights to a region of memory. Optionally, at least one barrier piece of information is recorded in the database.

[0114] In this embodiment, the first barrier information is retrieved from the kernel-level barrier information based on the subject information and region information included in the memory access request. Optionally, the first barrier information is retrieved from the kernel-level barrier information using the kernel subject indicated by the subject information and the region indicated by the region information as indexes.

[0115] The kernel-level barrier information in this application is pre-configured and can be dynamically changed. Optionally, the kernel-level barrier information changes accordingly when the number of kernel bodies changes. Optionally, the kernel-level barrier information changes accordingly when the number of memory regions changes. Optionally, the kernel-level barrier information is obtained by pre-determining whether a kernel has access permissions to a memory region for at least one kernel body included in the operating system and at least one memory region.

[0116] Step 430: Obtain the first inspection result based on the first barrier information.

[0117] Optionally, the first check result is determined based on the value of the first barrier information. Optionally, if the value of the first barrier information is a first value, the first check result is determined to be that the first kernel has access rights to the first region. Optionally, if the value of the first barrier information is a second value, the first check result is determined to be that the first kernel does not have access rights to the first region.

[0118] Optionally, taking the nuclear-level barrier information as a nuclear-level barrier matrix as an example, the matrix elements in the i-th row and j-th column are represented as follows: Optionally, if If the value is the first value, then the first check result is determined to be that the first kernel has access permissions to the first region. Optionally, if If the value is the second value, then the first check result is determined to be that the first kernel does not have access to the first region. Optionally, the first value is 1 and the second value is 0. For example, if If so, the token checking phase continues. If the access fails, access will be denied directly, triggering the access failure handling process.

[0119] For example, constructing a core-level barrier (CLB):

[0120]

[0121] in, Represents the kernel body set, This represents the set of regions included in memory. Represents the kernel body set The kernel body in , Represents a set of regions The memory region m in the memory. This indicates the kernel body. It is possible to access memory domains by bypassing barriers. , Represents the kernel body Unable to access memory domains across the barrier In other words, access is blocked by a barrier. The kernel-level barrier here can also be considered as kernel-level barrier information.

[0122] Optionally, for insecure subjects (i.e., insecure kernels):

[0123]

[0124] This means that non-secure kernels cannot bypass kernel-level barriers to access secure areas. Among these, For a secure kernel, This is a private security domain. A non-secure kernel is any kernel other than a secure kernel.

[0125] Step 440: If the first check result indicates that the first kernel has access permissions to the first region, perform a token permission check on the first kernel to obtain a second check result.

[0126] Step 450: If the second check result indicates that the first kernel has a valid authorization token corresponding to the first region, perform an access operation on the first region according to the memory access request.

[0127] The technical solution provided in this application obtains first barrier information from kernel-level barrier information based on subject information and region information to determine the first check result. This application, by pre-configuring kernel-level barrier information, directly retrieves the first barrier information from the kernel-level barrier information using the first kernel and the first region as indexes when determining the first check result, thus determining whether the first kernel has access rights to the first region. Therefore, this application improves the efficiency of obtaining first barrier information and the efficiency of kernel-level barrier checks, thereby improving the processing efficiency for memory access requests.

[0128] Please refer to Figure 5 The diagram illustrates a flowchart of a memory protection method provided in another embodiment of this application. The execution entity for each step of this method can be the aforementioned computer device. The method may include at least one of the following steps (510-550).

[0129] Step 510: Receive a memory access request initiated by the first kernel of the operating system. The memory access request is used to request access to the first region of memory.

[0130] Step 520: Based on the memory access request, perform a kernel-level barrier check on the first kernel to obtain the first check result; wherein, the kernel-level barrier check is used to determine whether the first kernel has access permissions to the first region.

[0131] The explanations for steps 510 and 520 in the above embodiments are provided and will not be repeated here.

[0132] Step 530: If the first check result indicates that the first kernel has access permissions to the first region, obtain the first authorization token from the token permission information based on the subject information, region information, and operation permission information included in the memory access request.

[0133] The token permission information includes at least one authorization token and the token level of each authorization token. Each authorization token is used to indicate the operation permissions that a kernel of the operating system has for a region of memory. The first authorization token is the authorization token corresponding to the first kernel and the first region.

[0134] Optionally, referring to the above explanation of kernel-level barrier information, this application does not limit the representation format of token permission information. Optionally, token permission information can be at least one of matrix form, table form, and database form.

[0135] Optionally, at least one authorization token and the token level of each authorization token are pre-configured to obtain token permission information. Optionally, at least one authorization token is pre-configured for the operation permissions that at least one kernel of the operating system has for at least one region of memory.

[0136] In this embodiment, the first authorization token is retrieved from the token permission information based on the subject information, region information, and operation permission information included in the memory access request. Optionally, the first authorization token information is retrieved from the token permission information using the kernel subject indicated by the subject information, the region indicated by the region information, and the operation permissions as indexes. Optionally, using... In , , Use the index to find the token. Optionally, if it exists... , , If a matching token is found, it is determined to be the first authorization token. Alternatively, if no matching token is found, it is determined that no first authorization token exists.

[0137] The token permission information in this application is pre-configured and can be dynamically changed. Optionally, the token permission information changes when the number of kernel bodies changes. Optionally, the token permission information changes when the number of memory regions changes. Optionally, the token permission information changes when the operation permissions change. Optionally, for at least one kernel body, at least one memory region, and at least one operation permission included in the operating system, an authorization token is obtained in advance based on an access permission of one kernel for one region. The token permission information is obtained by traversing at least one kernel body, at least one region, and at least one operation permission. Optionally, each token includes the operation permissions that a kernel has for one memory region.

[0138] Optionally, the first authorization token is an authorization token corresponding to the first kernel and the first region. Optionally, the first authorization token is a token held by the first kernel for the first region.

[0139] In some embodiments, tokens have token levels. Optionally, token levels include at least two of the following levels: highest access level, allowing access to all regions of memory; restricted access level, allowing access after confirmation by the operating system's security kernel; functionally restricted level, allowing access only to the first page table in memory; temporary access level, allowing temporary access to the first region of memory; and ownership transfer level, allowing the transfer of permissions to a second region of memory.

[0140] In some embodiments, a multi-level token authorization system (HT) is constructed. Optionally, the token includes at least one of the following levels: Root Token, Host Token, Guest Token, Shared Token, and Transfer Token.

[0141] Optionally, the Root Token corresponds to the token with the highest access level, representing the highest level of access to the secure kernel. That is, for the secure kernel, access to all areas of memory is allowed.

[0142] Optionally, the Host Token corresponds to a token with a restricted access level, indicating restricted access that is only permitted after confirmation by the security kernel.

[0143] Optionally, the Guest Token corresponds to a token with a limited functionality level, indicating that functionality is restricted and access is limited to its own page (i.e., the first page table). Optionally, the first page table is a pre-defined page table, such as the current process's own page table, and there are no restrictions on the specific type of the first page table.

[0144] Optionally, the Shared Token corresponds to a token for temporary access levels, representing temporary shared access permissions. Optionally, temporary access to the first region in memory is allowed. Optionally, the first region is also a pre-defined region, and there are no restrictions on the specific type of the first region.

[0145] Optionally, the Transfer Token corresponds to a token for ownership transfer level, indicating secure ownership transfer. Optionally, it allows the transfer of permissions to a second region in memory. Optionally, the second region is also a pre-defined region, and the specific type of the first region is not limited.

[0146] In some embodiments, token permission information is represented as a set. Optionally, the token permission information is a token set. In some embodiments, the token set... as follows:

[0147]

[0148] In some embodiments, each token includes at least one of the following: the kernel body possessing the token, the memory region that the kernel body is allowed to access, the operation permissions for the region, the validity period of the token, and the state of the token.

[0149] Optionally, each token is a 5-tuple. Optionally, tokens .in, This indicates that the token is possessed. kernel body , This indicates the kernel body. Allowed memory regions , Represents the kernel body For regions in memory Access permissions, Indicates the validity period of the token. Indicates the state of the token.

[0150] Optionally, .in, Indicates read permission. Indicates write permission. Indicates execution permission. Indicates read and write permissions. Indicates read and execute permissions. Indicates read, write, and execute permissions.

[0151] Optionally, the token's status includes at least one of the following: valid, revoked, suspended, and frozen.

[0152] For example, the token should include at least one of the following: the kernel body to be accessed, the accessible range, permission information, time limit information, usage limit, binding context, and token state information. Optionally, in the case of an operating system with two kernels, the kernel bodies are already differentiated, so the binding context information is not considered. Also, considering that the usage limit is relatively unimportant, a quintuple consisting of the other five items is selected as the information contained in the token.

[0153] Step 540: Obtain the second check result based on the token level of the first authorization token.

[0154] In some embodiments, after obtaining the first authorization token, the token level corresponding to the first authorization token is determined. Optionally, the token levels corresponding to different tokens are also pre-stored. Optionally, the token level can be dynamically changed. Optionally, the token level corresponding to the first authorization token can be obtained directly. Optionally, if the first authorization token does not exist, the second check result is determined to be that the first kernel does not have a valid authorization token corresponding to the first region.

[0155] Optionally, a second check result is obtained based on whether the token level of the first authorization token reaches a preset level. Optionally, if the token level corresponding to the first authorization token reaches the preset level, the second check result is determined to be that the first kernel possesses a valid authorization token corresponding to the first region. Conversely, if the token level corresponding to the first authorization token does not reach the preset level, the second check result is determined to be that the first kernel does not possess a valid authorization token corresponding to the first region.

[0156] Optionally, a second check result is obtained based on whether the token level of the first authorization token belongs to a preset level range. Optionally, if the token level corresponding to the first authorization token belongs to the preset level range, the second check result is determined to be that the first kernel possesses a valid authorization token corresponding to the first region. Conversely, if the token level corresponding to the first authorization token does not belong to the preset level range, the second check result is determined to be that the first kernel does not possess a valid authorization token corresponding to the first region.

[0157] Optionally, a second check result is obtained based on the token level and validity of the first authorization token. Optionally, if the token level of the first authorization token reaches a preset level and the first authorization token is valid, the second check result is determined to be that the first kernel possesses a valid authorization token corresponding to the first region. If the token level of the first authorization token reaches the preset level, but the first authorization token is invalid, the second check result is determined to be that the first kernel does not possess a valid authorization token corresponding to the first region. If the token level corresponding to the first authorization token is within a preset level range and the first authorization token is valid, the second check result is determined to be that the first kernel possesses a valid authorization token corresponding to the first region. If the token level corresponding to the first authorization token is within a preset level range, but the first authorization token is invalid, the second check result is determined to be that the first kernel does not possess a valid authorization token corresponding to the first region.

[0158] Step 550: If the second check result indicates that the first kernel has a valid authorization token corresponding to the first region, perform an access operation on the first region according to the memory access request.

[0159] The technical solution provided in this application obtains a first authorization token from token permission information based on subject information, region information, and operation permission information to determine the second check result. This application, by pre-configuring token permission information, directly retrieves the first authorization token from the token permission information using subject information, region information, and operation permission information as indexes when determining the second check result, thereby determining whether the first kernel possesses a valid authorization token corresponding to the first region. Therefore, this application improves the efficiency of obtaining the first authorization token and the efficiency of token permission checks, thereby improving the processing efficiency for memory access requests.

[0160] In some embodiments, the combined formula for the above two checks is as follows: .

[0161] in, This indicates that the memory access request is allowed. The corresponding access operations, Indicates that, This indicates that it exists. Indicates belonging to, Indicates that it is included in, This represents the kernel body of token t. This represents the memory region corresponding to token t. This indicates the operation permissions of token t. This indicates the permission permissions requested by the memory access request. Indicates the state of token t. This indicates that the status is valid. Optionally, if... =1, and Then the memory access request is allowed. The corresponding access operation.

[0162] Specifically, the kernel body ( (The identifier or index of the token) is the region in memory to be accessed. and with operation permissions To perform the operation, the kernel-level barrier must be satisfied simultaneously, allowing the kernel body to do so. Access Area (i.e. Furthermore, a valid token must exist in the token system to grant this access permission. Only when both conditions are met can the memory access request be allowed. In other words, the first check result must be that the first kernel has access permission to the first region, and the second check result must be that the first kernel has a valid authorization token corresponding to the first region, in order to allow the execution of the memory access request.

[0163] In some embodiments, a second check result is obtained based on the token level of the first authorized token and the token level required by the first region.

[0164] Optionally, if the token level of the first authorization token belongs to the token level range required by the first region, then the second check result is determined to be that the first kernel has a valid authorization token corresponding to the first region.

[0165] Optionally, if the token level of the first authorization token reaches the minimum token level required by the first region, then the second check result is determined to be that the first kernel has a valid authorization token corresponding to the first region.

[0166] Optionally, the minimum token level is the lowest required token level for the first region. Optionally, the minimum token level required for the first region is pre-configured for the first region. Optionally, the minimum token level setting differs for different regions in memory. Optionally, regions with higher security requirements (relatively sensitive objects) have higher minimum token levels. Optionally, regions with lower security requirements have lower minimum token levels.

[0167] For example, perform a token permission check. Obtain the kernel. The token level held by (that is, the first kernel) To obtain the minimum token level required for the target memory region (i.e., the first region). The two levels of information are compared to determine whether the conditions are met:

[0168]

[0169] In some embodiments, if the second check result indicates that the token level held by the first kernel meets the minimum token level required by the first region, and the first authorized token meets the validity conditions, the step of performing an access operation on the first region according to the memory access request is executed. Here, the token level held by the first kernel can be the token level of a token possessed (or held) by the first kernel. Optionally, the token level held by the first kernel is the token level of the first authorized token.

[0170] For example, if the first authorization token reaches the minimum token level required by the first region and the first authorization token meets the validity conditions, it is determined that the first kernel has a valid authorization token corresponding to the first region, and the step of performing an access operation on the first region according to the memory access request is executed.

[0171] For example, the token level held by the first kernel reaching the minimum token level required by the first region means that the token level of the first authorized token is greater than or equal to the minimum token level required by the first region. That is, .

[0172] In some embodiments, if the second check result indicates that the token level held by the first kernel does not meet the minimum token level required by the first region, and / or the first authorized token does not meet the validity conditions, the memory access request is rejected.

[0173] For example, if the first authorization token does not meet the minimum token level required by the first region, it is determined that the first kernel does not have a valid authorization token corresponding to the first region, and the memory access request is rejected.

[0174] For example, if the first authorization token does not meet the validity conditions, it is determined that the first kernel does not have a valid authorization token corresponding to the first region, and the memory access request is rejected.

[0175] For example, if the first authorization token does not meet the minimum token level required by the first region and the first authorization token does not meet the validity conditions, it is determined that the first kernel does not have a valid authorization token corresponding to the first region, and the memory access request is rejected.

[0176] For example, the token level held by the first kernel not meeting the minimum token level required by the first region means that the token level of the first authorized token is lower than the minimum token level required by the first region. That is, .

[0177] The valid conditions include at least one of the following: the first authorization token has not expired, and the token status of the first authorization token is valid.

[0178] Optionally, the first authorization token is considered valid if it has not expired. Optionally, the first authorization token is considered valid if its token status is valid. Optionally, the first authorization token is considered valid if it has not expired and its token status is valid.

[0179] The technical solution provided in this application constructs a token level system and introduces token permission checks after kernel-level barrier checks. The multi-level token authorization system (i.e., the token level system, which consists of tokens of different token levels) matches the token level with the sensitivity level of the accessed object (the lowest token level required by the first area) layer by layer. Through this complete link consisting of dual verification of access requests and intelligent authorization decisions, higher stability, controllability, and security reliability are achieved in memory access control.

[0180] In some embodiments, a mapping check is performed on the first region to obtain a third check result; wherein the mapping check is used to determine whether the first region is effectively mapped; if the third check result indicates that the first region is effectively mapped, the access operation indicated by the memory access request is performed on the first region.

[0181] Optionally, performing a mapping check on the first region means determining in memory, based on the memory access request, whether the third region indicated by the memory access request exists in memory. Optionally, if it exists, it is considered a valid mapping; if it does not exist, it is considered an invalid mapping.

[0182] Optionally, if the third check result indicates that the first region is effectively mapped, the access operation indicated by the memory access request is performed on the first region.

[0183] Optionally, if the third check results in the first region being invalidally mapped, the memory access request is rejected.

[0184] Specifically, a mapping check and actual access are performed to confirm whether the target field (i.e., the first region) in the page table is effectively mapped. If the page table entry does not exist or is marked as invalid, a page fault exception is triggered, and the failure handling process is initiated. If the mapping is valid, the instruction is allowed to continue execution, the execution permission verification is passed, and the access operation is completed.

[0185] In addition to the double-checking, this application's embodiments introduce a mapping check to ensure that the access operation corresponding to the memory access request can be implemented in memory. This triple check maximizes the protection of memory access accuracy and avoids the possibility of memory access errors.

[0186] In some embodiments, when a memory access request is denied, event content information related to the memory access request is recorded. The event content information is used to indicate the memory access request initiated by the first kernel and the corresponding check result. Based on the event content information, the exception handling process corresponding to the memory access request is executed.

[0187] The event content information is information related to the memory access request. The event content information includes at least one of the following: first check result, second check result, third check result, subject information, region information, operation permission information, and token level.

[0188] For example, the problem type is determined based on the event content information. Optionally, different exception handling procedures are executed for the memory access request corresponding to different problem types. Optionally, the first kernel itself executes different exception handling procedures for the memory access request corresponding to different problem types. Optionally, the exception handling procedure can also be executed by the security kernel. Optionally, the problem type corresponding to the memory access request is sent to the security kernel, and the security kernel executes the exception handling procedure corresponding to the memory access request based on the problem type. Optionally, the exception handling procedure includes at least one of the following: killing the unauthorized task, downgrading the token, triggering a system alarm, etc.

[0189] For example, regardless of the reason for the access failure (i.e., the memory access request is denied), this processing flow will be triggered, and the failure event content will be recorded. The event content information includes at least one of the following: the kernel that initiated the request, the memory domain, the access type, the kernel-level barrier result (i.e., the first check result), the token level information, the request information, and the timestamp. Optionally, the kernel will trigger a synchronization exception, a page fault, or an error return, depending on whether it is an illegal MMIO access, a page table out of bounds access, or an illegal access to a high-security domain, and switch to the security kernel to resolve the issue. After the security kernel takes over, it will continue to perform operations such as canceling the privilege escalation task, downgrading the token, and triggering system alarms.

[0190] The technical solution provided in this application, when a memory access request is denied, records event content information related to the memory access request and executes the exception handling process corresponding to the memory access request based on the event content information. Based on this, this application improves the memory access request processing mechanism, ensuring that even if a memory access request is denied, event content information can be recorded, and subsequent exception handling processes can be triggered promptly, thereby improving request processing efficiency.

[0191] In some embodiments, a token distribution request initiated by a second kernel of the operating system is received. The token distribution request is used to apply for or upgrade the token level held by the second kernel.

[0192] The second kernel and the first kernel in this application can be the same kernel or different kernels. Optionally, the second kernel can be a host kernel or a security kernel.

[0193] Optionally, the token distribution request includes at least one of the following: subject information, token level, the token level to which the request is made or upgraded, and the reason for making or upgrading the token level held by the second kernel.

[0194] Optionally, the token distribution request is represented in the form of a triple. Optionally, the token distribution request... It is expressed as follows:

[0195]

[0196] in, This indicates the second kernel (i.e., the low-level kernel). This indicates the token level that needs to be applied for or upgraded. This indicates the reason for requesting or upgrading the token level held by the second kernel.

[0197] In some embodiments, the reasons for requesting or upgrading the token level held by the second kernel include at least one of the following: modifying the shared area page table, activating a device, or accessing high-security memory.

[0198] In some embodiments, a permission check is performed on the second kernel according to the token distribution request to obtain a fourth check result; wherein the permission check is used to determine whether the second kernel has the permission to request or upgrade the token level held by the second kernel.

[0199] Optionally, based on at least one of the following: the principal information of the second kernel, the reason for requesting or upgrading the token level held by the second kernel, and the token level currently possessed by the second kernel, it is determined whether the second kernel has the authority to request or upgrade the token level held by the second kernel. Optionally, the fourth check result includes at least one of the following: the second kernel has the authority to request or upgrade the token level held by the second kernel, or the second kernel does not have the authority to request or upgrade the token level held by the second kernel.

[0200] In some embodiments, if the fourth check result indicates that the second kernel has the authority to request or upgrade the token level held by the second kernel, a new token level is determined to be issued to the second kernel.

[0201] Optionally, the token distribution request can be processed by a high-level kernel in the operating system. Optionally, the high-level kernel is a secure kernel, or a kernel other than a secure kernel. Optionally, the high-level kernel is a pre-configured kernel.

[0202] Optionally, upon receiving a token distribution request, the higher-level kernel checks whether the request's source is permitted, whether there is any unauthorized behavior, and whether security policy restrictions have been triggered. If distribution is not permitted, a rejection is returned. If distribution is permitted, the next step of token distribution is performed. When the token expires, it needs to be destroyed after the expiration conditions are met.

[0203] Optionally, upon receiving a request, the high-level kernel checks the legitimacy of the request's source and distributes tokens of different levels, such as temporary tokens, session tokens, and long-term tokens, according to the token distribution policy, and promptly destroys the tokens after the conditions expire.

[0204] Optionally, the high-level kernel may issue temporary tokens based on a policy, when the token is valid only once or for a short period. Session tokens may be issued when the token is valid during an IPC session. Long-term tokens may be issued for subsystem-level operations.

[0205] Optionally, when the token meets the expiration conditions of the request task ending, session termination, timeout, or access end event, the system will perform a token destruction operation.

[0206] For example, the highest token level of the new token level of the second kernel is determined based on the token level currently held by the second kernel and the level upgrade limit step of the token level.

[0207] Optionally, the step size for increasing token level is also preset. Optionally, upon receiving a token distribution request, the step size for increasing token level is obtained.

[0208] Optionally, the sum of the token level currently held by the second kernel and the level upgrade limit step of the token level can be used as the highest token level of the new token level of the second kernel.

[0209] For example, if the token level requested in the token distribution request is lower than or equal to the highest token level, the token level requested in the token distribution request is determined as the new token level to be issued to the second kernel.

[0210] That is, the level increase of each token does not exceed the level increase limit step size. Optionally, if the difference between the token level requested in the token distribution request and the token level currently held by the second kernel is less than or equal to the level increase limit step size, it means that the level increase does not exceed the level increase limit step size, and the token level requested in the token distribution request can be directly determined as the new token level issued to the second kernel.

[0211] For example, if the token level requested in the token distribution request is higher than the highest token level, the highest token level is determined as the new token level to be issued to the second kernel.

[0212] Conversely, if the difference between the token level requested in the token distribution request and the token level currently held by the second kernel is greater than the level upgrade limit step size, it means that the level upgrade amount exceeds the level upgrade limit step size. In this case, the token level needs to be upgraded according to the level upgrade limit step size. That is, the maximum value of each level upgrade amount is the level upgrade limit step size. Of course, after performing a token level upgrade, a token distribution request can be sent again to continue upgrading the token level, but each token level upgrade amount cannot exceed the level upgrade limit step size.

[0213] In some embodiments, a higher-level kernel, based on access requirements, elevates the token level of a lower-level kernel to a higher level, granting it temporary access rights. It can be represented as:

[0214]

[0215] This indicates the token level that needs to be applied for or upgraded. Indicates the token level of the current token. This indicates the safe step size (i.e., the step size that limits the level increase).

[0216] Optionally, the token upgrade cannot exceed the security permission value (i.e., the level upgrade limit step size). The final level obtained is the minimum of the target level and the current level plus the security step size. It is not allowed to break through to a higher level instantly without authorization.

[0217] Optionally, the upgraded token level cannot exceed the target level, and the upgrade process cannot skip levels or achieve excessively high privileges in one step. Furthermore, the upgrade process must be monotonically continuous, meaning it must satisfy... .

[0218] Optionally, upgrades require a binding context, which must include information on accessing memory, CPU (Central Processing Unit) or vCPU (virtual Central Processing Unit), request session, and token validity period. Furthermore, upgrades must meet audit traceability requirements, writing each upgrade action to an audit log.

[0219] Optionally, based on access requirements, a low-level token can be upgraded to a higher level to grant temporary access rights. The upgrade cannot exceed the security permission value, the upgraded token level cannot exceed the target level, and no level can be skipped during the upgrade process. Each upgrade action is written to the audit log.

[0220] The technical solution provided in this application allows for dynamic token upgrades, demonstrating the flexibility and comprehensiveness of the token level system. Upon receiving a token distribution request, a permission check is performed, and the token level is only upgraded after the check passes. Based on this, this application demonstrates the rationality and accuracy of token upgrades. Finally, when upgrading the token level, each upgrade is not allowed to exceed a safe step size, preventing instantaneous breakthroughs to higher levels and demonstrating the stability and security of the token upgrade system.

[0221] In some embodiments, such as Figure 6 The image shows a memory protection method provided in one embodiment of this application, which includes at least one of the following steps S1 to S12.

[0222] Step S1: The kernel initiates an access request.

[0223] Before executing step S1, system initialization must be performed.

[0224] Step S2: Determine if the memory access is legal?

[0225] If valid, proceed to step S3. If invalid, proceed to step S6.

[0226] Step S3: Token system verification.

[0227] Step S4, Has the access check passed?

[0228] If successful, proceed to step S5. If unsuccessful, proceed to step S6.

[0229] Step S5: Return success to the caller.

[0230] Step S6: Submit the event to the audit module.

[0231] Step S7: Do I need to upgrade the token?

[0232] If necessary, proceed to step S8. If not, proceed to step S2.

[0233] Step S8: Verify the legitimacy of the request.

[0234] Step S9, nuclear-level barrier check.

[0235] Step S10: Generate a new token.

[0236] Step S11: Record the token issuance event.

[0237] Step S12: Return the upgrade result.

[0238] Optionally, a memory protection method provided in one embodiment of this application includes at least one of the following steps S101 to S204 (not shown in the figure).

[0239] Step S101: Construct a dual-kernel architecture kernel-level barrier (CLB). . This indicates the subject It is possible to access memory domains by bypassing barriers. , This indicates that access was directly blocked by the barrier. That is, for insecure entities: This means that non-secure kernels cannot bypass kernel-level barriers to access secure regions.

[0240] Page table fields in step S101 It is a collection of page tables at all levels. A shared domain refers to a memory domain that is mapped jointly by two kernels. A security domain refers to a private domain belonging to a high-privilege kernel.

[0241] Step S102: Construct a multi-level token authorization system (HT). Each memory access authorization is divided into multiple levels, with the following token set: Each token Access request The final access determination formula for dual agreements is: This formula represents the main body. To access the memory domain Whether access is permitted depends on whether a kernel-level barrier is simultaneously satisfied to allow the subject to access the memory domain, and whether a valid token exists in the token system to grant this access permission.

[0242] Step S103: Based on the CLB and HT models obtained in step S102, execute the flow to initiate access. Currently running kernel. Accessing a memory region At that time, memory access request This memory access determination process includes the following steps.

[0243] Step S201, Nuclear-level barrier check. The system queries the barrier matrix information (i.e., nuclear-level barrier information). .when Continue with the token permission check; if If not, access will be denied directly, and the access will fail.

[0244] Step S202, Token Permission Check. Obtain Token Level To obtain the minimum level requirement Determine if the following conditions are met: If the conditions are not met, access is denied and the access fails. If the conditions are met, access is granted.

[0245] Step S203: Perform mapping checks and actual access to confirm whether the target domain has been effectively mapped and complete the access operation.

[0246] Step S204: Access failure event auditing, record the content of the failure event, and the kernel will trigger error exceptions according to different condition branches and perform corresponding operations.

[0247] In some embodiments, such as Figure 7 The operating system described herein employs a multi-layered memory protection structure, comprising user space (layer 710), a low-level kernel (EL1 layer, also known as layer 720), a high-level kernel (EL2 layer, also known as layer 730), a kernel-level barrier, and a multi-level token scheduling system. Applications in the user space layer initiate access requests, which are then trapped in EL1 through the kernel space. After virtualization scheduling, EL1 uniformly hands the request over to EL2 for processing. EL2 uses the kernel-level barrier to enforce access interception and, combined with the multi-level token system, performs dynamic authorization and context evaluation of access permissions, thereby achieving intelligent management of cross-permission access paths. During runtime, access behavior, token status, and risk information are continuously monitored. Tokens are upgraded or destroyed according to security policies, and the kernel-level barrier is used to achieve least privilege access and strict isolation control. This application constructs a closed-loop management system covering access authorization, interception, dynamic trust, and audit tracing, forming a clear dual-kernel security framework, significantly improving the security and controllability of memory access in the virtualization environment.

[0248] In some embodiments, such as Figure 8 In the operating system shown, the entire memory access chain is divided into three key layers: the low-level kernel (EL1) 810, the kernel-level barrier (EL1→EL2 transition zone), and the secure kernel (EL2) 820. In a virtualized environment, memory access requests are typically diverse, and access behavior is not only related to the nature of the task but also involves cross-kernel operations between different security domains. The kernel-level barrier is a strong isolation checkpoint between EL1 and EL2, responsible for intercepting all access requests from the low-level kernel to the high-level kernel, forcing all sensitive operations to be executed through authorized paths. Upon entering EL2, a multi-level token authorization system matches token levels with the sensitivity level of the accessed object layer by layer. Through this complete chain consisting of dual verification of access requests and intelligent authorization decisions, the operating system achieves higher stability, controllability, and security reliability in access control.

[0249] In some embodiments, such as Figure 9 The diagram illustrates the memory protection method. During system startup, the security kernel is initialized first, including building a kernel-level barrier matrix, initializing a multi-level token system, and initializing a page table system. Optionally, the audit module is started, the system enters runtime, and prepares to capture memory access requests. Captured memory access requests are evaluated based on kernel-level barrier verification (or checks), multi-level token level verification (or checks), and page table consistency verification rules to determine whether execution is permitted. Optionally, if access fails, an access denial event is generated and enters a unified audit process, submitted to the security kernel decision module to determine if it is abnormal behavior and whether to perform privilege compensation. When system policy requires escalation of privileges, a token upgrade process is triggered. After completing the legality verification, a new token is generated to continue access. Through a multi-level chain mechanism composed of a kernel-level barrier and a multi-level token system based on a dual-kernel structure, the system forms a complete closed-loop control process under normal operation. This ensures that access behavior maintains hardware-level isolation strength while possessing appropriate scalability within policy limits, thus balancing security, flexibility, and controllability in complex virtualization scenarios, achieving a highly reliable memory protection strategy.

[0250] When accessing memory in a virtualized system, related kernel security models typically rely on fixed-policy access control methods with coarse-grained authorization, making it difficult to simultaneously meet the performance requirements of ordinary access paths and the strict isolation requirements of high-security areas. Especially when facing cross-kernel-level access or temporary privilege escalation requests, related models struggle to balance security and flexibility, potentially leading to unauthorized access due to overly broad authorization or unnecessary blocking and performance degradation due to insufficient authorization. This application employs a memory protection method for a dual-kernel operating system. The dual-kernel structure achieves physical logical isolation, while the introduced kernel-level barrier acts as a mandatory control point for cross-kernel access, enabling structured verification of all sensitive accesses and reducing the attack surface caused by malicious kernel behavior. Furthermore, this application's multi-level token authorization model constructs a multi-level token permission system from low to high privileges, achieving dynamic and fine-grained permission scheduling. This transforms access control from static policy matching into a real-time state-based security decision-making process.

[0251] This application proposes a memory protection method, apparatus, device, and storage medium. By constructing a kernel-level barrier between the low-level and high-level kernels, it achieves unified management and secure scheduling of cross-privilege level access. A multi-level token authorization system is introduced, forming a dynamically distributed and upgraded token management model. This ensures the system maintains efficiency and determinism when handling complex operation chains such as cross-level access, shared memory mapping, and device interaction. Based on the centralized auditing capabilities of the kernel-level barrier and the fine-grained authorization mechanism of the token system, the system can significantly reduce the risk of unauthorized access, improve the accuracy and traceability of access auditing, and enhance the overall security in scenarios where virtual machines and the kernel share memory. Simultaneously, this mechanism can significantly improve the flexibility and stability of access chains while maintaining strong isolation, effectively supporting multiple types, high frequencies, and highly dynamic access patterns in virtualized environments, making memory access more secure, efficient, and reliable in complex and ever-changing system scenarios. Overall, this application constructs a dynamic, adaptive, and verifiable memory access security system through a dual architecture of "kernel-level barrier + multi-level token," which not only improves system robustness but also provides a novel intelligent solution for access control in virtualized environments.

[0252] For example, the memory protection method proposed in this application was tested on the Linux kernel. To ensure the objectivity of the evaluation process, the experiment was conducted in a unified hardware environment: an 8-core processor was used, operating system A was running, and memory and solid-state drives were configured.

[0253] Furthermore, to simulate different levels of access permissions in a real system, various test scenarios were constructed, including: a normal access scenario: frequently triggering regular access requests from EL1 to low-privilege areas; a sensitive resource scenario: permission escalation requests involving page table updates, shared memory mappings, etc., requiring EL2 review; and a high-security access scenario: simulating access to high-security areas (such as the key buffer), triggering strict kernel-level barrier verification and multi-level token evaluation processes. The request ratios for the three scenarios were set to 60%, 30%, and 10% to closely resemble the workload structure of a real system.

[0254] The performance of this system was evaluated by observing metrics such as access authorization time from EL1 to EL2, accurate access denial rate, success rate of token distribution and token permission upgrade operations, and system overhead. Experimental results show that the dual-kernel memory protection method proposed in this application can effectively block unauthorized access, and all cross-privilege access must pass through the security control path of the higher kernel. The multi-level token system can dynamically adjust the authorization level according to the access type, significantly reducing the coarse-grained problem in related technologies. Comprehensive comparison shows that while strengthening memory isolation and permission auditing capabilities, this system still maintains high availability and performance stability, verifying the feasibility and superiority of the dual-kernel operating system memory protection method in complex virtualization environments.

[0255] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0256] Please refer to Figure 10 This diagram illustrates a block diagram of a memory protection device according to an embodiment of this application. The device has the functionality to implement the method example described above; this functionality can be implemented in hardware or by hardware executing corresponding software. The device can be the computer device described above, or it can be installed within a computer device. Figure 10 As shown, the device 1000 may include: a request receiving module 1010, a barrier checking module 1020, a token checking module 1030, and a request execution module 1040.

[0257] The request receiving module 1010 is used to receive a memory access request initiated by the first kernel of the operating system, wherein the memory access request is used to request access to a first region of memory.

[0258] The barrier checking module 1020 is used to perform a kernel-level barrier check on the first kernel according to the memory access request and obtain a first check result; wherein, the kernel-level barrier check is used to determine whether the first kernel has access rights to the first region.

[0259] The token checking module 1030 is used to perform a token permission check on the first kernel to obtain a second check result if the first check result indicates that the first kernel has access permissions to the first region; wherein the token permission check is used to determine whether the first kernel has a valid authorization token corresponding to the first region.

[0260] The request execution module 1040 is used to perform an access operation on the first region according to the memory access request if the second check result indicates that the first kernel has a valid authorization token corresponding to the first region.

[0261] In some embodiments, the memory access request includes: subject information, indicating that the subject initiating the memory access request is the first kernel; region information, indicating that the region requested for access is the first region; and operation permission information, indicating the operation permissions that the first kernel has for the first region.

[0262] In some embodiments, the barrier checking module 1020 is configured to obtain first barrier information from kernel-level barrier information based on the subject information and the region information included in the memory access request; wherein the kernel-level barrier information includes at least one barrier information, each barrier information being used to indicate whether a kernel of the operating system has access rights to a region of the memory; the first barrier information is barrier information corresponding to the first kernel and the first region; and the first check result is obtained based on the first barrier information.

[0263] In some embodiments, the token checking module 1030 is configured to obtain a first authorization token from the token permission information based on the subject information, the region information, and the operation permission information included in the memory access request; wherein the token permission information includes at least one authorization token and the token level of each authorization token, each authorization token being used to indicate the operation permissions possessed by a kernel of the operating system for a region of the memory; the first authorization token is an authorization token corresponding to the first kernel and the first region; and the second check result is obtained based on the token level of the first authorization token.

[0264] In some embodiments, if the second check result indicates that the token level held by the first kernel reaches the minimum token level required by the first region, and the first authorized token meets the validity conditions, the request execution module 1040 is configured to perform the step of performing an access operation on the first region according to the memory access request.

[0265] In some embodiments, if the second check result indicates that the token level held by the first kernel does not meet the minimum token level required by the first region, and / or the first authorization token does not meet the validity conditions, the request execution module 1040 is used to reject the memory access request; wherein the validity conditions include at least one of the following: the first authorization token has not expired, and the token status of the first authorization token is valid.

[0266] In some embodiments, the token level includes at least two of the following levels: highest access level, allowing access to all regions of the memory; restricted access level, allowing access after confirmation by the security kernel of the operating system; functionally restricted level, having access only to the first page table in memory; temporary access level, allowing temporary access to the first region of memory; and ownership transfer level, allowing the transfer of permissions to a second region of memory.

[0267] In some embodiments, the request execution module 1040 is configured to perform a mapping check on the first region to obtain a third check result; wherein the mapping check is used to determine whether the first region is effectively mapped; if the third check result indicates that the first region is effectively mapped, the access operation indicated by the memory access request is performed on the first region.

[0268] In some embodiments, the above-described device 1000 further includes an information recording module (not shown in the figure).

[0269] The information recording module is used to record event content information related to the memory access request when the memory access request is denied. The event content information is used to indicate the memory access request initiated by the first kernel and the corresponding check result. Based on the event content information, the exception handling process corresponding to the memory access request is executed.

[0270] In some embodiments, the operating system includes two or more kernels; and / or, the memory includes at least two of the following regions: physical memory region, virtual memory region, MMIO region, page table region, shared region, and private security region.

[0271] In some embodiments, the operating system includes two kernels: a security kernel for handling a first type of task and a host kernel for handling a second type of task; wherein the security requirements for the first type of task are higher than the security requirements for the second type of task.

[0272] In some embodiments, the device 1000 further includes a token upgrade module (not shown in the figure).

[0273] In some embodiments, the token upgrade module is configured to receive a token distribution request initiated by a second kernel of the operating system, the token distribution request being used to apply for or upgrade the token level held by the second kernel; perform a permission check on the second kernel according to the token distribution request, and obtain a fourth check result; wherein the permission check is used to determine whether the second kernel has the permission to apply for or upgrade the token level held by the second kernel; if the fourth check result indicates that the second kernel has the permission to apply for or upgrade the token level held by the second kernel, a new token level is determined to be issued to the second kernel.

[0274] In some embodiments, the token upgrade module is configured to determine the highest token level of the new token level of the second kernel based on the token level currently held by the second kernel and the level upgrade limit step size of the token level; if the token level requested by the token distribution request is lower than or equal to the highest token level, determine the token level requested by the token distribution request as the new token level to be issued to the second kernel; if the token level requested by the token distribution request is higher than the highest token level, determine the highest token level as the new token level to be issued to the second kernel.

[0275] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0276] Please refer to Figure 11 The diagram illustrates a structural block diagram of a computer device 1100 provided in one embodiment of this application. The computer device 1100 can be any electronic device capable of data computation, processing, and storage. The computer device 1100 can be used to implement the memory protection method provided in the above embodiments.

[0277] Typically, computer device 1100 includes a processor 1101 and a memory 1102.

[0278] Processor 1101 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1101 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1101 may also include a main processor and a coprocessor. The main processor, also known as the CPU, is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1101 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, processor 1101 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0279] The memory 1102 may include one or more computer-readable storage media, which may be non-transitory. The memory 1102 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1102 are used to store a computer program configured to be executed by one or more processors to implement the memory protection method described above.

[0280] Those skilled in the art will understand that Figure 11 The structure shown does not constitute a limitation on the computer device 1100 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0281] In an exemplary embodiment, a memory protection system is also provided, the memory protection system including a processor and a memory, the processor being programmed or configured to implement the memory protection method described above.

[0282] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program, when executed by a processor, implements the memory protection method described above. Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0283] In an exemplary embodiment, a computer program product is also provided, the computer program product including a computer program that, when executed by a processor, implements the memory protection method described above.

[0284] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0285] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A memory protection method, characterized in that, The method includes: The system receives a memory access request initiated by the first kernel of the operating system. The memory access request is used to request access to a first region of memory. The first kernel is a low-level kernel in the operating system. The operating system also includes a high-level kernel. The memory is the memory of the high-level kernel. The method is executed by the high-level kernel. Based on the memory access request, a kernel-level barrier check is performed on the first kernel to obtain a first check result; wherein, the kernel-level barrier check is used to determine whether there is a kernel-level barrier between the first kernel and the high-level kernel, and the kernel-level barrier is used to intercept the memory access request; If the first check result indicates that the kernel-level barrier does not exist, a token permission check is performed on the first kernel to obtain a second check result; wherein, the token permission check is used to determine whether the first kernel has a valid authorization token corresponding to the first region, and the token level held by the first kernel allows for dynamic upgrading after the permission check performed by the higher-level kernel passes, and the permission check is used to determine whether the first kernel has the permission to apply for or upgrade the token level held by the first kernel. If the second check result indicates that the first kernel possesses a valid authorization token corresponding to the first region, an access operation is performed on the first region according to the memory access request.

2. The method according to claim 1, characterized in that, The memory access request includes: The entity information is used to indicate that the entity initiating the memory access request is the first kernel; Region information, used to indicate that the requested region is the first region; Operation permission information is used to indicate the operation permissions that the first kernel has for the first region.

3. The method according to claim 2, characterized in that, The step of performing a kernel-level barrier check on the first kernel based on the memory access request to obtain a first check result includes: Based on the subject information and region information included in the memory access request, first barrier information is obtained from the kernel-level barrier information; wherein, the kernel-level barrier information includes at least one barrier information, each barrier information being used to indicate whether a kernel of the operating system has access rights to a region of the memory; the first barrier information is the barrier information corresponding to the first kernel and the first region; The first inspection result is obtained based on the first barrier information.

4. The method according to claim 2, characterized in that, The step of performing a token permission check on the first kernel to obtain a second check result includes: Based on the subject information, region information, and operation permission information included in the memory access request, a first authorization token is obtained from the token permission information; wherein, the token permission information includes at least one authorization token and the token level of each authorization token, each authorization token is used to indicate the operation permissions that a kernel of the operating system has for a region of the memory; the first authorization token is an authorization token corresponding to the first kernel and the first region; The second check result is obtained based on the token level of the first authorization token.

5. The method according to claim 4, characterized in that, The method further includes: If the second check result indicates that the token level held by the first kernel reaches the minimum token level required by the first region, and the first authorized token meets the validity conditions, then the step of performing the access operation on the first region according to the memory access request is executed. If the second check result indicates that the token level held by the first kernel does not meet the minimum token level required by the first region, and / or the first authorized token does not meet the validity conditions, the memory access request is rejected. The validity conditions include at least one of the following: the first authorization token has not expired, and the token status of the first authorization token is valid.

6. The method according to claim 4, characterized in that, The token levels include at least two of the following levels: The highest access level allows access to all regions of the memory. Access is restricted to a specific level, and access is granted only after verification by the operating system's security kernel. The functionality is restricted, granting access only to the first page table in the memory. Temporary access level, allowing temporary access to the first region in memory; Ownership transfer level, allowing the transfer of permissions for the second region in the memory.

7. The method according to claim 1, characterized in that, The step of performing an access operation on the first region according to the memory access request includes: A mapping check is performed on the first region to obtain a third check result; wherein the mapping check is used to determine whether the first region has been effectively mapped; If the third check result indicates that the first region is effectively mapped, the access operation indicated by the memory access request is performed on the first region.

8. The method according to claim 1, characterized in that, The method further includes: If the memory access request is denied, record event content information related to the memory access request. The event content information is used to indicate the memory access request initiated by the first kernel and the corresponding check result. Based on the event content information, execute the exception handling process corresponding to the memory access request.

9. The method according to claim 1, characterized in that, The operating system includes two or more kernels; and / or, The memory includes at least two of the following regions: physical memory region, virtual memory region, memory-mapped input / output (MMIO) region, page table region, shared region, and private security region.

10. The method according to claim 9, characterized in that, The operating system includes the following two kernels: The security kernel is responsible for handling the first type of tasks; The host kernel is responsible for handling the second type of task; The security requirements for the first type of task are higher than those for the second type of task.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: Receive a token distribution request initiated by the second kernel of the operating system, the token distribution request being used to apply for or upgrade the token level held by the second kernel; Based on the token distribution request, a permission check is performed on the second kernel to obtain a fourth check result; wherein, the permission check is used to determine whether the second kernel has the permission to request or upgrade the token level held by the second kernel; If the fourth check result indicates that the second kernel has the authority to apply for or upgrade the token level held by the second kernel, a new token level is determined to be issued to the second kernel.

12. The method according to claim 11, characterized in that, The determination of the new token level issued for the second kernel includes: Based on the token level currently held by the second kernel and the level upgrade limit step size of the token level, determine the highest token level of the new token level of the second kernel; If the token level requested in the token distribution request is lower than or equal to the highest token level, the token level requested in the token distribution request shall be determined as the new token level to be issued to the second kernel. If the token level requested in the token distribution request is higher than the highest token level, the highest token level is determined as the new token level to be issued to the second kernel.

13. A memory protection device, characterized in that, The device includes: The request receiving module is used to receive a memory access request initiated by the first kernel of the operating system. The memory access request is used to request access to a first region of memory. The first kernel is a low-level kernel in the operating system. The operating system also includes a high-level kernel. The memory is the memory of the high-level kernel. The memory protection process is executed by the high-level kernel. The barrier checking module is used to perform a kernel-level barrier check on the first kernel according to the memory access request and obtain a first check result; wherein, the kernel-level barrier check is used to determine whether there is a kernel-level barrier between the first kernel and the high-level kernel, and the kernel-level barrier is used to intercept the memory access request; The token checking module is used to perform a token permission check on the first kernel when the first check result indicates that the kernel-level barrier does not exist, and obtain a second check result; wherein, the token permission check is used to determine whether the first kernel has a valid authorization token corresponding to the first region, and the token level held by the first kernel is allowed to be dynamically upgraded after the permission check performed by the higher-level kernel passes; the permission check is used to determine whether the first kernel has the permission to apply for or upgrade the token level held by the first kernel. The request execution module is used to perform an access operation on the first region according to the memory access request if the second check result indicates that the first kernel has a valid authorization token corresponding to the first region.

14. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the memory protection method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the memory protection method as described in any one of claims 1 to 12.

16. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the memory protection method as described in any one of claims 1 to 12.

Images