KASLR architecture design method and system based on SW64

By randomly setting the kernel running address, module address, and linear mapping area address under the SW64 architecture, the problems of low memory utilization and insufficient flexibility in the existing technology are solved, thereby improving system security and memory usage efficiency.

CN120893047APending Publication Date: 2025-11-04WUXI ADVANCED TECH RES INST
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511056060.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-07-30
Publication Date
2025-11-04

AI Technical Summary

Technical Problem

The existing KASLR mechanism under the SW64 architecture suffers from low memory utilization and lack of flexibility in kernel address randomization.

Method used

The KASLR design method based on the SW64 architecture is adopted. By randomly setting the kernel running address, module address, and linear mapping area address, memory randomization is achieved by using kernel page table mapping, avoiding physical copying and enhancing system security and flexibility.

Benefits of technology

It improves memory utilization, enhances system security and flexibility, reduces resource waste, and achieves more comprehensive address space layout randomization.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120893047A_ABST
    Figure CN120893047A_ABST
Patent Text Reader

Abstract

The invention provides an SW64-based KASLR architecture design method and system. The method comprises the following steps: randomly setting a kernel running address, a module address and a linear mapping area address on an SW64 architecture; the KASLR architecture design is completed through random setting of a kernel operation address, a module address and a linear mapping area address. On one hand, specific randomization design and implementation of the kernel, the module and the initial address of the linear mapping area are covered, memory layout adjustment and design implementation, kernel page table mapping mechanism adjustment and design implementation and architecture relocation design implementation are also covered, and the system security is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention discloses a KASLR architecture design method and system based on SW64, which relates to the field of computer architecture. Background Technology

[0002] KASLR (Kernel Address Space Layout Randomization) is a security technique designed to increase the difficulty for attackers to predict or exploit kernel vulnerabilities by randomizing the memory address layout of kernel code and data. It is an extension of user-mode ASLR (Address Space Layout Randomization) specifically for the operating system kernel. KASLR dynamically randomizes the kernel's base address (including critical memory areas such as code segments, data segments, and stack) during system startup, ensuring that the kernel's address layout is different each time the system boots. Even if an attacker discovers a kernel vulnerability, it is difficult to accurately locate the address of the target function or data structure, thus preventing exploitation.

[0003] The Linux kernel (since 2005) has supported KASLR. The randomization formula is: kernel chain address + random value = kernel runtime address. Due to differences in hardware characteristics, instruction sets, and hardware / software interfaces among various processor architectures, the KASLR mechanism needs to be implemented by architecture-specific kernel code and architecture-specific compilers.

[0004] The Shenwei processor features a 64-bit Shenwei proprietary architecture (SW64). Prior to SW64, the method of randomizing the kernel running address was the same as that of architectures such as MIPS and Loongarch. After calculating the random value in head.S, the kernel was copied to the new address using memcpy to achieve randomization of the kernel running address. This method requires allocating twice the physical memory for the kernel image (original image + copied copy) and lacks efficiency and flexibility. Summary of the Invention

[0005] This invention provides a KASLR architecture design method and system based on SW64, which solves the problems of low memory utilization and lack of flexibility in kernel address randomization.

[0006] To achieve the above-mentioned objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a KASLR architecture design method based on SW64, comprising the following steps:

[0008] Randomly set the kernel execution address on the SW64 architecture;

[0009] Randomly set module addresses on the SW64 architecture;

[0010] Randomly set the linear mapping region address on the SW64 architecture;

[0011] The KASLR architecture design was completed by randomly setting the kernel runtime address, module address, and linear mapping area address.

[0012] Furthermore, the random setting of the kernel running address includes:

[0013] The system control is handed over to the kernel, and the head.S stage is entered to obtain a random offset;

[0014] Based on the kernel page table, the kernel physical address is mapped to the virtual address obtained by adding the random offset to the link address, and the kernel is initially run at the mapped virtual address;

[0015] Symbol relocation is performed on symbols in the kernel that need to be relocated. Based on the address mapping relationship, the symbol reference addresses in the kernel code are corrected, and the randomized kernel running address is completed.

[0016] Preferably, the address mapping relationship is to map the kernel physical address to the virtual address obtained by adding the random offset to the link address.

[0017] Furthermore, mapping the kernel physical address to a virtual address obtained by adding the random offset to the link address, and initially running the kernel on the mapped virtual address, includes:

[0018] Perform kernel page mapping, establish temporary page table mapping, and map kernel physical addresses to virtual addresses with random offsets from kernel link addresses;

[0019] Establish a transition page table where the virtual address equals the physical address;

[0020] Change the value of the substitution mode register to switch the dial to page substitution, change the value of the page table pointer register so that the page table pointer register points to the transition page table, and realize the operation on the transition page table where the virtual address is equal to the physical address;

[0021] Change the value of the page table pointer register so that the page table pointer register points to the temporary page table;

[0022] Modify the stack pointer register, current thread register, and return address register, return to the head.S stage, and jump the current instruction pointer register to the new address;

[0023] The address replacement cache is refreshed, allowing operation on a temporary page table that runs on a virtual address with a random offset from the kernel link address.

[0024] Furthermore, it also includes initializing and establishing formal page tables, so that the kernel runs on formal page tables at random addresses.

[0025] This invention, based on the kernel page table, enables the kernel to randomize its execution address during each boot process, ensuring system security. By randomizing the kernel execution address, attackers find it difficult to predict the kernel's exact location, thus increasing the difficulty of attacks.

[0026] This invention implements address randomization based on page table mapping, avoiding physical copying, saving memory resources, and enhancing system security. The kernel, modules, and linear mapping regions can be randomized independently, providing greater flexibility.

[0027] Furthermore, symbol relocation is performed on symbols that require relocation, including global offset table and refquad type relocation.

[0028] The Global Offset Table (GOT) stores the addresses of global variables and external functions. At runtime, the program accesses these variables and functions through the GOT. Symbol relocation aims to dynamically update the addresses in the GOT during program execution, ensuring that the program can correctly access global variables and call external functions. Refquad type relocation handles references to function pointers defined in global variables, specifically relocating symbols of that type. Symbol relocation avoids symbol conflicts and memory access errors, improving system stability and security.

[0029] Furthermore, the random setting of the module address includes: implementing the architecture in the memory allocation function, applying a random offset to the module's virtual address base address, and changing the module loading region.

[0030] This invention randomizes the loading address of modules, making it difficult for malicious programs to predict the specific location of the modules and increasing the difficulty of attacks.

[0031] Furthermore, the random setting of the linear mapping region address includes: applying a random offset to the main memory mapping start address to achieve random setting of the linear mapping region start address.

[0032] Linear mapping regions are typically used to access physical memory. This invention, by randomizing their starting addresses, can prevent malicious programs from accessing or tampering with physical memory through fixed linear mapping region addresses.

[0033] Furthermore, it also includes: modifying the virtual address memory layout, including: moving the kernel from the linear mapping area to the first 4G address of the dynamic virtual memory mapping area, moving the module to the first 2G space of the dynamic virtual memory mapping area, and modifying macro definition functions.

[0034] This invention improves memory utilization efficiency and system flexibility by rearranging memory and optimizing memory allocation for the kernel and modules.

[0035] Furthermore, the random setting of the kernel running address, the random setting of the module address, and the random setting of the linear mapping region address are executed in parallel.

[0036] Secondly, the present invention provides a system comprising:

[0037] The kernel runtime address randomization module is used to randomly set the kernel runtime address on the SW64 architecture;

[0038] The module address randomization module is used to randomly set the module address on the SW64 architecture;

[0039] The linear mapping area address randomization module is used to randomly set the linear mapping area address on the SW64 architecture;

[0040] The implementation module is used to complete the KASLR architecture design by randomly setting the kernel running address, module address, and linear mapping area address.

[0041] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, characterized in that, when the computer program is executed by a processor, it implements the design method as described in any of the first aspects.

[0042] Beneficial effects:

[0043] This invention fundamentally avoids doubling memory consumption by randomly setting the kernel running address, eliminating the need for a complete copy of the kernel image, thus improving memory utilization, reducing resource waste, and adapting to the kernel page table structure. Randomly setting module addresses allows modules to dynamically adjust their address space as needed, without pre-allocating fixed memory regions at startup, resulting in greater flexibility. Randomly setting linear mapping area addresses improves main memory access security. Simultaneously, randomizing the kernel running address, module addresses, and linear mapping area addresses enables more comprehensive address space layout randomization, thereby significantly improving system security.

[0044] This invention presents a KASLR architecture design method based on the SW64 architecture. It covers the specific randomization design and implementation of the kernel, modules, and the starting addresses of the linear mapping region. It also encompasses memory layout adjustment and design implementation, kernel page table mapping mechanism adjustment and design implementation, and architecture relocation design implementation. This method offers high randomization efficiency and flexibility. Specifically, kernel image randomization is mainly achieved through memory layout adjustment, kernel page table mapping mechanism adjustment, and relocation. Furthermore, it implements random design for modules and random design for linear mapping region addresses, thereby improving system security. Attached Figure Description

[0045] Figure 1 This is a flowchart of the KASLR architecture design method of the present invention;

[0046] Figure 2 This is a schematic diagram illustrating the randomization setting of the kernel running address based on the kernel page table according to the present invention;

[0047] Figure 3 This is a schematic diagram of the module loading address randomization process of the present invention;

[0048] Figure 4 This is a schematic diagram of the SW64 memory layout of the present invention. Detailed Implementation

[0049] The invention will now be further described with reference to the accompanying drawings.

[0050] Example 1

[0051] This invention aims to develop KASLR technology for Linux based on the SW64 architecture. It implements KASLR technology on the basis of page table paging in the SW64 kernel, which randomizes the kernel running virtual address, module allocation address, and the starting address of the linear mapping area. This is comprehensive, efficient, and also improves kernel security.

[0052] like Figure 1 As shown, a KASLR architecture design method based on SW64 includes the following steps:

[0053] Randomizing the kernel's running address: The kernel's link address (virtual address) is defined in the Linux kernel linker script root / arch / sw_64 / kernel / vmlinux.lds.S. During kernel runtime, a random seed is introduced, causing the kernel to run at a virtual address different from the link address, thus randomizing the kernel's running address and enhancing kernel security.

[0054] Randomize module address settings: When a module is loaded into memory, space is allocated to the module. At this time, the module's memory address is randomized so that the memory address allocated to the module is random.

[0055] Randomize the address of the linear mapping area: In the memory layout of the architecture, the physical memory address is in the linear mapping area. The starting address (physical address) of the physical memory address is randomized. Because of the direct mapping, the virtual address corresponding to the physical memory address is also randomly offset.

[0056] The KASLR architecture design is achieved through the above random settings.

[0057] In the above steps, randomizing the kernel execution address is the most critical step. The KASLR function takes effect after enabling the corresponding option CONFIG_RANDOMIZE_BASE=y.

[0058] This invention presents a KASLR architecture design method based on the SW64 architecture. It covers the specific randomization design and implementation of the kernel, modules, and the starting addresses of the linear mapping region. It also encompasses memory layout adjustment and design implementation, kernel page table mapping mechanism adjustment and design implementation, and architecture relocation design implementation. This method offers high randomization efficiency and flexibility. Specifically, kernel image randomization is mainly achieved through memory layout adjustment, kernel page table mapping mechanism adjustment, and relocation. Furthermore, it implements random design for modules and random design for linear mapping region addresses, thereby improving system security.

[0059] Furthermore, such as Figure 2 As shown, randomizing the kernel execution address includes:

[0060] Control is handed over to the kernel, and head.S is entered. During the startup process, a 2M aligned random offset is obtained.

[0061] The kernel page table is mapped to a virtual address that is the linker address plus a random offset.

[0062] Symbol relocation is performed on symbols that need to be relocated, the symbol reference addresses in the kernel code are corrected, and the random setting of the kernel running address is completed.

[0063] The specific implementation of KASLR varies across different architectures, but its core mechanism is based on randomizing the kernel runtime address through random offsets. After the new memory mapping is completed, because the virtual address has changed, symbol relocation is then performed on the symbols that need to be relocated, correcting the symbol reference addresses in the kernel code to ensure the correctness of instruction execution.

[0064] It's worth noting that the compiler compiles the kernel into position-independent code, addressing global variables and functions based on the current program counter (PC). This ensures the smooth execution of the randomization process. For example, after relocation, the addresses (virtual addresses) of global variables have changed, and the mapped code will use these global variables. Without position-independent code, the old mapping relationship would still exist, leading to problems if the addresses of global variables weren't retrieved through the PC. Therefore, mapping must precede relocation. Furthermore, in paged operation, the SW64 kernel uses address 0xfff0000000000000 to perform a substitution (subtracting the 0xfff header) to obtain the physical address. However, the kernel link address is 0xfffff000000000000, causing global variable addresses to reside at the 0xfffff header virtual address (meaning that subtracting the 0xfff header from addresses starting with 0xfffff would not yield the correct physical address). Therefore, position-independent code, independent of absolute addresses, is required before establishing paged mapping to ensure proper operation.

[0065] Furthermore, control is handed over to the kernel, entering head.S, where a 2M aligned random offset is obtained during startup, including:

[0066] 1) First, the kernel gains control and runs in head.S. SW64 has a unique dial-up substitution mode. Before paged mapping, the kernel is in dial-up substitution mode, that is, the virtual address is accessed by subtracting 0xfff00000000000000;

[0067] 2) Obtain a 2M aligned random offset.

[0068] Furthermore, the kernel page table is mapped to the virtual address after the linker address plus a random offset, including...

[0069] 1) Jump to the temporary page table function in root / arch / sw_64 / mm / init.c to perform kernel page mapping. First, establish a temporary page table and fixmap page table to support initial operation. The temporary page table maps the kernel to the virtual address of link address (0xfffff00000000000) + s random offset.

[0070] 2) Then establish a transition page table where VA=PA (virtual address equals physical address) (after switching to paged mapping, the original address was a physical address, but now it is a random virtual address. The code segment address has changed, and the current instruction pointer register needs to jump to the new address to run. Therefore, the jump statement needs to run on the transition page table).

[0071] 3) Change the value of the ATC (substitution mode) register to switch to page replacement mode. Change the value of the PTBR (page table pointer) register to point to the transition page table, thus operating on the transition page table where VA=PA;

[0072] 4) Change the value of the PTBR (page table pointer) register to point to the temporary page table;

[0073] 5) Change the values ​​of SP (stack pointer register) and $8 (current thread register), modify ra (return address register), return to head.S, and successfully jump PC (current instruction pointer register) to the new address;

[0074] 6) Flush the TLB (address substitution cache), so it is now running on a temporary page table with a kernel link address plus a random offset (KASLR offset) virtual address;

[0075] 7) Subsequent initialization functions related to startup are executed until the paging_init() function establishes the formal page table. The mapping is also mapped to the kernel link address + random offset virtual address. Then, the PTBR is modified to point to the formal page table, and the kernel runs on the formal page table at the random address.

[0076] This invention relates to a kernel image randomization technique based on kernel page tables under the SW64 architecture. It designs a new memory layout to support KASLR and adjusts the kernel image link address. Compared with simple memcpy (memory copy) and relocation, it forms a more complete and efficient kernel image randomization technique based on kernel page tables.

[0077] Furthermore, symbol relocation is performed on symbols that require relocation, including relocation of GOT tables and Refquad types.

[0078] The core idea of ​​this invention's relocation design is to modify the addresses of global variables and functions. Global variables and functions are stored in the GOT table (Global Symbol Offset Table), which stores variable addresses. Therefore, it is necessary to modify the originally stored variable addresses by traversing the GOT table one by one and adding a random offset to each entry.

[0079] Secondly, the SW64 architecture also includes refquad type relocation in its relocation types, which is used to handle references to function pointers defined in global variables. Therefore, in addition to the GOT table, refquad type relocation also needs to be modified. The relocation information is stored in the kernel's .data.reloc segment. The relocation entry of the refquad type is found and modified. The relocation type is calculated as type=(*r >> 24) & 0xf, and the pointer to the variable address is loc = (kbase_old + ((*r & 0x00ffffff) << 2)). kbase_old is the starting address of the kernel code segment, so *(unsigned long *)loc += offset adds a random offset to the variable address.

[0080] This invention designs a method for relocating the kernel's runtime address after modification under the SW64 architecture. By modifying the GOT table and architecture relocation entries based on the architecture characteristics, it ensures that the kernel can run normally from any location.

[0081] Furthermore, module addresses are randomly set, including: implementing the architecture in module_alloc, applying a random offset to MODULES_VADDR, and changing the module loading region.

[0082] like Figure 3 The diagram shows the module loading process. When allocating memory space for a module, we apply a random offset to the module's starting address MODULES_VADDR. The module offset is in the range of 0x1000-0x400000.

[0083] Furthermore, the address of the linear mapping area is randomly set, including: applying a random offset to the starting address of the main memory to achieve random setting of the starting address of the linear mapping area.

[0084] The linear mapping region contains physical memory and I / O memory, etc. The linear mapping region uses a direct mapping method, mapping one-to-one. The virtual address is obtained by adding page_offset to the physical address. The starting address of the physical memory is randomized. The starting address of the physical memory is randomized in the architecture memblock_init. Here it is the physical address. Because of the direct mapping, after mapping the virtual address, the virtual address of the physical memory is also randomized.

[0085] As mentioned earlier, the physical memory is obtained through memblock_start_of_DRAM() and memblock_end_of_DRAM(). The range of random numbers is obtained by subtracting the physical memory size from the size of the linear mapping region, and then appended to the physical memory base address.

[0086] Furthermore, this also includes modifications to the SW64 virtual address memory layout.

[0087] The SW64 virtual address memory layout before and after modification is as follows: Figure 4 As shown, this invention modifies the SW64 virtual address memory layout to provide support for KASLR, specifically including: moving the kernel from the linear mapping area to the first 4G address of the vmalloc area (0xfffff000000000000), moving the module to the first 2G space of the vmalloc area, and modifying the macro definition function pa.

[0088] First and foremost, the kernel space was modified. Originally, the kernel resided in the linearly mapped region. Randomizing the kernel's runtime address would cause conflicts and problems with the physical memory in the linearly mapped region. Therefore, the kernel was moved from the linearly mapped region to the first 4GB address of the vmalloc region (dynamic virtual memory mapping region), address 0xfffff000000000000 (2GB of the first 4GB of the vmalloc region is allocated to the kernel, and 2GB to modules). We first changed the kernel linker address to 0xfffff00000000000 in the vmlinux.lds.S linker script, and then introduced random numbers to map to the new address during mapping. The reason for allocating the kernel to a specific 2GB region, rather than simply allocating it in the vmalloc region, is to place the kernel in an independent space to avoid conflicts with other uses of the vmalloc region. For example, during startup, vfs_dcache initializes the virtual file system (VFS) caches (Dentry cache, Inode-cache, Mount-cache, Mountpoint-cache), and the hash table memory for these caches is allocated in the vmalloc region via vmalloc.

[0089] Secondly, there is module randomization. Modules were originally in the vmalloc area, and were allocated wherever there was space. This had a potential problem: if vmalloc was occupied by a large application, the memory addresses of different segments of the same module would be far apart, exceeding the distance limit for module relocation. Therefore, the modules were moved to the first 2GB of space in the vmalloc area, and the module starting address was randomized in the module_alloc implementation, i.e., MODULES_VADDR.

[0090] Finally, and equally importantly, the macro function `pa` (which obtains the corresponding physical address from the virtual address in both physical memory and the kernel) needs to be modified accordingly. Previously, as shown in the diagram, simply subtracting 0xfff00000000000000 was sufficient to obtain the physical address. Now, it needs to be determined whether the current virtual address is in the linearly mapped region or the kernel virtual address region. For the linearly mapped region, subtracting 0xfff0000000000000 is sufficient; for the kernel mapped region, subtracting (0xfffff000000000000 + random offset) gives the physical address.

[0091] This invention is based on the KASLR architecture design method under the SW64 architecture. It realizes the randomness of the kernel image, module and physical memory start address during runtime under the SW64 architecture, improves the security of system operation, and completes the architecture adaptation of KASLR under the SW64 architecture.

[0092] Example 2

[0093] In one embodiment of the present invention, a KASLR architecture design system based on SW64 is also provided. The system includes a kernel runtime address randomization module for randomly setting the kernel runtime address on the SW64 architecture; a module address randomization module for randomly setting the module address on the SW64 architecture; a linear mapping region address randomization module for randomly setting the linear mapping region address on the SW64 architecture; and an implementation design module for completing the KASLR architecture design through the randomization of the kernel runtime address, module address, and linear mapping region address. Each module of the design system can be stored in a processor, which is used to perform operations according to the instructions to execute the steps of the method described in Embodiment 1.

[0094] The system may include, but is not limited to, at least one processor, at least one memory, and a bus connecting different system components (including the memory and the processor). The memory stores program code that can be executed by the processor, causing the processor to perform the steps described in the "Exemplary Methods" section above, according to various exemplary embodiments of the present invention. For example, the processor may perform, as... Figure 1 The steps are shown.

[0095] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0096] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0097] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus that uses any of the various bus structures.

[0098] The system can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the system, and / or any device that enables the system to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, the system can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter. The network adapter communicates with other modules of the system via a bus.

[0099] It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the system, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0100] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0101] Example 3

[0102] In exemplary embodiments of the present invention, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of the present invention may also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps of the various exemplary embodiments of the present invention described in the "Exemplary Methods" section above.

[0103] The program product for implementing the above-described method according to embodiments of the present invention may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0104] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0105] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of outputting, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0106] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0107] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0108] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A KASLR architecture design method based on SW64, characterized in that, Includes the following steps: Randomly set the kernel execution address on the SW64 architecture; Randomly set module addresses on the SW64 architecture; Randomly set the linear mapping region address on the SW64 architecture; The KASLR architecture design was completed by randomly setting the kernel runtime address, module address, and linear mapping area address.

2. The KASLR architecture design method based on SW64 according to claim 1, characterized in that, The random setting of the kernel running address includes: The system control is handed over to the kernel, and the head.S stage is entered to obtain a random offset; Based on the kernel page table, the kernel physical address is mapped to the virtual address obtained by adding the random offset to the link address, and the kernel initially runs at the mapped virtual address; symbol relocation is performed on the symbols in the kernel that need to be relocated, and the symbol reference addresses in the kernel code are corrected based on the address mapping relationship, thus completing the randomization of the kernel running address.

3. The KASLR architecture design method based on SW64 according to claim 2, characterized in that, Mapping the kernel physical address to a virtual address obtained by adding the random offset to the link address, and initially running the kernel on the mapped virtual address, includes: Perform kernel page mapping, establish temporary page table mapping, and map kernel physical addresses to virtual addresses with random offsets from kernel link addresses; Establish a transition page table where the virtual address equals the physical address; Change the value of the substitution mode register to switch the dial to page substitution, change the value of the page table pointer register so that the page table pointer register points to the transition page table, and realize the operation on the transition page table where the virtual address is equal to the physical address; Change the value of the page table pointer register so that the page table pointer register points to the temporary page table; Modify the stack pointer register, current thread register, and return address register, return to the head.S stage, and jump the current instruction pointer register to the new address; The address replacement cache is refreshed, allowing operation on a temporary page table that runs on a virtual address with a random offset from the kernel link address.

4. The KASLR architecture design method based on SW64 according to claim 2, characterized in that, Symbol relocation is performed for symbols that need to be relocated, including global offset table and type relocation.

5. The KASLR architecture design method based on SW64 according to claim 1, characterized in that, The random setting of the module address includes: implementing the architecture in the memory allocation function, applying a random offset to the module's virtual address base address, and changing the module's loading region.

6. The KASLR architecture design method based on SW64 according to claim 1, characterized in that, The random setting of the linear mapping region address includes: applying a random offset to the main memory mapping start address to achieve random setting of the linear mapping region start address.

7. The KASLR architecture design method based on SW64 according to claim 2, characterized in that, Also includes: Modifying the virtual address memory layout includes: moving the kernel from the linear mapping area to the first 4GB of the dynamic virtual memory mapping area, moving the modules to the first 2GB of the dynamic virtual memory mapping area, and modifying macro definition functions.

8. The KASLR architecture design method based on SW64 according to claim 1, characterized in that, The random setting of the kernel running address, the random setting of the module address, and the random setting of the linear mapping region address are executed in parallel.

9. A system, characterized in that, include: The kernel runtime address randomization module is used to randomly set the kernel runtime address on the SW64 architecture; The module address randomization module is used to randomly set the module address on the SW64 architecture; The linear mapping area address randomization module is used to randomly set the linear mapping area address on the SW64 architecture; The implementation module is used to complete the KASLR architecture design by randomly setting the kernel running address, module address, and linear mapping area address.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the design method as described in any one of claims 1-8.