A real-time operating system memory mapping and task level protection method

Abstract

The application discloses a real-time operating system memory mapping and task-level protection method, which comprises the following steps: in the case that platform basic data is acquired, a static page table is constructed based on the platform basic data; in the case that a reserved mapping window area is divided into a plurality of window units based on the platform basic data, a window descriptor table is determined; in the case that a memory mapping request of a target task is received, a mapping request record and an architecture-independent attribute descriptor of the target task are determined through a memory mapping interface; and based on the mapping request record, the architecture-independent attribute descriptor and the window descriptor table, a mapping window of the target task is determined, and a static page table entry in a static page table corresponding to the mapping window is updated, so that the security of memory mapping is improved.

Description

Technical Field

[0001] This application relates to the technical field of memory mapping and task-level protection in real-time operating systems, and in particular to a method for memory mapping and task-level protection in real-time operating systems. Background Technology

[0002] Existing lightweight real-time operating systems are primarily used in microcontrollers, edge controllers, industrial gateways, automotive controllers, or resource-constrained embedded terminals. These systems typically employ a flat address space model, where tasks share the same address space, emphasizing real-time scheduling, compact code size, and low runtime overhead. While this design is suitable for traditional microcontroller scenarios, it cannot effectively utilize the MMU's page-level mapping capabilities and access attribute control on high-performance embedded processor platforms with an MMU, resulting in lower memory mapping security. Summary of the Invention

[0003] This application aims to at least address the technical problems existing in the prior art. To this end, this application proposes a method for memory mapping and task-level protection in a real-time operating system, which can improve the security of memory mapping.

[0004] The first aspect of this application provides a method for memory mapping and task-level protection in a real-time operating system, comprising the following steps: Having acquired the platform's basic data, a static page table is constructed based on the platform's basic data, which includes the page size, the virtual address range of the reserved mapping window area, and the maximum number of concurrent mapping windows. Based on the platform's basic data, when the reserved mapping window area is divided into several window units, a window descriptor table is determined, wherein the window descriptor table includes a window descriptor corresponding to each window unit; Upon receiving a memory mapping request for a target task, the mapping request record and architecture-independent attribute descriptor for the target task are determined through the memory mapping interface. The mapping request record includes the task number and resource number of the target task, and the architecture-independent attribute descriptor includes the resource number, mapping mode, and a first protection attribute, which is read permission, write permission, and / or execute permission. Based on the mapping request record, the architecture-independent attribute descriptor, and the window descriptor table, the mapping window for the target task is determined, and the static page table entry in the static page table corresponding to the mapping window is updated.

[0005] A real-time operating system memory mapping and task-level protection method according to an embodiment of this application has at least the following beneficial effects: This application introduces a window-based memory mapping mechanism, effectively addressing the issues of insufficient MMU capability utilization and low memory mapping security in traditional flat address space models within real-time operating systems equipped with lightweight MMUs. By managing reserved mapping window areas and dynamically allocating mapping windows based on task requests, the system provides greater flexibility in memory management under resource-constrained environments, thereby improving overall memory mapping security.

[0006] A second aspect of this application provides a real-time operating system memory mapping and task-level protection system, the real-time operating system memory mapping and task-level protection system comprising: The data construction module is used to construct a static page table based on the platform's basic data, which includes the page size, the virtual address range of the reserved mapping window area, and the maximum number of concurrent mapping windows. The window descriptor table determination module is used to determine the window descriptor table when the reserved mapping window area is divided into several window units based on the platform basic data, wherein the window descriptor table includes the window descriptor corresponding to each window unit. The mapping request record and architecture-independent attribute descriptor determination module is used to determine the mapping request record and architecture-independent attribute descriptor of the target task through the memory mapping interface when a memory mapping request of the target task is received. The mapping request record includes the task number and resource number of the target task, and the architecture-independent attribute descriptor includes the resource number, mapping mode and a first protection attribute, wherein the first protection attribute is read permission, write permission and / or execution permission. The mapping window determination module is used to determine the mapping window of the target task based on the mapping request record, the architecture-independent attribute descriptor, and the window descriptor table, and update the static page table entry in the static page table corresponding to the mapping window.

[0007] This system effectively addresses the issues of insufficient MMU capability utilization and low memory mapping security in traditional flat address space models by introducing a window-based memory mapping mechanism within a real-time operating system equipped with a lightweight MMU. By managing reserved mapping window areas and dynamically allocating mapping windows based on task requests, the system provides greater flexibility in memory management under resource-constrained environments, thereby improving overall memory mapping security.

[0008] A third aspect of this application provides an electronic device including at least one processor and a memory for communicatively connecting to the processor; the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform a real-time operating system memory mapping and task-level protection method as described in the first aspect of this application.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions for causing a computer to perform a real-time operating system memory mapping and task-level protection method as described in the first aspect of this application.

[0010] It should be noted that the beneficial effects of the third and fourth aspects of this application compared with the prior art are the same as the beneficial effects of the above-mentioned method for real-time operating system memory mapping and task-level protection compared with the prior art, and will not be described in detail here.

[0011] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0012] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a flowchart illustrating an embodiment of the real-time operating system memory mapping and task-level protection method provided in this application; Figure 2 This is a schematic diagram of the structure of an embodiment of the real-time operating system memory mapping and task-level protection system provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the electronic device provided in this application. Detailed Implementation

[0013] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0014] In the description of this application, the use of terms such as "first," "second," etc., is for the purpose of distinguishing technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or the order of the technical features indicated.

[0015] In the description of this application, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0016] In the description of this application, it should be noted that, unless otherwise explicitly defined, terms such as "setup," "installation," and "connection" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this application in conjunction with the specific content of the technical solution.

[0017] Existing lightweight real-time operating systems are primarily used in microcontrollers, edge controllers, industrial gateways, automotive controllers, or resource-constrained embedded terminals. These systems typically employ a flat address space model, where tasks share the same address space, emphasizing real-time scheduling, compact code size, and low runtime overhead. While this design is suitable for traditional microcontroller scenarios, it cannot effectively utilize the MMU's page-level mapping capabilities and access attribute control on high-performance embedded processor platforms with an MMU, resulting in lower memory mapping security.

[0018] To address the aforementioned technical deficiencies, this application provides a method for real-time operating system memory mapping and task-level protection.

[0019] Please see Figure 1 This is a flowchart illustrating a real-time operating system memory mapping and task-level protection method provided in an embodiment of this application. This method is applied to electronic devices, such as servers. Figure 1 As shown, the real-time operating system memory mapping and task-level protection method includes: Step S101: After obtaining the platform's basic data, construct a static page table based on the platform's basic data. The platform's basic data includes the page size, the virtual address range of the reserved mapping window area, and the maximum number of concurrent mapping windows. The static page table mentioned above can be a page table structure that is pre-built during the system startup phase and remains stable over a long period of time.

[0020] The aforementioned reserved mapping window area can be a pre-defined segment of virtual address space used to dynamically map the memory resources required by the task.

[0021] In step S101, the above-mentioned method of constructing a static page table based on the platform basic data can be described as follows: when the platform basic data is manually configured, the page table structure is dynamically allocated and initialized in memory according to the page size and the virtual address range of the reserved mapping window area defined in the platform basic data, so as to map fixed system resources to the corresponding virtual address space.

[0022] Specifically, after the system (a real-time operating system with a lightweight MMU, which may include the processor) powers on and boots, it configures basic platform data. This basic platform data may include: processor architecture type, page size, physical memory start address, physical memory length, kernel code segment physical address range, kernel data segment physical address range, device register physical address range, virtual address range of reserved mapping window area, and maximum number of concurrent mapping windows. Based on the processor architecture type (which can be an ARMv8-A platform or a RISC-V platform) and page size, it sets the page table hierarchy of the static page table: for example, a four-level page table can be used on an ARMv8-A platform; on a RISC-V platform, an Sv39 page table structure can be used. The system then divides the virtual address range into kernel code segment mapping area, kernel data segment mapping area, ordinary memory area, device register area, and reserved mapping window area based on the physical memory layout and kernel segment address. For each of the above regions (kernel code segment mapping area, kernel data segment mapping area, ordinary memory area, device register area, and reserved mapping window area), default page table entries are generated (the page table structure includes several page table entries, and the default page table entry is the initial default configuration of each page table entry). In the default page table entry, the kernel code segment mapping area is set to read-only and executable; the kernel data segment mapping area is set to read-write and non-executable; the ordinary memory area is set to cached and read-write; the device register area is set to device, non-cacheable, and non-executable; and the mapping window area is initially set to an inaccessible or controlled dynamic attribute area.

[0023] Given the pre-obtained kernel link address (virtual address, VMA) and physical load address (physical address, LMA), the difference between the kernel link address and the physical load address is calculated to obtain a fixed offset. This application enables the original kernel code of a lightweight MMU real-time operating system to run at a stable kernel address by using a fixed offset. During task context switching, it is not necessary to be aware of the complex process virtual address space. Only local modifications to the page table entries in the mapped window area are needed, without replacing the entire page table.

[0024] Step S102: Based on the platform's basic data, the reserved mapping window area is divided into several window units. The window descriptor table is determined, wherein the window descriptor table includes the window descriptor corresponding to each window unit. In step S102, the aforementioned determination of the window descriptor table can be based on platform basic data, generating a window descriptor corresponding to each window unit. Each window descriptor can include a window number, a virtual starting address, a target physical starting address, a resource number, a resource internal offset, a mapping length, a number of pages, an authorized task bitmap, a window state, a reference count, and a recent refresh timestamp. The window number is a unique identifier for the window unit; the virtual starting address is the starting linear address of the window in the task virtual address space; the target physical starting address is the actual physical base address on the hardware side; the resource number is the resource handle number (which can be used to determine whether they belong to the same resource); the resource internal offset can be used to characterize the byte offset of the current window within the resource, used to locate the starting position within the resource; the authorized task bitmap is generated by the task-resource authorization table (the task-resource authorization table is a table generated when the driver resource is registered), used to determine access permissions when switching tasks; the window state includes idle, allocated, mapped, pending reclamation, or error; the reference count is used to characterize the total number of tasks holding the mapped window.

[0025] Step S103: Upon receiving a memory mapping request for the target task, determine the mapping request record and architecture-independent attribute descriptor of the target task through the memory mapping interface. The mapping request record includes the task number and resource number of the target task, and the architecture-independent attribute descriptor includes the resource number, mapping mode, and first protection attribute. The first protection attribute is read permission, write permission, and / or execute permission. The aforementioned mapping request record may also include the resource type of the target task, the first protection attribute, and the mapping mode. The resource type may be a device resource, and the virtual address range marked as a device resource may include the network controller register area (device register area).

[0026] Step S104: Based on the mapping request record, architecture-independent attribute descriptor, and window descriptor table, determine the mapping window of the target task and update the static page table entries in the static page table corresponding to the mapping window.

[0027] This application introduces a window-based memory mapping mechanism, effectively addressing the issues of insufficient MMU capability utilization and low memory mapping security in traditional flat address space models within real-time operating systems equipped with lightweight MMUs. By managing reserved mapping window areas and dynamically allocating mapping windows based on task requests, the system provides greater flexibility in memory management under resource-constrained environments, thereby improving overall memory mapping security.

[0028] In some embodiments, the method may further include steps S201 to S203: Step S201: When performing task switching through the scheduler, determine the permission attributes of the task to be switched in each window unit based on the window descriptor table and the task-resource authorization table. The task-resource authorization table is a table generated when the driver resource is registered. The task-resource authorization table includes task number, resource number, second protection attribute, mapping mode and permission attribute. The permission attribute is either have access permission or no access permission. The second protection attribute mentioned above can be read permission, write permission, and / or execute permission.

[0029] In step S201, the above-mentioned determination of the permission attributes of the task to be switched in each window unit based on the window descriptor table and the task-resource authorization table can be achieved by traversing the task-resource authorization table and the window descriptor table to find a record that matches the task number of the task to be switched and the resource number corresponding to the current window unit. If a matching record is found, the permission attributes in the record are used to determine the permission of the task for that window unit.

[0030] Specifically, for each mapped window, the system determines whether the task to be switched exists in the authorized task bitmap of the mapped window. If the task to be switched is authorized to access the mapped window, the system ensures that the static page table entry of the mapped window remains valid and maintains the corresponding read, write, execute, and cache attributes (of the static page table entry of the mapped window). If the task to be switched is not authorized to access the mapped window, the system restores the static page table entry corresponding to the mapped window to an inaccessible state and performs TLB synchronization on the mapped window.

[0031] Specifically, when multiple tasks to be switched share the same window unit, the system keeps the window unit valid only among authorized tasks; when switching to an unauthorized task, the window unit is inaccessible to the unauthorized task; for task stack areas pre-set according to actual needs, the system uniformly sets the execution prohibition attribute to prevent data in the stack area from being executed as instructions; for kernel code segments, the system maintains the read-only attribute to prevent tasks from accidentally writing or maliciously modifying them.

[0032] Step S202: Determine the target window unit of the task to be switched based on the permission attributes; In step S202, the above-mentioned determination of the target window unit for the task to be switched based on permission attributes can be to traverse all window units, check the corresponding permission attributes for each window unit, and mark the window unit as the target window unit if the permission attribute is "has access rights".

[0033] Step S203: If the task to be switched is switched through the scheduler based on the target window unit, and there is an exception during the switch, the corresponding exception status error code is returned.

[0034] In step S203, when switching to the task to be switched based on the target window unit via the scheduler, and an exception occurs during the switch, the corresponding exception status error code returned can be: after the task switch is actually executed by the scheduler and the target window unit is activated, a security check is performed on the switch process. If the security check result indicates that an exception has occurred during the switch, the exception can be: an illegal attempt to access an unauthorized resource handle (in the case of an invalid resource status), window exhaustion (in the case of no free windows and no reusable windows after traversing the window descriptor table; reusable windows are used to represent window units currently occupied by other tasks), insufficient permissions (in the case of the permissions requested by the current task not being a subset of the allowed permissions in the authorization table), or TLB synchronization failure (in the case of the TLB synchronization interface returning failure or timeout). After the system catches this exception, it cancels the temporary state during this mapping establishment process, restores the window descriptor corresponding to the target window unit to an idle state, and returns an exception status error code pre-set according to actual needs to the upper-level caller. The reference count of the target window unit is decremented.

[0035] This application extends memory protection from static mapping to dynamic task-level protection by introducing a dynamic permission verification mechanism during task switching. At the critical juncture of task scheduling and switching in the real-time operating system, a pre-generated task-resource authorization table is compared with the window descriptor table to accurately determine the access permissions of the task to be switched in each window unit. This design allows the system to move away from relying on a single global memory view and instead dynamically configure memory access attributes based on the actual resource requirements of the task at the moment of switching, effectively preventing unauthorized access. Specifically, the scheduler synchronously executes the permission attribute determination step during task switching, ensuring that the memory protection strategy aligns with the task's requirements. Strict synchronization of the task execution process avoids security risks caused by delayed permission configuration. Permission attributes are determined based on the task-resource authorization table, and the mapping relationship established during driver resource registration is utilized to ensure the accuracy and consistency of permission verification. The target window unit is further determined through permission attributes, realizing fine-grained management of memory-mapped windows and ensuring that tasks can only access their authorized specific memory areas. Finally, an anomaly detection and error code return mechanism is introduced during the switching process, providing the system with necessary security defense boundaries. Once an illegal switch or configuration conflict is detected, it can be blocked and feedback can be provided in a timely manner, enhancing the robustness and security of the real-time operating system in complex task environments.

[0036] In some embodiments, step S103 may include steps S301 to S302: Step S301: After obtaining the target task's request mapping length, mapping mode, first protection attribute, and resource handle through the memory mapping interface, determine the mapping request record based on the request mapping length, mapping mode, first protection attribute, resource handle, and resource registration table; wherein, the resource handle is used to look up the target resource in the resource registration table, the resource registration table is a table generated when the driver registers resources, and the resource registration table includes resource number, resource type, resource physical base address, and resource length; The above request mapping length can be used to characterize the size of the memory region that the target task expects to map.

[0037] The above mapping patterns can be used to characterize the type or behavior of memory mapping.

[0038] In step S301, after obtaining the target task's request mapping length, mapping mode, first protection attribute, and resource handle through the memory mapping interface, and determining that the mapping request record can be used by the target task when calling the memory mapping interface and receiving the target task's input parameters, a basic verification is first performed to obtain the verification result. The basic verification may include determining whether the request mapping length is zero and whether the internal offset of the resource meets the page alignment requirements. If the verification result is successful, the resource registration table is queried according to the resource handle to obtain the query result. Based on the query result and the input parameters, a mapping request record is constructed. The input parameters may include the virtual address to which the target task is expected to be mapped, the request mapping length, the mapping mode, the first protection attribute, the resource handle, and the internal offset of the resource. The mapping request record may also include the target task number, the resource number, the target physical starting address, the first protection attribute, the mapping mode, and the internal offset of the resource.

[0039] Step S302: Determine the architecture-independent attribute descriptor based on the mapping request record.

[0040] This application introduces a resource registry as an intermediary bridge, achieving a standardized transformation from the original request parameters on the task side to the system's internal mapping request record. By obtaining the request mapping length, mapping mode, first protection attribute, and resource handle through the memory mapping interface, it comprehensively covers the key information required for memory mapping. Through basic verification and resource registry matching, it transforms abstract resource requests into specific underlying information such as resource number, resource type, resource physical base address, and resource length, thereby constructing a complete mapping request record. This method of determining mapping request records based on the resource registry ensures the legality and accuracy of mapping requests, providing a reliable data foundation for subsequent memory mapping. Furthermore, based on this mapping request record, it determines architecture-independent attribute descriptors, achieving decoupling of mapping attributes. This allows the system to shield the differences in underlying hardware architecture and uniformly handle the memory mapping requirements of different tasks, thereby improving the standardization and flexibility of memory mapping processing.

[0041] In some embodiments, step S302 may include step S401: Step S401: Determine the architecture-independent attribute descriptor based on the resource type, the first protection attribute, and the mapping mode.

[0042] In step S401, based on the resource type, the first protection attribute, and the mapping mode, it is determined that the architecture-independent attribute descriptor can be a read mapping request record. Then, according to the conversion rules preset according to actual needs, the resource type, the first protection attribute, and the mapping mode are converted into architecture-independent attribute descriptors.

[0043] Specifically, the conversion rules mentioned above may include: if the first protection attribute includes read permission, then set the read allow bit; if the first protection attribute includes write permission, then set the write allow bit; if the first protection attribute includes execute permission, then set the execute allow bit; if the first protection attribute does not include execute permission, then set the execute prohibit bit.

[0044] Specifically, the above conversion rules may also include: when the mapping mode is device register mapping, the device memory bit is set, the cache bit and buffer bit are disabled, and the execution prohibition bit is forcibly set; when the mapping mode is shared buffer mapping, the shared bit is set, and it is set to read-only shared or read-write shared according to the business requirements preset according to actual needs; when the mapping mode is ordinary memory mapping, the ordinary memory bit is set, and the cache bit can be set according to the default attributes corresponding to the resource type; when the resource registration table indicates that the resource type must be non-executable, the security constraints in the resource registration table shall prevail (i.e., non-executable).

[0045] This application refines the mapping request record, clarifying resource type, primary protection attribute, and mapping mode as core input parameters for generating architecture-independent attribute descriptors, thereby achieving fine-grained management of memory mapping attributes. This multi-dimensional parameter-based mapping descriptor generation method can generate more targeted and accurate architecture-independent attribute descriptors based on the characteristics of different resources (such as peripheral registers, shared memory, etc.), combined with read / write execution permissions and mapping modes. This ensures that memory mapping requests can be uniformly and accurately transformed into system-recognizable protection attributes under different hardware architectures, thus achieving finer-grained access control in task-level protection. In this way, the system can not only accurately identify the task's access requirements for specific resources, but also effectively avoid illegal access risks during the mapping window allocation phase based on the generated descriptors, enhancing the memory security and mapping flexibility of the real-time operating system in resource-constrained environments.

[0046] In some embodiments, step S104 may include step S501: Step S501: Based on the mapping request record and the architecture-independent attribute descriptor, traverse the window descriptor table to determine the mapping window of the target task, wherein the mapping window is a reused window or an idle window.

[0047] In step S501, based on the mapping request record and architecture-independent attribute descriptor, the system traverses the window descriptor table to determine the mapping window for the target task. If, during the traversal of the window descriptor table, a reused window is found that has the same resource number, the same target physical starting address, and the same internal resource offset (from the matching result of the mapping request record corresponding to the target task in the window descriptor table), and the architecture-independent attribute descriptor of other tasks occupying the reused window is the same as the architecture-independent attribute descriptor of the target task, then the reused window is used as the mapping window for the target task, the reference count of the reused window is incremented, and the current task is added to the authorized task bitmap of the reused window. If no reused window meets the above conditions, the system selects a window unit with an idle window state from the window descriptor table as the mapping window for the target task.

[0048] In some embodiments, the method may further include, before determining the mapping window for the target task: Read the processor architecture type and architecture-independent attribute descriptor, input the processor architecture type and architecture-independent attribute descriptor into the platform attribute translation table for matching (a table hard-coded in the kernel at the kernel level during system compilation) to obtain the page table entry code that can be written to the page table; for example, on the ARMv8-A platform, convert ordinary memory mapping into memory attribute index; convert execution prohibition attribute into privileged execution prohibition bit or user execution prohibition bit; convert page valid status into valid page table entry flag to obtain the page table entry code; After determining the mapping window for the target task, the method may also include: The task-resource authorization table is queried based on the task number and resource number corresponding to the target task. If the pre-acquired request permissions of the target task are a subset of the authorized permissions in the task-resource authorization table, the permission verification passes. The page table entry code is written into the static page table entry corresponding to the mapping window of the target task, and TLB (page table cache) synchronization is performed so that the processor can immediately use the new address mapping relationship. The window descriptor corresponding to the mapping window of the target task is updated, which may include setting the window state to mapped.

[0049] This application, by combining the specific requests and attributes of the target task, can accurately select the most suitable mapping window from numerous window units, avoiding blind allocation and thus optimizing the memory mapping allocation logic. This scheme prioritizes reusable windows, reduces unnecessary memory allocation and page table operations, and lowers system overhead. When there are no reusable windows, idle windows are allocated to ensure full utilization of resources. This dynamic and intelligent window selection mechanism enables the lightweight MMU to handle memory mapping requests more flexibly and efficiently in the real-time operating system.

[0050] In some embodiments, the method may further include step S601: Step S601: When the reference count is zero, perform TLB synchronization and reset the corresponding window descriptor to an idle state. The reference count is used to represent the total number of tasks holding the mapped window.

[0051] Reference counting can also be used to determine whether a reused window is still occupied by a task.

[0052] Specifically, when the reference count is zero, the static page table entry corresponding to the target window unit is restored to an inaccessible state, TLB synchronization is performed, and the window state of the window descriptor corresponding to the target window unit is reset to an idle state.

[0053] This application demonstrates that when the reference count is zero, indicating that the mapped window is no longer occupied by any task, performing TLB synchronization at this point avoids illegal memory access or security vulnerabilities caused by stale cache. Simultaneously, the corresponding window descriptor is reset to an idle state, allowing the system to promptly reclaim released window resources and reallocate them to subsequent memory mapping requests. This significantly improves the utilization of limited mapped window resources and further enhances memory isolation between tasks and overall system security. This mechanism, combined with basic static page table construction, window descriptor table management, and memory mapping request processing, forms a comprehensive memory management and protection scheme, ensuring the efficient operation of a lightweight real-time operating system on platforms equipped with an MMU.

[0054] In some embodiments, step S102 may include step S701: Step S701: Based on the page size, divide the virtual address range of the reserved mapping window area into several window units, wherein the total number of window units is equal to the maximum number of concurrent mapping windows, the addresses of each window unit are continuous, and the addresses of every two window units do not overlap.

[0055] In step S701, the above-mentioned division of the virtual address range of the reserved mapping window area into several window units based on the page size can be achieved by aligning the virtual address range of the reserved mapping window area according to the page size to obtain the aligned virtual address range, and then dividing the aligned virtual address range into independent virtual slots that are the same as the maximum number of concurrent mapping windows, with continuous and non-overlapping addresses, to obtain several window units.

[0056] This application introduces page size as the core basis for dividing the reserved mapping window area, achieving standardized and refined management of memory mapping windows. By associating the virtual address range with the page size, it ensures that each divided window unit meets the minimum granularity requirements of hardware memory management, thereby avoiding mapping anomalies caused by address alignment issues. By imposing an equal constraint on the total number of window units and the maximum number of concurrent mapping windows, deterministic resource allocation is achieved, effectively preventing excessive allocation or waste of memory resources. By forcing each window unit address to be contiguous and non-overlapping, a regular memory mapping space is constructed. This not only simplifies the search and matching logic of subsequent memory mapping requests but also provides a clear boundary definition for task-level protection, ensuring that in a multi-task concurrent environment, the mapping windows of different tasks can be managed and switched without interference, thereby improving the overall efficiency and security of system memory mapping.

[0057] This application does not introduce complex process address spaces and page fault mechanisms. It only updates local page table entries in the static page table and the mapped window area, which makes the memory protection overhead during task switching extremely small and the timing certain. Thus, while greatly improving system security, it still strictly guarantees the real-time performance of the lightweight operating system.

[0058] Additionally, refer to Figure 2 One embodiment of this application provides a real-time operating system memory mapping and task-level protection system, including a data construction module 1100, a window descriptor table determination module 1200, a mapping request record and architecture-independent attribute descriptor determination module 1300, and a mapping window determination module 1400, wherein: The data construction module 1100 is used to construct a static page table based on the platform's basic data, which includes the page size, the virtual address range of the reserved mapping window area, and the maximum number of concurrent mapping windows. The window descriptor table determination module 1200 is used to determine the window descriptor table when the reserved mapping window area is divided into several window units based on the platform's basic data. The window descriptor table includes the window descriptor corresponding to each window unit. The mapping request record and architecture-independent attribute descriptor determination module 1300 is used to determine the mapping request record and architecture-independent attribute descriptor of the target task through the memory mapping interface when a memory mapping request of the target task is received. The mapping request record includes the task number and resource number of the target task, and the architecture-independent attribute descriptor includes the resource number, mapping mode and first protection attribute, wherein the first protection attribute is read permission, write permission and / or execute permission. The mapping window determination module 1400 is used to determine the mapping window of the target task based on the mapping request record, the architecture-independent attribute descriptor, and the window descriptor table, and to update the static page table entries in the static page table corresponding to the mapping window.

[0059] This system effectively addresses the issues of insufficient MMU capability utilization and low memory mapping security in traditional flat address space models by introducing a window-based memory mapping mechanism within a real-time operating system equipped with a lightweight MMU. By managing reserved mapping window areas and dynamically allocating mapping windows based on task requests, the system provides greater flexibility in memory management under resource-constrained environments, thereby improving overall memory mapping security.

[0060] It should be noted that the system embodiments described above are based on the same inventive concept as the method embodiments described above. Therefore, the relevant content of the method embodiments described above is also applicable to the system embodiments described above, and will not be repeated here.

[0061] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with relevant regulations. The acquisition, storage, use and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.

[0062] like Figure 3One embodiment of this application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned real-time operating system memory mapping and task-level protection method. The electronic device includes: At least one memory; At least one processor; At least one program; The program is stored in memory, and the processor executes at least one program to implement a real-time operating system memory mapping and task-level protection method according to the above embodiments of this disclosure.

[0063] Electronic devices can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), and in-vehicle computers.

[0064] The electronic devices according to embodiments of this application will now be described in detail.

[0065] The processor 1600 can be implemented using a general-purpose central processing unit (CPU), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this disclosure. The memory 1700 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 1700 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1700 and is called and executed by the processor 1600 to implement a real-time operating system memory mapping and task-level protection method according to an embodiment of this disclosure.

[0066] The input / output interface 1800 is used to implement information input and output. The communication interface 1900 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 2000 transmits information between various components of the device (e.g., processor 1600, memory 1700, input / output interface 1800, and communication interface 1900); The processor 1600, memory 1700, input / output interface 1800 and communication interface 1900 are connected to each other within the device via bus 2000.

[0067] This disclosure also provides a storage medium, which is a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above-described real-time operating system memory mapping and task-level protection method.

[0068] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0069] The above is a detailed description of the preferred embodiments of this application. However, the embodiments of this application are not limited to the above-described implementation methods. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the embodiments of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of the embodiments of this application.

Claims

1. A method for memory mapping and task-level protection in a real-time operating system, characterized in that, The real-time operating system memory mapping and task-level protection method includes: Having acquired the platform's basic data, a static page table is constructed based on the platform's basic data, which includes the page size, the virtual address range of the reserved mapping window area, and the maximum number of concurrent mapping windows. Based on the platform's basic data, when the reserved mapping window area is divided into several window units, a window descriptor table is determined, wherein the window descriptor table includes a window descriptor corresponding to each window unit; Upon receiving a memory mapping request for a target task, the mapping request record and architecture-independent attribute descriptor for the target task are determined through the memory mapping interface. The mapping request record includes the task number and resource number of the target task, and the architecture-independent attribute descriptor includes the resource number, mapping mode, and a first protection attribute, which is read permission, write permission, and / or execute permission. Based on the mapping request record, the architecture-independent attribute descriptor, and the window descriptor table, the mapping window for the target task is determined, and the static page table entry in the static page table corresponding to the mapping window is updated.

2. The method for memory mapping and task-level protection of a real-time operating system according to claim 1, characterized in that, The method further includes: When task switching is performed through the scheduler, the permission attributes of the task to be switched in each window unit are determined based on the window descriptor table and the task-resource authorization table. The task-resource authorization table is a table generated when the driver resource is registered. The task-resource authorization table includes task number, resource number, second protection attribute, mapping mode and permission attribute. The permission attribute is either "have access" or "have no access". Based on the permission attributes, the target window unit of the task to be switched is determined; If the scheduler switches to the task to be switched based on the target window unit, and an exception occurs during the switch, the corresponding exception status error code is returned.

3. The method for memory mapping and task-level protection of a real-time operating system according to claim 1, characterized in that, The step of determining the mapping request record and architecture-independent attribute descriptor of the target task through the memory mapping interface includes: When the request mapping length, mapping mode, first protection attribute, and resource handle of the target task are obtained through the memory mapping interface, the mapping request record is determined based on the request mapping length, the mapping mode, the first protection attribute, the resource handle, and the resource registration table; wherein, the resource handle is used to look up the target resource in the resource registration table, the resource registration table is a table generated when the driver registers resources, and the resource registration table includes resource number, resource type, resource physical base address, and resource length; Based on the mapping request record, the architecture-independent attribute descriptor is determined.

4. The method for memory mapping and task-level protection of a real-time operating system according to claim 3, characterized in that, The mapping request record includes the resource type of the target task, the first protection attribute, and the mapping mode. Determining the architecture-independent attribute descriptor based on the mapping request record includes: The architecture-independent attribute descriptor is determined based on the resource type, the first protection attribute, and the mapping pattern.

5. The method for memory mapping and task-level protection of a real-time operating system according to claim 4, characterized in that, The step of determining the mapping window for the target task based on the mapping request record, the architecture-independent attribute descriptor, and the window descriptor table includes: Based on the mapping request record and the architecture-independent attribute descriptor, the window descriptor table is traversed to determine the mapping window for the target task, wherein the mapping window is a reused window or an idle window.

6. The method for memory mapping and task-level protection of a real-time operating system according to claim 1, characterized in that, The method further includes: When the reference count is zero, TLB synchronization is performed, and the corresponding window descriptor is reset to an idle state, wherein the reference count is used to represent the total number of tasks holding the mapped window.

7. The method for memory mapping and task-level protection of a real-time operating system according to claim 1, characterized in that, The process of dividing the reserved mapping window area into several window units based on the platform's basic data includes: Based on the page size, the virtual address range of the reserved mapping window area is divided into several window units, wherein the total number of window units is equal to the maximum number of concurrent mapping windows, the addresses of each window unit are continuous, and the addresses of any two window units do not overlap.

Images