Lightweight system in-memory isolation method and terminal

Abstract

The application relates to the field of operating system memory isolation, in particular to an application memory isolation method of a lightweight system and a terminal. The method comprises the following steps: after the system is started, at least one preset memory space is divided from the total memory of the system, and the remaining memory space except the preset memory space is used as a global available memory pool; an application startup request is received, and a continuous memory area is allocated for a target application corresponding to the application startup request from the global available memory pool; and an application identity of the target application is added to the continuous memory area, so that the continuous memory area is accessed only through an access request of the target application. According to the application, a continuous memory area is allocated for each application, and an application identity is added, so that boundary control of memory access between applications is realized, data leakage or system crash caused by memory out-of-bound reading and writing and malicious access is effectively prevented, and the data security and system stability during multi-application running are obviously improved.

Description

Technical Field

[0001] This invention relates to the field of operating system memory isolation technology, and in particular to application memory isolation methods and terminals for lightweight systems. Background Technology

[0002] The OpenHarmony lightweight system provides the ArkUI Lite lightweight UI development framework for lightweight devices, encompassing core components such as the Native runtime, JS runtime, AMS (Ability Manager Service), BMS (Bundle Manager Service), and UIKit. Leveraging prior technology, the system has implemented the loading and switching of multiple JS applications and supports intelligent functions such as Launcher and status bar. Standard Android and OpenHarmony systems build sandbox isolation mechanisms by assigning independent process IDs and UIDs to applications. However, lightweight devices have limited hardware resources and typically lack an MMU (Memory Management Unit), with the underlying system scheduling supporting only threads and not processes. With the introduction of multi-application runtime capabilities, data security isolation in the coexistence of multiple applications becomes essential, but the lack of underlying process support renders traditional process-based sandbox isolation mechanisms completely unusable. This results in all applications running in the current system within the same address space, with no memory isolation between applications. Any application can directly read and write memory data occupied by other applications, creating serious risks of cross-application data unauthorized access and tampering. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide an application memory isolation method for lightweight systems to achieve memory isolation in lightweight systems.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for application memory isolation in a lightweight system includes: after system startup, dividing the total memory of the system into at least one preset memory space, and using the remaining memory space other than the preset memory space as a global available memory pool; receiving an application startup request, allocating a contiguous memory region from the global available memory pool for the target application corresponding to the application startup request; adding the application identity identifier of the target application to the contiguous memory region so that the contiguous memory region is only accessible through the target application's access requests.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A lightweight system with an application memory isolation terminal includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it performs the following steps: After the system starts, it allocates at least one preset memory space from the total system memory and uses the remaining memory space other than the preset memory space as a global available memory pool; it receives application startup requests and allocates a contiguous memory region from the global available memory pool for the target application corresponding to the application startup request; it adds the application identity identifier of the target application to the contiguous memory region so that the contiguous memory region can only be accessed by the target application.

[0006] The beneficial effects of this invention are as follows: After system startup, this invention divides the total memory into at least one memory space and uses the remaining memory as a globally available memory pool. Upon receiving an application startup request, it allocates a contiguous memory region for the application from the globally available memory pool and adds an application identity identifier to this contiguous memory region, ensuring that the region can only be accessed by the corresponding application identity identifier. Compared with existing technologies where all applications run in the same physical address space and lack memory isolation, this invention achieves boundary control of memory access between applications by allocating a dedicated contiguous memory region for each application and adding an application identity identifier. This effectively prevents data leakage or system crashes caused by out-of-bounds memory reads and writes and malicious access, significantly improving data security and system stability when multiple applications are running. Furthermore, this method does not rely on MMU hardware and process mechanisms, making it suitable for resource-constrained lightweight systems and exhibiting good compatibility and practicality. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of an application memory isolation method for a lightweight system provided in this embodiment of the invention; Figure 2 A system architecture diagram of an application memory isolation method for a lightweight system provided in an embodiment of the present invention; Figure 3 A flowchart illustrating the system startup and memory initialization process of an application memory isolation method for a lightweight system provided in this embodiment of the invention; Figure 4 A flowchart illustrating the application startup and memory allocation process of an application memory isolation method for a lightweight system, provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an application memory isolation terminal for a lightweight system provided in an embodiment of the present invention; Detailed Implementation Definitions:

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] Among existing technologies, OpenHarmony is a lightweight operating system designed specifically for lightweight devices. It provides developers with the ArkUI Lite lightweight UI development framework, covering core components such as the Native runtime, JS runtime, AMS, BMS, and UIKit. Due to hardware resource limitations, this system typically lacks a Modeling Unit (MMU) and only supports threads, not processes. With the introduction of multi-application runtime capabilities, data security issues between multiple applications have become increasingly prominent. Existing standard operating systems (such as Android and the standard OpenHarmony system) use sandbox isolation schemes to build sandbox isolation by assigning each application a unique process ID and application UID, and utilizing the MMU to implement virtual address space mapping. However, some systems do not have an MMU, thus requiring a new technical solution to address the memory isolation deficiency caused by multiple applications sharing the same address space in the OpenHarmony lightweight system, without relying on MMU hardware and process mechanisms, and to achieve memory access boundary control and data security protection during multi-application runtime.

[0010] To at least address the aforementioned issues, this invention divides the total system memory into a preset memory space and a globally available memory pool. For each application, a contiguous memory region is allocated from the globally available memory pool and bound to an application identity identifier to restrict access to only that application. In this way, memory isolation between applications can be achieved in lightweight systems lacking MMU and process isolation.

[0011] The following describes in detail an application memory isolation method for a lightweight system according to the present invention, with reference to the appendix. Figure 1 This includes steps 101 to 103.

[0012] Step 101: After system startup, at least one preset memory space is allocated from the total system memory. The remaining memory space, excluding the preset memory space, is used as a global available memory pool. System startup includes the power-on reset of the OpenHarmony lightweight system kernel and the completion of basic hardware initialization. Total memory includes the physical memory capacity provided by the system hardware. The preset memory space consists of fixed partitions statically divided by the kernel according to the total system memory size and the number of pre-configured applications, with no overlap between regions. The global available memory pool is all remaining memory excluding the preset memory space, a memory region uniformly managed by the kernel runtime memory allocator. For example, after the kernel statically divides the total memory into a kernel memory area, a system core application memory area, a shared memory area, and a red area as preset memory spaces, all remaining memory is used as the global available memory pool.

[0013] Step 102: Receive an application startup request and allocate a contiguous memory region from the global available memory pool for the target application corresponding to the application startup request. The application startup request includes an instruction sent by the user or system service to AMS to start the application. The target application includes a lightweight system application that requests to be started. A contiguous memory region is a memory space with a continuous address range allocated from the global available memory pool, divided into a code segment, a data segment, a heap segment, and a stack segment. For example, if a user sends a request to AMS to start application A, the kernel runtime memory allocator allocates a contiguous memory region from the global available memory pool for application A, including the code segment, data segment, heap segment, and stack segment.

[0014] Step 103: Add the target application's application identity to the contiguous memory region so that the contiguous memory region is accessible only to access requests from the target application; where the application identity is the APPID. An access request is an application task's read / write operation on the memory region. For example, the kernel memory marking module adds an APPID security tag to the header of each memory block in the contiguous memory region allocated for the target application, recording the APPID to which the contiguous memory region belongs and the size of the contiguous memory region. This contiguous memory region is marked as accessible only to APPID=xxx.

[0015] As described above, this invention solves the problem of lack of memory isolation when multiple applications run in the same address space in an environment without an MMU by statically dividing a preset memory space and dynamically allocating a continuous memory region and binding it with an application identity identifier. This enables only the target application to access its allocated memory region, thereby building application-level memory logical isolation in a lightweight system.

[0016] In one embodiment of this application, step 101, which involves allocating at least one preset memory space from the total system memory, includes: Step 201 involves allocating a kernel memory region from the total memory for executing kernel code and reading / writing kernel data. This kernel memory region is a pre-defined memory space with a fixed address range. During allocation, the OpenHarmony lightweight system typically runs on resource-constrained hardware like an MCU. After power-on reset, the RAM (Random Access Memory) is not yet initialized. The CPU first fetches instructions from Flash (non-volatile storage), and the early kernel startup code (including hardware initialization, RAM self-test, and basic peripheral driver loading logic) runs in Flash. After the kernel completes basic hardware initialization, the kernel code segment and read-only data segment are copied from Flash to the subsequently statically allocated kernel memory region. Simultaneously, the RAM initialization of the data segment and BSS segment is completed. Afterward, the kernel's core scheduling, memory management, and other logic jump to the kernel memory region in RAM for execution. The startup code in Flash only takes effect during the startup phase and does not participate in subsequent runtime logic.

[0017] Step 202: Allocate a system core application memory area from the total memory for running system core applications, accessible only to system core applications. The system core application (System Core APP) memory area is a pre-defined memory space with a fixed address range, allowing only system core applications to read / write / execute it. System core applications are the applications corresponding to the core services of the operating system.

[0018] Step 203: Divide the total memory into a shared memory area for inter-application communication; wherein, the shared memory area is a preset memory space with a fixed address range, which can be read / written by all applications and is used for inter-application communication.

[0019] Step 204: Divide the total memory into a red zone for stack overflow protection, which is prohibited from being accessed by all application tasks. The red zone is a preset memory space with a fixed address range.

[0020] As described above, in this invention, the system powers on and resets, and the kernel completes basic hardware initialization. Based on the total system memory size and the number of pre-configured applications, the kernel statically divides the memory space into a pre-defined memory area. By statically dividing the total memory into a kernel memory area, a system core application memory area, and a shared memory area, and combining this with the APPID binding and verification mechanism during subsequent dynamic allocation, the technical problem of multiple applications running in the same address space and the inability to achieve memory isolation in existing lightweight systems due to the lack of MMU and process isolation mechanisms is solved. This achieves logical isolation and security protection for each application's memory area. The pre-defined kernel memory area, system core application memory area, shared memory area, and red zone are all essential fixed modules for system operation and must be prioritized. Ordinary third-party applications are characterized by flexible installation, uninstallation, and startup / shutdown, and their memory requirements vary greatly. If static pre-allocation is also used for ordinary applications, a large amount of memory will be idle (e.g., pre-allocated memory is completely wasted when no application is installed), severely reducing the memory utilization of the lightweight system. The remaining memory is used as a globally available memory pool, and contiguous memory areas can be dynamically allocated according to the actual number of installed applications and startup requirements, maximizing memory utilization efficiency.

[0021] In one embodiment of this application, step 102, allocating a contiguous memory region from the globally available memory pool for the target application corresponding to the application startup request, includes: Step 301: Check the remaining memory capacity of the global available memory pool; where the remaining memory capacity is the amount of memory that is currently not allocated in the global available memory pool.

[0022] Step 302: If the remaining memory capacity is greater than or equal to the memory requirement of the target application, then allocate a contiguous memory region from the global available memory pool; where the memory requirement is the amount of memory required for the application to run, which is extracted from the application package during the application installation phase.

[0023] Step 303: If the remaining memory capacity is less than the memory requirement of the target application, release the memory occupied by the lowest priority application in the global available memory pool until the remaining memory capacity is greater than or equal to the memory requirement of the target application; where the lowest priority application is the running application with the lowest priority determined by the kernel memory shortage scheduler according to the scheduling policy.

[0024] As described above, this invention dynamically allocates contiguous memory regions for application startup requests in a single-address-space environment without an MMU by checking the remaining memory capacity of the globally available memory pool and releasing the memory occupied by the lowest priority application when the capacity is insufficient. This mechanism avoids application startup failures caused by memory fragmentation, ensures the continuity and reliability of memory allocation, and thus improves memory utilization efficiency when multiple applications run concurrently.

[0025] In one embodiment of this application, step 102, before receiving the application launch request, further includes: Step 401: Receive the application installation request, parse the application package corresponding to the target application installation request, and extract the memory requirement information of the application package. Here, the application installation request is the instruction to install the application. The application package is an installation package containing application code and configuration information. The memory requirement information is the memory capacity parameter required for the application to run. Specifically, during the application installation phase: no RAM memory is allocated. The BMS receives the application installation request, parses the application package, and extracts the application's memory requirement information.

[0026] Step 402: Assign a globally unique application identity to the application package; specifically, BMS assigns a globally unique and tamper-proof APPID to the application.

[0027] Step 403: Write the application package's memory requirements and application identity to the application registry so that the target application's runtime memory area can be allocated based on the application identity when the target application starts. The application registry is an application information table stored in Flash memory, recording the application package's memory requirements and application identity. Writing the application information to the application registry in Flash memory allows the kernel runtime memory allocator to schedule and allocate the application's runtime memory area when the application starts.

[0028] As described above, this invention assigns a globally unique application identity to each application during the application installation phase and writes this identity along with memory requirement information into the application registry. This allows the kernel to allocate a dedicated runtime memory area for the application based on this identity when the application starts. In a single address space environment without an MMU, this achieves logical isolation of memory between multiple applications, effectively preventing data access between different applications and improving system security.

[0029] In one embodiment of this application, it further includes: Step 501: Generate a memory protection unit configuration template corresponding to the target application; wherein, the memory protection unit configuration template is an MPU configuration template. MPU is an abbreviation for Memory Protection Unit. It is a standardized configuration unit with a fixed structure and content dynamically generated according to the application's runtime state by the kernel MPU management module. It explicitly prohibits access to the memory areas of all other applications and is stored in the kernel's private memory, which cannot be accessed or modified by any application.

[0030] Step 502: Load the target application's code into a contiguous memory region; specifically, the kernel loads the application code from Flash into the allocated code area.

[0031] Step 503: Create each task of the target application, and in the task control block of each task, set the application identity of the task control block to the application identity of the target application; where a task is a thread, the basic unit of scheduling in a lightweight system. The task control block (TCB) is a data structure used by the kernel to manage task attributes, containing an appId field. For example, when creating each task of the target application, the appId field in the task control block is forcibly set to the application's APPID.

[0032] Step 504: Establish the mapping relationship between the target application's task and the contiguous memory region, and start the target application's task; wherein, the mapping relationship is the corresponding binding relationship between the application identity in the task control block and the application identity marked in the contiguous memory region.

[0033] As described above, this invention generates a memory protection unit configuration template corresponding to the target application and sets the application identity identifier in the task control block. Combined with the mapping relationship between continuous memory regions and tasks, it achieves logical isolation of the runtime memory of multiple applications in a single address space environment without a memory management unit. This effectively solves the technical problem of lack of memory isolation in existing lightweight systems where all applications run in the same address space.

[0034] In one embodiment of this application, step 504, after starting the task of the target application, further includes: Step 601: In response to the dynamic memory allocation request sent by the target application, obtain the application identity of the task; wherein, the dynamic memory allocation request is the request sent by the application to the kernel to allocate heap memory when calling the malloc function.

[0035] Step 602: Allocate a target memory block from the contiguous memory region corresponding to the application identity of the task; wherein, the target memory block is a memory unit of a specified size allocated from the application-specific memory sub-pool.

[0036] Step 603: Add the application identity identifier of the task to the target memory block; for example, add the APPID tag to the header of the memory block.

[0037] Step 604: Return the pointer to the target memory block to the target application; where the pointer is the starting memory address of the target memory block.

[0038] As described above, this invention achieves fine-grained isolation of application runtime memory allocation in a single address space environment without an MMU by adding the application identity identifier of the task to the target memory block and verifying the identifier during the dynamic memory allocation request response process. This effectively prevents out-of-bounds memory access between applications and improves the memory security of lightweight systems.

[0039] In one embodiment of this application, step 604, after returning the pointer to the target memory block to the target application, further includes: Step 701: In response to the dynamic memory release request sent by the target application for the memory block to be released, obtain the application identity of the task; wherein, the dynamic memory release request is the request sent by the application to the kernel to release heap memory when calling the free function. The memory block to be released is the memory unit requested to be released by the application.

[0040] Step 702: Read the temporary identity of the memory block to be released; Step 703: Determine whether the temporary identity of the memory block to be released is consistent with the application identity of the task; specifically, check whether the APPID marker in the header of the memory block to be released is consistent with the APPID of the current task.

[0041] Step 704: If there is no consistency, the release of the memory block to be released is refused, a security log is recorded, and the task is terminated. The security log is the kernel log that records unauthorized memory operation events. Terminating the task is the kernel's operation to terminate the running of the unauthorized application.

[0042] Step 705: If consistent, clear the data area content of the memory block to be released and return the memory block to be released to the dedicated memory sub-pool corresponding to the application identity of the task. The dedicated memory sub-pool is a heap space within a contiguous memory region of the target application used for dynamic memory allocation. The dedicated memory sub-pool is a heap area within a contiguous memory region allocated by the kernel from the globally available memory pool when the application starts. It is formed by writing the APPID identifier and binding it to the task control block, and is reclaimed when the application is destroyed.

[0043] As described above, this invention verifies the consistency between the temporary identity of the memory block to be released and the application identity of the task during memory release. If the identities do not match, the release is refused, a security log is recorded, and the task is terminated. This achieves strict isolation of memory release operations between applications in a single address space environment without an MMU, effectively preventing data leakage or system crashes caused by applications releasing memory blocks of other applications without authorization, and improving memory security.

[0044] In one embodiment of this application, after starting the target application's task in step 504, the method further includes: Step 801: Intercept the pointer parameter passed to the target application when it invokes a system call involving memory operations; whereby the system call is a kernel interface invoked by the application involving memory operations. The pointer parameter is a parameter passed by the application pointing to a memory address. The interception is a unified pre-interception and pointer validity verification performed at the kernel level for all memory-related operating system calls.

[0045] Step 802: Obtain the memory region where the pointer parameter is located; where the memory region is a memory partition recorded in the global memory region table maintained by the kernel, including the kernel static region, the system core application memory region, the application dynamic allocation region, the shared memory region, and the red region.

[0046] Step 803: Determine whether the memory range where the pointer parameter is located belongs to a legal area that the application identity of the task is allowed to access; where a legal area is a memory range that the current task is allowed to access, including the current application's own memory area, shared memory area, and public area that the kernel allows to access.

[0047] Step 804: Determine whether the access length of the pointer parameter exceeds the memory block boundary; where the access length is the length of the memory data requested by the system call. The memory block boundary is the range of the start and end addresses of the allocated memory block.

[0048] Step 805: If the memory region containing the pointer parameter is not a legally accessible region, or the access length exceeds the memory block boundary, then the system call is rejected. As described above, this invention achieves real-time interception of applications accessing other applications' memory or exceeding their own memory block boundaries in a single address space environment without an MMU by performing dual verification of the memory range and access length of pointer parameters during system calls. This effectively prevents data leakage or system crashes caused by memory out-of-bounds access and enhances memory isolation security during multi-application runtime.

[0049] In one embodiment of this application, step 803, determining whether the memory region containing the pointer parameter belongs to a legal region accessible by the application identity of the task, includes: Step 901: If the pointer parameter points to the target application's own memory region, shared memory region, or public region that the kernel allows access to, then the memory region where the pointer parameter is located is determined to be a legal region that is allowed to be accessed; public regions that the kernel allows access to include the kernel public readable region.

[0050] As described above, this invention determines whether the memory region containing the pointer parameter belongs to a legal region that the application identity of the current task is allowed to access, including its own memory region, shared memory region, or kernel public region, in the pointer parameter verification step. This enables precise permission verification of pointer parameters in system calls in a single address space environment without an MMU, effectively preventing unauthorized access to memory across applications and improving memory isolation security during multi-application runtime.

[0051] The lightweight system application memory isolation method and terminal described above can be applied to Internet of Things devices, such as smartwatches, that are equipped with the OpenHarmony system but have no memory management unit (MMU). The following is a detailed description of the specific implementation.

[0052] The system architecture involved in this embodiment is as follows: Figure 2 As shown, the system is divided into static and dynamic memory areas. The static memory area is fixed during system compilation and includes the kernel memory area (which further includes the kernel code execution area and the kernel data read / write area), the System Core App memory area, and the shared memory area. The dynamic memory area is a runtime subdivision of the globally available memory pool, used to allocate independent memory areas for each ordinary application (such as application A and application B). Each dynamic memory area is bound to its application's APPID.

[0053] Step A: Refer to Figure 3 Upon system power-on reset, the kernel completes basic hardware initialization. This corresponds to step 101 above.

[0054] Step B: Based on the total system memory (e.g., 1MB) and pre-configuration, statically divide the basic memory space using fixed addresses. This results in a kernel memory area, a System Core App memory area, a shared memory area, and a red zone. The System Core App memory area only allows System Core Apps to read, write, and execute operations. The shared memory area allows all applications to read and write operations. The red zone is used for stack overflow protection, and all application tasks are prohibited from accessing it. These areas have fixed addresses and do not overlap. This corresponds to step 101 above.

[0055] Step C: The kernel reserves a dynamic partition management module and application registry interface in the system to prepare for subsequent dynamic management. After partitioning, all remaining memory is initialized as a globally available memory pool, managed uniformly by the kernel runtime memory allocator. At this point, the static memory isolation framework for the system startup phase is complete. This corresponds to step 101 above.

[0056] Step D: During the application installation phase, the Package Management Service (BMS) receives the installation request from the "Health Monitoring" application, parses the application package, and extracts memory requirement information. The BMS generates a globally unique and immutable APPID for the application, such as "0x00001001," and stores this APPID along with the application metadata in the application registry in the secure area. No RAM is allocated during this phase.

[0057] Step E: Reference Figure 4Upon receiving the instruction to launch the "Health Monitoring" application, the Application Management Service (AMS) sends an application launch request to the kernel, carrying the APPID "0x00001001" retrieved from the application registry. This corresponds to step 102 above.

[0058] Step F: The kernel runtime memory allocator checks the globally available memory pool. If memory is sufficient, the allocator allocates a contiguous memory region to the application, for example, starting at address 0x00080000 and with a size of 200KB. If memory is insufficient, the out-of-memory scheduler is activated, terminating low-priority applications to free up memory until sufficient memory is available. This corresponds to step 102 above.

[0059] Step G: The kernel memory marking module divides the contiguous memory region into code, data, heap, and stack areas. An APPID is added to the header of each memory block, recording the APPID "0x00001001" and the memory block size. This memory region is marked as "accessible only by APPID=0x00001001," and access by any other APPID will be blocked. This corresponds to step 103 above.

[0060] Step H: The kernel MPU management module dynamically generates a dedicated MPU configuration template for this application. The template has a fixed structure, but its content is dynamically generated based on the application's runtime state. Access to the memory areas of all other applications is explicitly prohibited in the template. This configuration template is stored in the kernel's private memory, and no application can access or modify it.

[0061] Step 1: The task binding module creates a new Task Control Block (TCB) for the application. The appId field in the TCB is forcibly set to "0x00001001". This prevents the application task from modifying its own or other tasks' appId fields, thus establishing a unique mapping between the task and the allocated memory region.

[0062] Step J: The kernel loads the application's executable code from flash memory into the allocated code segment and starts the application's task. At this point, the application has finished starting and enters runtime.

[0063] Step K: When the application runs, it calls the "mallo" function to request memory allocation. The kernel runtime verification module obtains the APPID of the current task and confirms it as "0x00001001". The verification module allocates memory from the application's dedicated memory sub-pool, the memory marking module adds the APPID marker to the header of the new block, and finally returns the memory pointer to the application.

[0064] Step L: When the application calls the "free" function to release memory, the kernel runtime verification module obtains the current task's APPID "0x00001001" and checks the APPID flag in the header of the target memory block. If the flag matches the current task's APPID, the data area content of the memory block is cleared, and the memory is returned to the application's dedicated memory sub-pool. If they do not match, the release is refused, a security log is recorded, and the offending application is terminated.

[0065] Step M: When an application calls a system call involving memory operations (such as the "memcpy" function), the kernel performs pre-interception and pointer validity checks on all pointer parameters. The kernel maintains a global memory region table that records the attribute information of all memory regions. During verification, the kernel performs three checks: First, it obtains the memory region where the pointer is located; second, it determines which region the pointer falls into; third, it determines whether the current application is allowed to access the pointer according to the rules. The rules are: pointers to the current application's own memory region, shared memory region, or kernel public readable region are allowed; pointers to other applications' memory regions or red zones are not allowed. Simultaneously, the kernel checks whether the access length exceeds the memory block boundary. Only after all verifications pass can the system call execute; if verification fails, execution is refused.

[0066] Step N: When the application exits, AMS receives an application exit notification and notifies the kernel. The kernel terminates all tasks of the application and clears all memory areas occupied by the application. The kernel removes the application's dedicated MPU configuration template from the MPU template pool. Finally, the kernel reclaims all memory blocks of the application and returns them to the globally available memory pool.

[0067] Please refer to Figure 5 The present invention also provides an application memory isolation terminal 210 for a lightweight system, including a memory 211, a processor 212, and a computer program stored on the memory 211 and executable on the processor 212. When the processor 212 executes the computer program, it implements the various steps of the application memory isolation method for a lightweight system as described above.

[0068] The beneficial effects of the terminal of the present invention are the same as those of the method described above, and will not be repeated here.

[0069] In summary, this invention addresses the data security issues caused by the lack of memory isolation mechanisms in lightweight, single-address-space systems without an MMU, specifically for multi-application runtime environments. By combining static memory partitioning during kernel startup with dynamic memory allocation at runtime, this invention achieves physical isolation between critical system areas and application runtime areas while ensuring efficient memory utilization. During application startup, by allocating contiguous memory regions for each application and binding them with a unique APPID, combined with a dedicated MPU configuration template and APPID marking in the task control block, a full-link security association is constructed from memory regions to task execution. At runtime, fine-grained memory access control is achieved through dynamic memory allocation, release, and APPID consistency verification in system calls, effectively preventing illegal memory access, memory tampering, and data leakage between applications. This invention does not rely on a hardware MMU; it achieves lightweight, highly secure multi-application memory logical isolation solely through software-layer memory marking and verification mechanisms, significantly improving the security and reliability of IoT operating systems.

[0070] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A lightweight system application memory isolation method, characterized in that, The method includes: After the system starts, at least one preset memory space is allocated from the total memory of the system, and the remaining memory space other than the preset memory space is used as a global available memory pool. Receive an application launch request and allocate a contiguous memory region from the global available memory pool for the target application corresponding to the application launch request. Add the application identity of the target application to the contiguous memory region so that the contiguous memory region is accessed only by the target application.

2. The method according to claim 1, characterized in that, The step of dividing the total memory of the system into at least one preset memory space includes: The total memory is divided into a kernel memory area for executing kernel code and reading and writing kernel data; The total memory is divided into a system core application memory area for running the system core application, and only the system core application is allowed to access it. The total memory is divided into a shared memory area for inter-application communication.

3. The method according to claim 1, characterized in that, The step of allocating a contiguous memory region from the globally available memory pool for the target application corresponding to the application startup request includes: Check the remaining memory capacity of the globally available memory pool; If the remaining memory capacity is greater than or equal to the memory requirement of the target application, then a contiguous memory region is allocated from the globally available memory pool; If the remaining memory capacity is less than the memory requirement of the target application, then the memory occupied by the lowest priority application in the global available memory pool is released until the remaining memory capacity is greater than or equal to the memory requirement of the target application.

4. The method according to claim 1, characterized in that, Before receiving the application launch request, the following is also included: Receive an application installation request, parse the application package corresponding to the target application installation request, and extract the memory requirement information of the application package; Assign a globally unique application identity to the application package; The memory requirement information of the application package and the application identity identifier are written into the application registry so that the memory area for the target application to run is allocated according to the application identity identifier when the target application starts.

5. The method according to claim 1, characterized in that, Also includes: Generate a memory protection unit configuration template corresponding to the target application; Load the code of the target application into the contiguous memory region; Create each task of the target application, and in the task control block of each task, set the application identity identifier of the task control block to the application identity identifier of the target application; Establish a mapping relationship between the task of the target application and the contiguous memory region, and start the task of the target application.

6. The method according to claim 5, characterized in that, Following the task of launching the target application, the following is also included: In response to a dynamic memory allocation request sent by the target application, obtain the application identity identifier of the task; Allocate a target memory block from the contiguous memory region corresponding to the application identity of the task; Add the application identity identifier of the task to the target memory block; Return the pointer to the target memory block to the target application.

7. The method according to claim 6, characterized in that, After returning the pointer to the target memory block to the target application, the method further includes: In response to a dynamic memory release request sent by the target application for a memory block to be released, the application identity identifier of the task is obtained; Read the temporary identifier of the memory block to be released; Determine whether the temporary identity of the memory block to be released is consistent with the application identity of the task; If there is a discrepancy, the release of the memory block to be released will be refused, a security log will be recorded, and the task will be terminated. If they match, the data area content of the memory block to be released is cleared, and the memory block to be released is returned to the dedicated memory sub-pool corresponding to the application identity of the task.

8. The method according to claim 5, characterized in that, Following the task of launching the target application, the following is also included: Intercept the pointer parameters passed to the target application when it makes system calls involving memory operations; Obtain the memory range where the pointer parameter is located; Determine whether the memory region containing the pointer parameter belongs to a legal region that the application identity of the task is allowed to access; Determine whether the access length of the pointer parameter exceeds the memory block boundary; If the memory region containing the pointer parameter is not a legally accessible area, or if the access length exceeds the memory block boundary, the system call will be refused.

9. The method according to claim 8, characterized in that, The step of determining whether the memory region containing the pointer parameter belongs to a legitimate region that the application identity of the task is allowed to access includes: If the pointer parameter points to the target application's own memory region, shared memory region, or public region that the kernel allows access to, then the memory region where the pointer parameter is located is determined to be a legal region that is allowed to be accessed.

10. An application memory isolation terminal for a lightweight system, comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements the application memory isolation method for a lightweight system as described in any one of claims 1 to 9.

Images