WO2024048922A1 - 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치 및 방법 - Google Patents

커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치 및 방법 Download PDF

Info

Publication number
WO2024048922A1
WO2024048922A1 PCT/KR2023/007599 KR2023007599W WO2024048922A1 WO 2024048922 A1 WO2024048922 A1 WO 2024048922A1 KR 2023007599 W KR2023007599 W KR 2023007599W WO 2024048922 A1 WO2024048922 A1 WO 2024048922A1
Authority
WO
WIPO (PCT)
Prior art keywords
processor
physical address
kernel code
page table
kernel
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2023/007599
Other languages
English (en)
French (fr)
Inventor
문현곤
하선
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
UNIST Academy Industry Research Corp
Original Assignee
UNIST Academy Industry Research Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by UNIST Academy Industry Research Corp filed Critical UNIST Academy Industry Research Corp
Publication of WO2024048922A1 publication Critical patent/WO2024048922A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the operating system kernel may contain privileged software components that manage the system at various levels.
  • the code that the kernel executes may exist at the center of the kernel. The code defines how the kernel operates, so it may need to be kept intact at runtime. Kernel code integrity can refer to the characteristics by which code executed by the kernel must remain intact at runtime. Kernel code integrity can be violated by an attacker in two ways.
  • kernel code integrity can be violated through modification of kernel code by an attacker.
  • the processor can be made to execute modified code with the privileges of the kernel. For example, by overwriting some system call handlers, an attacker can change the way the kernel handles the target system call.
  • kernel code integrity can be violated through execution from a new location (e.g. a data page) that does not contain kernel code.
  • the kernel may not normally jump to this new location, but an attacker may be able to manipulate one or more pointers to the code, such as return addresses or function pointers, that the kernel uses to determine indirect jump targets.
  • Attackers may have incentives to violate kernel code integrity. Incentives may include providing the victim with a high level of freedom to manipulate the system. For example, a jailbreak tool for iOS devices can patch the kernel to install applications from outside the Apple App Store, typically when the device is not protected by the page table-based protection described above. Even if some user-level programs attempt to determine whether a device is based on the Android platform, these attackers can easily nullify the check by injecting code into the kernel.
  • KPP Kernel Patch Protection
  • the older iOS may also have a similar feature.
  • KPP Kernel Patch Protection
  • Many existing and deployed protection mechanisms can ensure that kernel code content is not modified by an attacker exploiting unknown vulnerabilities by periodically examining snapshots of kernel code pages. Unfortunately, an attacker who knows these defenses can bypass them by modifying the kernel only between checks.
  • a more powerful mechanism to defeat such manipulation is to use page table properties, but by relying on a more privileged software layer (e.g. hypervisor) or by sacrificing the flexibility of page table management, the integrity of the page table. You can ask for this to be guaranteed.
  • hypervisor software layer
  • Hypervision and SPROBES may rely on Secure Monitor and Secure OS protected by TrustZone
  • HVCI may rely on a hypervisor. Details about KTRR are not disclosed, but the mechanism can limit the flexibility of managing the kernel's virtual address space by limiting updates to the kernel page tables.
  • the RISC-V ISA specification already includes standards for implementing some form of physical address-based access control, and a working group may be preparing an enhanced version.
  • This extension is called physical memory protection (PMP), and can primarily be designed to prevent supervisor mode (e.g. kernel mode) programs and user mode programs from accessing the addresses of machine mode programs.
  • PMP physical memory protection
  • This standard can define four configuration registers that can define up to 16 different physical address ranges and corresponding access control policies. The priorities of the 16 ranges can be strictly specified such that at most one of the 16 policies applies to one physical address.
  • Physical Memory Protection has proven useful in protecting machine layer software, but may not be used to protect kernel code integrity.
  • Physical Memory Protection can associate with each address range three bits representing readable (R), writable (W), and executable (X) permissions, which are It may be possible to create execution-only physical memory regions.
  • the operating system kernel can request that machine mode software use these properties to make code pages execution-only to protect them.
  • the kernel cannot prevent itself from being tricked into executing outside of kernel code pages. This may be because Physical Memory Protection (PMP) does not take into account the mode in which the processor is currently running and only applies one of the 16 policies it defines for a specific physical address.
  • PMP Physical Memory Protection
  • PMP Physical Memory Protection
  • Only one permission can be associated with each address due to the address matching specification.
  • address ranges of supervisor and user programs may need to be marked as executable in order to delegate access control to those pages to a supervisor-level program.
  • the page can be executed even in machine mode.
  • machine mode vulnerabilities could include an attacker being able to execute payloads located in the user's memory while the processor is running in machine mode.
  • a draft of the enhanced specification considers the execution of external code in machine mode as a threat and may include a processor-like specification according to one embodiment.
  • the new specification may make it impossible to execute addresses that do not fall within the configured address range in machine mode. Therefore, while the processor uses address range registers to define an allowlist of executable code pages, registers can currently only be denylists for physical memory protection (PMP).
  • a method for controlling operations in the kernel code area performed by a processor is to use the physical address of the kernel code area where the kernel code is stored while the processor is in machine mode. It may include the step of configuring a range register based on the address.
  • a method for controlling operations on a kernel code area performed by a processor includes when the processor receives an access request based on the virtual address of a page while in kernel mode. In response, the method may include obtaining the physical address of the page using a page table entry for the virtual address of the page.
  • a method for controlling operations on a kernel code area performed by a processor includes comparing the set range register with the obtained physical address, so that the area corresponding to the obtained physical address is the kernel code area.
  • a method for controlling operations on a kernel code area performed by a processor includes, based on whether the area corresponding to the obtained physical address is included in the kernel code area, It may include determining whether to enable or disable at least one of a write operation or an execution operation for the area.
  • the step of determining whether to enable or disable at least one of the write operation and the execution operation may include, in response to a case where an area corresponding to the obtained physical address is included in a kernel code area, It may include disabling a write operation for the corresponding area.
  • the step of determining whether to enable or disable at least one of the write operation and the execution operation may include, in response to a case where an area corresponding to the obtained physical address is included in a kernel code area, the processor It may include enabling an execute operation for an area corresponding to the physical address while in the mode.
  • the step of determining whether to enable or disable at least one of the write operation and the execution operation may include, in response to a case where an area corresponding to the obtained physical address is included in an area different from a kernel code area, It may include disabling an execute operation for an area corresponding to the physical address while the processor is in kernel mode.
  • the step of determining whether to enable or disable at least one of the write operation and the execution operation may be performed independently of a page table attribute of the page table entry. It may include a step of determining whether to enable or disable.
  • Setting the range register may include aligning pages containing kernel code according to the boundary of a chunk having a predetermined size while the processor is in machine mode. .
  • Setting the range register may include storing the kernel code as at least one kernel code chunk.
  • Setting the range register may include, for each kernel code chunk, setting at least a portion of the range register corresponding to the corresponding kernel code chunk.
  • Setting the range register includes setting a valid bit and a lock bit of the range register in response to setting the base bit and mask bit of the range register. can do.
  • Obtaining the physical address of the page may include checking whether the page table entry for the virtual address of the access request is cached in a translation lookaside buffer (TLB). You can.
  • a method for controlling an operation on a kernel code area performed by a processor according to an embodiment includes, in response to a case where the page table entry is cached in the translation index buffer, the set range register and the obtained physical A step of omitting address comparison may be included.
  • a method for controlling operations on a kernel code region performed by a processor includes, in response to a case where the page table entry is cached in a translation index buffer, based on a page table attribute of the page table entry. This may include determining whether to enable or disable the at least one operation.
  • a method for controlling an operation on a kernel code region performed by a processor includes determining a page table attribute of the page table entry based on whether to enable or disable the determined at least one operation. It may include an updating step.
  • a method for controlling an operation on a kernel code region performed by a processor may include caching the updated page table attribute together with the page table entry in a translation index buffer.
  • the step of determining whether a region corresponding to the obtained physical address is included in a kernel code region may include determining a partial address of the physical address based on a mask bit of the range register.
  • the step of determining whether the area corresponding to the acquired physical address is included in the kernel code area may include, if the determined partial address matches at least a portion of the base bits of the range register, the area corresponding to the acquired physical address. It may include the step of determining what is included in the kernel code area.
  • An electronic device for controlling operations in a kernel code area is based on the physical address of the kernel code area where the kernel code is stored while the processor is in machine mode. configure a range register, and in response to receiving an access request based on the virtual address of the page while the processor is in kernel mode, the virtual address of the page The physical address of the page is obtained using a page table entry, and by comparing the set range register with the obtained physical address, the area corresponding to the obtained physical address is in the kernel code area. determines whether the area corresponding to the obtained physical address is included in the kernel code area, and performs at least one of a write operation or an execution operation on the area corresponding to the physical address. It may include a processor that determines whether to enable or disable.
  • the processor may determine whether to enable or disable at least one of the write operation and the execution operation. In response to a case where the area corresponding to the obtained physical address is included in the kernel code area, the processor may disable a write operation on the area corresponding to the physical address.
  • the processor may determine whether to enable or disable at least one of the write operation and the execution operation.
  • the processor in response to a case where the area corresponding to the obtained physical address is included in the kernel code area, enables an execute operation for the area corresponding to the physical address while the processor is in kernel mode. can do.
  • the processor may determine whether to enable or disable at least one of the write operation and the execution operation.
  • the processor in response to a case where the region corresponding to the obtained physical address is included in a region different from a kernel code region, executes an execute operation on the region corresponding to the physical address while the processor is in kernel mode. can be disabled.
  • the processor may determine whether to enable or disable at least one of the write operation and the execution operation.
  • the processor may determine whether to enable or disable the at least one operation independently of the page table attribute of the page table entry.
  • the processor may align pages containing kernel code according to the boundary of a chunk having a predetermined size while the processor is in machine mode.
  • the processor may store the kernel code as at least one kernel code chunk.
  • the processor may set, for each kernel code chunk, at least a portion of a range register corresponding to the kernel code chunk.
  • the processor may set the base bit of the range register corresponding to the kernel code chunk based on the starting physical address of each kernel code chunk.
  • the processor may set a mask bit of a range register corresponding to the kernel code chunk based on the size of the kernel code chunk.
  • the processor may set a valid bit and a lock bit of the range register in response to setting the base bit and mask bit of the range register.
  • the processor may check whether the page table entry for the virtual address of the access request is cached in a translation lookaside buffer (TLB).
  • TLB translation lookaside buffer
  • the processor may, in response to the case where the page table entry is cached in the translation index buffer, omit comparison of the set range register and the obtained physical address.
  • the processor may determine whether to enable or disable the at least one operation based on a page table attribute of the page table entry.
  • the processor may retrieve the page table entry for the virtual address from the page table.
  • the processor may obtain the physical address of the page mapped to the virtual address based on the retrieved page table entry.
  • the processor may update the page table attribute of the page table entry based on whether the determined at least one operation is enabled or disabled.
  • the processor may cache the updated page table attributes along with the page table entries in a translation index buffer.
  • the processor may determine a partial address among the physical addresses based on the mask bit of the range register.
  • the processor may determine that an area corresponding to the obtained physical address is included in the kernel code area when the determined partial address matches at least a portion of the base bits of the range register.
  • Kernel code integrity can be ensured without first protecting kernel page table integrity.
  • a small hardware extension that checks all memory accesses can be introduced by reusing the processor's access control logic.
  • a processor according to one embodiment may be designed and implemented to have a small impact not only on performance and energy consumption, but also on chip area and critical path delay. Mechanisms can be comprehensively evaluated.
  • the processor according to one embodiment can be implemented by extending the implementation of the RISC-V SoC and Rocket Chip in RTL to evaluate the proposed microarchitectural changes, and can be evaluated through experiments on an FPGA-based prototype.
  • FIG. 1 is a diagram for explaining the operation of a processor according to an embodiment.
  • FIG. 2 is a diagram illustrating a method for a processor to control operations in a kernel code area, according to an embodiment.
  • Figure 3 is a diagram for explaining a range register setting operation according to one embodiment.
  • FIG. 4 is a diagram illustrating the structure of a range register with a plurality of bits according to an embodiment.
  • FIG. 5 is a diagram illustrating an operation of a processor acquiring a physical address mapped to a virtual address of an access request, according to an embodiment.
  • FIG. 6 is a diagram illustrating an operation of a processor determining whether an area corresponding to a physical address is included in the kernel code area, according to an embodiment.
  • FIG. 7 is a diagram illustrating an operation of a processor determining whether to enable or disable an operation for an area corresponding to a physical address, according to an embodiment.
  • FIG. 8 is a diagram illustrating an operation of a processor updating page table properties when a page table entry for a virtual address of an access request is not cached in a translation index buffer, according to an embodiment.
  • FIG. 9 is a diagram illustrating an operation of a processor updating page table properties when a page table entry for a virtual address of an access request is cached in a translation index buffer, according to an embodiment.
  • FIG. 10 is a diagram illustrating the results of measuring the performance of a processor according to an embodiment and a processor according to a comparative example using LMBench.
  • FIG. 11 illustrates the execution time of a workload of a system having a processor according to an embodiment normalized to the execution time of a system having a processor according to a comparative embodiment according to an embodiment.
  • Figure 12 shows normalized execution times of 12 workloads of the SPEC 2006 benchmark suite according to one embodiment.
  • FIG. 13 is a diagram illustrating normalized additional energy consumption of a processor according to an embodiment.
  • first or second may be used to describe various components, but these terms should be interpreted only for the purpose of distinguishing one component from another component.
  • a first component may be named a second component, and similarly, the second component may also be named a first component.
  • FIG. 1 is a diagram for explaining the operation of a processor according to an embodiment.
  • the processor may use virtual memory technology to process data access by programs running on the processor.
  • programs may include applications, operating systems, device drivers, virtual machines, software executed by peripheral devices, etc.
  • blocks or "pages" of a certain size e.g., 4 kB, 2 MB
  • a mass storage device e.g., disk drive, semiconductor memory
  • the processor can track the physical locations of pages relative to programs.
  • programs can access memory using virtual addresses in virtual address spaces, which are local address spaces specific to the corresponding programs. there is.
  • virtual addresses represent the actual physical locations where data is stored in memory, and thus programs can use virtual addresses to perform memory accesses.
  • virtual addresses may not map directly to physical addresses of actual locations where data is stored in pages of memory.
  • the processor may translate virtual addresses used by programs in memory access requests to physical addresses where the data is actually located. The processor can then use the physical addresses to perform memory access to programs.
  • the processor may abstract the physical address of main memory into a virtual memory address used by the program. Conversion between virtual and physical addresses may be performed by hardware, typically referred to as a memory management unit (MMU).
  • MMU memory management unit
  • the memory management unit may include page tables.
  • a page table may contain records stored in the processor's memory that include page table entries (PTEs) (or entries) and virtual address to physical address translation information for pages of data stored in memory. there is.
  • PTEs page table entries
  • a page table may have mappings to physical addresses that correspond to virtual addresses.
  • a lookup in the page table may be referred to as a page table walk and may be performed by hardware in a memory management unit (MMU), referred to as a page table walker (PTW).
  • MMU memory management unit
  • PGW page table walker
  • the processor uses translation lookaside buffers (TLBs), which are local caches used to store a limited number of copies of page table entries (or information based on page table entries) obtained during page table walks. Includes. During operation, the processor may attempt to obtain cached page table entries from the TLB in order to perform translations between virtual and physical addresses.
  • TLBs translation lookaside buffers
  • Multiple page table entries can be stored in the TLB. If the page table entry for the virtual address of the access request is cached within the TLB (e.g., a TLB hit), the corresponding translation may be immediately available. If the page table entry for the virtual address of the access request is not cached in the TLB (e.g., a TLB miss), the page table entry is acquired through a page table walk, and a copy of the acquired page table entry is stored in the TLB. Can be cached.
  • RISC-V may include an open source implementation of the reduced instruction set computing (RISC) instruction set architecture (ISA). Metadata tags are placed in both the instructions and data for each word.
  • RISC-V architecture a word can be 64 bits.
  • RISC-V architecture can provide different word size scalability.
  • RV64 may be a 64-bit word size
  • RV32 may be a 32-bit word size.
  • the width or size of registers and user address space may vary depending on word size.
  • the tag size or width may be independent of the word size or width, but illustratively, the tag size or width may be the same as the word size or width.
  • the RISC-V architecture is described, for example, in ["The RISC-V Instruction Set Manual Vol. I, User-Level ISA, Version 2.0", May 6, 2014, Waterman, Andrew, et. al., ("also referred to as the "RISC-V user level ISA"), which is incorporated herein by reference and, for example, on the RISCV.ORG web It is available to the public as Technical Report UCB/EECS-2014-54 through the site and the University of California, Berkeley.
  • the RISC-V architecture is also available, for example, in ["The RISC-V Instruction Set Manual Volume II: Privileged Architecture, Version 1.7", May 9, 2015, also referred to as the "RISC-V privileged ISA”], privileged instructions and It incorporates a privileged architecture that includes additional functionality, which is incorporated herein by reference and, for example, Technical Report UCB/EECS-2015-49 via the RISCV.ORG website and the University of California, Berkeley. It is available to the public as.
  • An embodiment of the RISC-V architecture may have four RISC-V privilege levels: level 0 for the user/application (U) privilege level, and level 0 for the supervisor (S) privilege level. Level 1, level 2 for the hypervisor (H) privilege level, and level 3 for the machine (M) privilege level.
  • the processor can have user/application privilege levels while in user mode. there is.
  • a processor, while in kernel mode may have a supervisor privilege level.
  • a processor, while in machine mode can have machine privilege levels.
  • RISC-V privilege levels can be ranked from 0 to 3, highest to lowest, with level 0 representing the lowest privilege level and level 3 representing the highest privilege level. These privilege levels can be used to provide protection between different components, and can cause an exception, such as a trap, to be redirected to the default execution environment if an attempt is made to execute code that performs an operation not permitted by the current privilege level or mode. there is.
  • the machine level (e.g., the privilege level that the processor has while in machine mode) may have the highest privileges and may be the only mandatory privilege level on RISC-V hardware platforms.
  • Code running in machine mode (M-mode) can be inherently reliable because it has a low level of access to the machine implementation.
  • User mode (U-mode) and supervisor mode (S-mode) are intended for normal applications and operating systems, respectively, while hypervisor mode (H-mode) may be intended to support virtual machine monitors.
  • Each privilege level can have a set of core privileges ISA extensions with arbitrary extensions and mutability.
  • implementations of the RISC-V architecture must support at least M-mode and most implementations support at least U-mode and M-mode.
  • S-mode can be added to provide additional separation between the code of the supervisor-level operating system and other more privileged code running in M-mode.
  • User or application code typically encounters traps (e.g., supervisor calls, page faults) or interrupts that cause the user or application code to run in one of the supported higher privilege modes or levels (e.g., H, S, or M modes). It can run in U-mode until it is forced to transfer control to the running trap handler. The trap handler's code can then be executed, and then control can return to the original user code or application that triggered the trap. Execution of this user code or application can be resumed at or after the original trapped instruction in U-mode that triggered the trap handler call.
  • traps e.g., supervisor calls, page faults
  • interrupts e.g., H, S, or M modes
  • modes supported in a RISC-V implementation include, by way of example, a single M mode, two modes with M and U, three modes with M, S, and U, or M, H, S, It may include four modes with U and U.
  • the RISC-V architecture may have a Control Status Register (CSR) that can be read and modified by one or more associated privilege levels.
  • the CSR may be accessible at the first of the four permission levels and at any other permission level of the four permission levels higher than the first permission level. For example, if a trap such as a rule cache miss occurs when the program is running in U-mode (e.g. level 0), control is transferred to a higher authority, such as the rule cache miss handler code, or a mode (e.g. one of levels 1 through 3). can be transferred to a trap handler running at any level).
  • U-mode e.g. level 0
  • a higher authority such as the rule cache miss handler code, or a mode (e.g. one of levels 1 through 3).
  • a trap handler running at any level When a trap occurs, information can be placed in a CSR accessible to a trap handler running in M-mode.
  • a CSR that is accessible to a trap handler running in M-mode may be
  • the operating system kernel may be responsible for resource management, including isolation between processes and enforcement of access control policies. This responsibility can make it difficult for kernels to be written concisely, and can result in new security vulnerabilities being discovered every year. An attacker with knowledge of one of the security vulnerabilities could obtain means to arbitrarily read or modify page tables or the kernel's memory pages containing code.
  • Kernel code integrity can refer to the property that the operating system kernel should not be tricked into executing pieces of code that do not belong to the kernel. If the system fails to enforce this policy, the attacker can gain the power to manipulate the victim system in almost arbitrary ways. For example, an attacker could bypass any application-level security mechanisms or vendor-installed security policies associated with application distribution.
  • processors today can enable the operating system kernel to associate special page table attributes with pages containing kernel code.
  • special page table properties a processor can reject all attempts to modify kernel code or execute outside of kernel code while running in a kernel-privileged mode (e.g., supervisor mode).
  • a kernel-privileged mode e.g., supervisor mode
  • Making a kernel code page read-only prevents these undesirable modifications of the kernel code page, but preventing execution of kernel code pages from outside may require the policy to be applied to all page tables.
  • the latter page table property may be commonly called Privileged Execute None (PXN) or Supervisor Mode Execution Prevention (SMEP).
  • pages When configured while the processor is running in supervisor mode (e.g., kernel mode with kernel privilege level), pages may be considered non-executable. This may mean that, in order to achieve the desired goal, all page table entries created by the kernel, except for those for kernel code pages, must have a bit set. Nonetheless, modern operating system kernels may adopt this feature to ensure that only memory contents approved by the kernel are executed with kernel privileges.
  • supervisor mode e.g., kernel mode with kernel privilege level
  • kernel code integrity can only be guaranteed if the page tables are free from malicious modifications.
  • Existing mechanisms may rely on other trusted software components to defeat these attacks, which often corrupt page tables, which is undesirable in small embedded systems. For example, existing mechanisms can redirect page table updates to trusted software protected by ARM TruseZone. As another example, existing mechanisms may rely on the hypervisor for page table integrity.
  • a processor according to one embodiment may be disclosed as a small hardware extension that enables the kernel to protect kernel code integrity without relying on page table integrity.
  • the kernel can ensure that the processor executes only kernel-approved code with the authority of the kernel.
  • a processor according to one embodiment may be based on three observations about how kernel code pages are managed in embedded systems.
  • the set of physical or virtual pages containing kernel code may not change frequently. Most pages, including the core kernel, can be allocated at boot time and remain intact during runtime. Operating system kernels dynamically load additional code for additional functionality such as device drivers, but this can rarely happen, especially in embedded systems that often use a fixed set of peripheral devices.
  • the operating system may have some flexibility in managing memory pages in the physical address space.
  • Programs use virtual addresses to access code or data memory, and the kernel can relocate these pages back into the physical address space when necessary.
  • a memory management unit can implement all attribute checks necessary to protect kernel code pages.
  • the only additional requirements may include properly sanitized properties to comply with the desired access control policy to protect kernel code integrity.
  • the processor according to one embodiment may have additional inprocessor control registers (e.g., RISC-V Processor control and status registers (CSRs) can be introduced.
  • CSRs RISC-V Processor control and status registers
  • the processor according to one embodiment can ensure that the processor fetches instructions only from designated physical memory pages and refuses to write to those pages while the processor is running in privileged mode.
  • kernel code integrity may no longer depend on the integrity of the page tables.
  • the kernel can freely manage its page tables as needed.
  • the integrity of additional control registers is typically used to write-protect some critical read-only registers after system boot, assuming that the system should not load additional code, which is often the case in many embedded systems. It can be protected by a locking mechanism.
  • the threat model may follow a general threat model assumed by a defense mechanism against kernel-level attacks.
  • An attacker can be assumed to be aware of one or more kernel vulnerabilities that can trick the kernel into reading or modifying attacker-specified memory locations with kernel privileges.
  • This may include page tables that the kernel reads and modifies periodically.
  • the operating system kernel and underlying processor can implement state-of-the-art defense mechanisms to neutralize it.
  • page table entries contain attributes such as PXN/SMEP, and the kernel can make certain pages non-executable.
  • Kernels can also be carefully written so that only page table entries for legitimate kernel code pages are set with executable permissions.
  • an attacker can bypass this defense by staging a memory page containing a malicious code snippet that creates an executable permission mapping for the page by directly modifying the page table. The attacker can then cause the kernel to run from the page.
  • the processor may stop this by sanitizing the page table entries of each TLB refill using physical pages configured for kernel code.
  • the hardware may be changed twice and the operating system kernel may be changed once.
  • Figure 1 shows two possible hardware changes:
  • a processor according to one embodiment may add additional control registers (described below in Figure 2) to maintain the location and size of kernel code pages, and combinational logic to inspect page table entries to enforce policies in the page table walker. there is.
  • a page fault handler may be modified to further check whether a page fault is due to a violation of a policy enforced by the processor according to one embodiment.
  • a processor may include hardware components.
  • the processor may configure kernel code ranges at boot time.
  • the processor may set range registers included in the page table worker (PTW) based on the set kernel code ranges.
  • PW page table worker
  • the processor can receive access requests while in kernel mode.
  • the processor may include a kernel code region determiner (PRIVLOCKCHECKER).
  • the kernel code area determination unit (PRIVLOCKCHECKER) of the processor may receive a physical address mapped to the virtual address of the access request.
  • the processor's kernel code area determination unit (PRIVLOCKCHECKER) determines whether the area corresponding to the physical address (e.g., a partial area of memory corresponding to the physical address) is included in the kernel code area by comparing the range register with the received physical address. You can judge.
  • the processor may determine whether to enable or disable the operation of the area corresponding to the physical address.
  • the processor may update (e.g., sanitize) page table properties based on whether to enable or disable the determined operation.
  • the kernel code area determination unit (PRIVLOCKCHECKER) of the processor may transmit a page table entry (sanitized_pte) with updated page table properties to the translation index buffer (TLB).
  • TLB translation index buffer
  • FIG. 2 is a diagram illustrating a method for a processor to control operations in a kernel code area, according to an embodiment.
  • An electronic device for controlling operations in the kernel code region may include a processor.
  • processor operations for controlling operations in the kernel code area will be described.
  • the processor may configure a range register while in machine mode.
  • the processor may set the range register based on the physical address of the kernel code area where kernel code is stored. For example, the processor may be in machine mode when booting.
  • a processor can set scope registers for a core (e.g. Rocket Core) through the CSRFile interface while running the operating system kernel in machine mode.
  • a core e.g. Rocket Core
  • a control register having the number of bits of the physical address may be introduced.
  • the number of bits of the physical address may be 32.
  • the number of control registers can be set according to design.
  • the processor may include four control registers. The range register and its settings are described later in FIGS. 3 and 4.
  • the processor may obtain the physical address of the page in response to receiving an access request based on the virtual address of the page.
  • the processor may use a page table entry to obtain the physical address mapped to the virtual address of the access request.
  • the page table entry may include information about the virtual address of the access request and the physical address mapped to the virtual address. Acquisition of the physical address is described later in FIG. 5.
  • the processor may determine whether the area corresponding to the obtained physical address is included in the kernel code area by comparing the set range register with the obtained physical address.
  • the page table walker (PTW) of the processor may include a kernel code area determination unit (eg, the kernel code area determination unit (PRIVLOCKCHECKER) in FIG. 1).
  • the kernel code area determination unit of the processor may receive a physical address mapped to the virtual address of the access request.
  • the kernel code area determination unit of the processor may determine whether the area corresponding to the physical address is included in the kernel code area by comparing the range register with the received physical address.
  • a page table worker may include a plurality of range registers.
  • the kernel code area determination unit may determine whether the area corresponding to the physical address is included in the kernel code area by comparing the corresponding range register and the physical address for each of the plurality of range registers.
  • the kernel code area determination unit determines whether the area corresponding to the physical address is included in the kernel code area based on the area corresponding to the physical address being included in the range determined by at least one range register among the plurality of range registers. You can decide.
  • the kernel code area determination unit may determine that the area corresponding to the physical address is not included in the kernel code area, based on the fact that the area corresponding to the physical address is not included in the ranges determined by the plurality of range registers. . Determination of whether a physical address includes a kernel code area through comparison of the range register and the physical address will be described later with reference to FIG. 6.
  • step 240 the processor enables or disables operations on the area corresponding to the physical address, based on whether the area corresponding to the obtained physical address is included in the kernel code area. You can decide whether or not.
  • An operation for an area corresponding to a physical address may include at least one of a write operation or an execution operation.
  • a write operation to an area of memory is an operation to store data in an area of memory.
  • a kernel mode write operation stores data in the corresponding area while in kernel mode, and a user mode writes data to the corresponding area while in user mode. It may include a write operation.
  • the execution operation for an area of memory is an operation to execute a program based on data (e.g., program code) stored in the area of memory.
  • An execution operation in kernel mode is to execute a program based on data stored in the area while in kernel mode.
  • an execution operation in user mode that executes a program based on data stored in the corresponding area while in user mode. Determination of whether to enable or disable the operation will be described later in FIG. 7.
  • a page table entry may include a virtual address and a physical address mapped to the virtual address.
  • Page table entries can be stored with page table attributes.
  • the page table attribute enables operations (e.g., kernel mode write operation, user mode write operation, kernel mode write operation, user mode execution operation) on the memory area having the physical address of the corresponding page table entry.
  • it may include information regarding whether it is disabled.
  • the page table properties include a bit indicating whether write operations in kernel mode are enabled (e.g., sw bit), a bit indicating whether write operations in user mode are enabled (e.g., w bit), and kernel mode bits. It may have a bit indicating whether the mode execution operation is enabled (e.g., sx bit), and a bit indicating whether the user mode execution operation is enabled (e.g., x bit).
  • the update of page table properties is described later in FIG. 8.
  • Figure 3 is a diagram for explaining a range register setting operation according to one embodiment.
  • FIG. 4 is a diagram illustrating the structure of a range register with a plurality of bits according to an embodiment.
  • step 310 while in machine mode, the processor may align pages containing kernel code according to the boundaries of chunks having a predetermined size.
  • the processor may compare a part of the physical address expressed with a plurality of bits with the range register to determine whether the area corresponding to the physical address is included in the kernel code area.
  • the processor may compare the partial address corresponding to one or more upper bits of the physical address with the range register.
  • the processor may store the kernel code so that a partial address corresponding to the upper bits of the physical address is required to determine whether the memory area corresponding to the physical address is included in the kernel code area.
  • the processor can align the kernel code area where the kernel code is stored according to the boundaries of chunks with a predetermined size (e.g., a 16MB chunk, a 16KB chunk).
  • 16MB corresponds to 2 24 , so the boundary of a 16MB chunk can be determined by the 8 high-order bits of the physical address expressed in 32 bits. At the boundary of a 16MB chunk, each of the 24 low-order bits can have a value of 0.
  • the processor may store kernel code as at least one kernel code chunk.
  • a kernel code chunk may refer to an area of memory where at least a portion of kernel code is continuously stored.
  • a kernel code chunk may be referred to as a kernel code page corresponding to kernel code. Kernel code may be stored as multiple kernel code chunks.
  • the kernel code area determination unit e.g., the kernel code area determination unit (PRIVLOCKCHECKER) in FIG. 1
  • the kernel code page is one embodiment. May need to be protected and sorted by the processor according to . It may be found that chunks of kernel code can be aligned with small changes without affecting performance.
  • Operating system kernels can typically have anywhere from a few megabytes to tens of megabytes of code.
  • the Linux kernel running in our implementation can have approximately 3.04MB of code. Kernel code chunks can fit into 2MB boundaries. As a result, two 2MB kernel code chunks can result, and the processor can use two range registers for two 2MB kernel code chunks. Alignment of kernel code chunks can be performed by changing the linker script.
  • the processor may set, for each kernel code chunk, at least a portion of the range register corresponding to the kernel code chunk.
  • the processor may include a plurality of range registers corresponding to the plurality of kernel code chunks.
  • Each of the plurality of range registers may correspond to one kernel code chunk among the plurality of kernel code chunks.
  • the processor may set the base bit of the range register corresponding to the kernel code chunk based on the starting physical address of each kernel code chunk.
  • the base bit of the range register may have information about the starting physical address of the kernel code chunk to which the range register corresponds.
  • the base bit which is the 20 most significant bits among the plurality of bits of the range register, may be determined based on the start physical address of the kernel code chunk to which the range register corresponds.
  • the processor may determine that some of the base bits (e.g., 18 bits) have a range register equal to the starting physical address of the corresponding kernel code chunk.
  • the range register may have 32 bits.
  • the base bits may be the upper 20 bits of the range register.
  • the base bit has 20 bits, and the two upper bits may be bits related to information about the range register that are independent of the determination of whether the area corresponding to the physical address is included in the kernel code area.
  • the 18 bits other than the two upper bits among the base bits may have the same value as the starting physical address of the kernel code chunk to which the range register corresponds.
  • the processor may set the mask bit of the range register corresponding to the kernel code chunk based on the size of each kernel code chunk.
  • the mask bit of the range register may have information about the size of the kernel code chunk to which the range register corresponds.
  • the mask bits may be the 10 bits of the range register following the base bit.
  • the mask bit which has 10 bits, can be set based on the size of each kernel code chunk.
  • the processor may compare a part of the physical address and at least a part of the range register to determine whether the area corresponding to the physical address is included in the kernel code area.
  • the high-order bits of the physical address to be compared with at least a portion of the range register (e.g., base bits) may be determined based on the size of the kernel code chunk.
  • the processor can determine the eight high-order bits of the physical address to be compared to the range register.
  • the processor may determine the portion of the physical address to be compared with the range register as the upper bits of a predetermined number (e.g., 8) plus the number determined based on the mask bits.
  • the processor may set the mask bit to 0000000000 (2) if the size of the kernel code chunk is 16MB.
  • the processor calculates the number of physical addresses (e.g., 8) by adding the predetermined number (e.g., 8) and the number determined based on the mask bit (e.g., 0). ) can be compared to the range register.
  • the 20 low-order bits of the physical address included in the kernel code chunk may have different values. In other words, whether or not it is included in the corresponding kernel code chunk can be determined based on the top 12 bits of the physical address.
  • the processor can determine the 12 high-order bits of the physical address to be compared to the range register.
  • the processor may determine the portion of the physical address to be compared with the range register as the upper bits of a predetermined number (e.g., 8) plus the number determined based on the mask bits.
  • the processor may set the mask bit to 1111000000 (2) when the size of the kernel code chunk is 1MB.
  • the processor calculates the number of physical addresses (e.g., 12) by adding the predetermined number (e.g., 8) and the number determined based on the mask bit (e.g., 4). ) can be compared to the range register.
  • the 14 low-order bits of the physical address included in the kernel code chunk may have different values. In other words, whether or not it is included in the corresponding kernel code chunk can be determined based on the upper 18 bits of the physical address.
  • the processor can determine the 18 high-order bits of the physical address to compare with the range register.
  • the processor may determine the portion of the physical address to be compared with the range register as the upper bits of a predetermined number (e.g., 18) plus the number determined based on the mask bits.
  • the processor may set the mask bit to 1111111111 (2) when the size of the kernel code chunk is 16MB.
  • the processor selects the number of physical addresses (e.g., 18) by adding the predetermined number (e.g., 8) and the number determined based on the mask bit (e.g., 10). ) can be compared to the range register.
  • the processor may set the valid bit and lock bit of the range register in response to setting the base bit and mask bit of the range register.
  • the valid bit of the range register may have information regarding whether the range register corresponds to a kernel code chunk. If the number of range registers is greater than the number of kernel code chunks, at least one of the range registers may not correspond to a kernel code chunk. As an example, if there are 4 range registers and 3 kernel code chunks, each of 3 range registers among the range registers corresponds to one kernel code chunk, and the remaining 1 range register among the range registers corresponds to kernel code. It may not correspond to chunks.
  • the valid bit may be one bit following the mask bit.
  • the processor may set the value of the valid bit to 1 in response to setting the base bit and mask bit of the range register based on the kernel code chunk. After the kernel code chunk sets the corresponding range register, the processor can set the value of the valid bit to 0 for the unset range register.
  • the processor can use the range register to determine whether the area corresponding to the physical address is included in the kernel code area. If the valid bit of the range register is set to 0, the processor may determine that the range register does not correspond to a kernel code chunk. As a result, when the valid bit of the range register is set to 0, the processor may exclude use of the range register from determining whether the area corresponding to the physical address is included in the kernel code area.
  • the lock bit of the range register may have information regarding whether the range register has been set.
  • the lock bit may be a sticky bit that is set once and cannot be cleared.
  • the lock bit may be one bit following the valid bit.
  • the processor while in machine mode, can set the base bit, mask bit, and valid bit of the range register based on the kernel code chunk. After setting the base bit, mask bit, and valid bit of the range register based on the kernel code chunk, the processor may set the lock bit of the range register to 1. The processor may ignore additional write operations and/or update operations to the range register if the lock bit of the range register is set to 1. After the kernel code chunk sets the corresponding range register, the processor sets the value of the valid bit to 0 for the remaining range registers, and then sets the lock bit of the range register of the valid bit set to 0 to 1. You can set it.
  • the processor according to one embodiment cannot damage already set range registers, even if a powerful attacker can execute special instructions for updating the range register through the lock bit of the range register, so the range determined by the range registers cannot be changed. Accordingly, the processor according to one embodiment may ignore additional write operations and/or update operations for the range register after the value of the lock bit of the range register is set to 1.
  • FIG. 5 is a diagram illustrating an operation of a processor acquiring a physical address mapped to a virtual address of an access request, according to an embodiment.
  • the processor may, in response to receiving a request to access a virtual address while in kernel mode, obtain a physical address mapped to the virtual address using a page table entry for the virtual address.
  • the page table entry for the virtual address may or may not be cached in a translation lookaside buffer (TLB).
  • TLB translation lookaside buffer
  • the processor may check whether a page table entry for the virtual address of the access request is cached in the translation lookaside buffer.
  • recently used page table entries may be cached in the translation lookaside buffer.
  • the processor determines the page for the page table entry based on whether the area corresponding to the physical address is included in the kernel code area. Table properties can be updated.
  • the processor may cache page table entries along with updated page table attributes in the translation lookaside buffer. Therefore, according to one embodiment, the processor may treat the page table attribute of the page table entry already cached in the translation index buffer as updated based on the determination of the kernel code area determination unit. For example, the processor may treat the page table attributes of a page table entry cached in the translation lookaside buffer as if they had not been manipulated by an attacker.
  • the processor may retrieve a page table entry for the virtual address from the page table in response to the case where the page table entry is not cached in the translation lookaside buffer.
  • a page table entry may have a virtual address and a physical address mapped to the virtual address.
  • the processor may verify that the page table entry for the virtual address of the access request is not cached in the translation lookaside buffer.
  • the processor may retrieve a page table entry for the virtual address from the page table, based on the virtual address of the access request.
  • the processor may obtain the physical address of the page mapped to the virtual address based on the retrieved page table entry.
  • the processor may obtain the physical address of the page based on the page table entry cached in the translation lookaside buffer.
  • FIG. 6 is a diagram illustrating an operation of a processor determining whether an area corresponding to a physical address is included in the kernel code area, according to an embodiment.
  • the processor may determine a partial address of the physical address based on the mask bits of the range register.
  • a partial address may refer to a partial address among physical addresses to be compared with a range register.
  • a physical address can be expressed with 32 bits.
  • the processor selects the number of physical addresses (e.g., the sum of the predetermined number (e.g., 8) and the number determined by the mask bit (e.g., 4). : 12) upper bits can be determined as a partial address.
  • the processor may determine that the region corresponding to the obtained physical address is included in the kernel code region in response to the determined partial address matching at least a portion of the base bits of the range register.
  • the processor may determine that the code stored in the physical address is kernel code.
  • the value of the base bit of the range register may be shifted left by 14 bits and then used as the starting physical address of the kernel code chunk.
  • the value of the mask bit in the range register may be shifted left by 14 bits, and a predetermined number of bits preceding the value of the mask bit may be prepended by being set to 1 to construct the mask value.
  • the processor may determine whether the area corresponding to the physical address (addr) is included in the kernel code area according to Equation 1.
  • the processor may determine that the area corresponding to the physical address is included in the kernel code area to which the range register corresponds. If the physical address (addr) does not satisfy Equation 1, the processor may determine that the area corresponding to the physical address is not included in the kernel code area to which the range register corresponds.
  • FIG. 7 is a diagram illustrating an operation of a processor determining whether to enable or disable an operation for an area corresponding to a physical address, according to an embodiment.
  • the processor may disable a write operation on the area corresponding to the physical address in response to a case where the area corresponding to the obtained physical address is included in the kernel code area.
  • the processor may disable a kernel mode write operation for an area corresponding to a physical address.
  • the processor can limit write operations to the area corresponding to the physical address while in kernel mode by setting the sw bit of the page table attribute of the page table entry to 0.
  • the processor may disable a user mode write operation on an area corresponding to a physical address.
  • the processor can limit write operations to the area corresponding to the physical address while in user mode by setting the w bit of the page table attribute of the page table entry to 0.
  • an attacker when a write operation to the kernel code area is enabled, an attacker can store malicious code in the kernel code area. If malicious code is stored in the kernel code area, the malicious code stored in the kernel code area may be executed while the processor is in kernel mode. In contrast, according to one embodiment, when the area corresponding to the physical address is included in the kernel code area, the processor disables a write operation for the area corresponding to the physical address, thereby allowing an attacker to write kernel code to the kernel code area. It can prevent other codes (e.g. malicious code) from being stored.
  • the processor in response to a case where the region corresponding to the obtained physical address is included in the kernel code region, enables an execute operation for the region corresponding to the physical address while in kernel mode. You can.
  • the processor may enable a kernel mode execution operation for an area corresponding to a physical address.
  • the processor may allow execution operations on the area corresponding to the physical address while in kernel mode by setting the sx bit of the page table attribute of the page table entry to 1.
  • the processor may disable execution operations for the region corresponding to the physical address while in kernel mode in response to a case where the region corresponding to the obtained physical address is included in a region different from the kernel code region. there is.
  • the processor may disable kernel mode execution operations for the area corresponding to the physical address.
  • the processor can limit execution operations to the area corresponding to the physical address while in kernel mode by setting the x bit of the page table attribute of the page table entry to 0.
  • an attacker may store kernel code and other code (e.g., malicious code) in some area of memory.
  • An attacker can enable kernel mode execution for some areas where other code is stored.
  • an attacker can store other code in some areas of memory and manipulate the processor to recognize some areas of memory as kernel code areas.
  • the processor according to the comparative example may execute malicious code stored in some areas while in kernel mode.
  • the processor when the area corresponding to the physical address is not included in the kernel code area, the processor disables the execution operation of the kernel mode for the area corresponding to the physical address, thereby allowing other processors to run while in kernel mode. It can prevent code (e.g. malicious code) from running.
  • the processor may determine whether to enable or disable at least one operation independently of the page table attribute of the page table entry.
  • a page table entry for a virtual address may have a page table attribute.
  • the page table attribute includes at least one of a kernel mode write operation, a user mode write operation, a kernel mode execution operation, and a user mode execution operation for the area corresponding to the physical address of the page table entry. It may include information regarding whether the operation is enabled or disabled.
  • the processor prevents the processor from being deceived into disabling an operation that should be enabled in an area corresponding to a physical address or enabling an operation that should be disabled due to manipulation of page table properties by an attacker. can do.
  • an attacker can manipulate a kernel code area where kernel code is stored to be enabled even though write operations should be disabled.
  • An attacker can manipulate at least one bit of the w bit or the sw bit to 1 in the page table attribute of the page table entry for the kernel code region.
  • an attacker could manipulate a region of kernel code and other regions into enabling execution even though they should be disabled.
  • an attacker can manipulate the sx bit to 1 in the page table attribute of a page table entry for a region other than the kernel code region.
  • the processor may determine whether to enable or disable a write operation and/or an execution operation for an area corresponding to a physical address based on page table properties.
  • the processor according to the comparative embodiment may determine whether to enable or disable the write operation and/or the execution operation based on the manipulated page table properties.
  • the processor according to one embodiment determines whether the area corresponding to the physical address is included in the kernel code area, and performs a write operation and/or an execution operation for the area corresponding to the physical address based on the determination result. You can decide whether to enable or disable it.
  • the processor according to one embodiment can determine whether to enable or disable correct operation according to the result of determining whether or not the page table is included in the kernel code area.
  • FIG. 8 is a diagram illustrating an operation of a processor updating page table properties when a page table entry for a virtual address of an access request is not cached in a translation index buffer, according to an embodiment.
  • the processor determines whether to enable or disable operations (e.g., write operations, execution operations) for the area corresponding to the physical address, independently of the page table attribute of the page table entry. You can decide.
  • the processor may set page table properties depending on whether to enable or disable the determined operation.
  • the processor may update the page table attribute of the page table entry based on whether the determined at least one operation is enabled or disabled.
  • updating the page table attribute of a page table entry may also be expressed as sanitizing the page table attribute (or page table entry).
  • the processor may determine that the area corresponding to the physical address is included in the kernel code area.
  • the processor may disable kernel mode write operations and user mode write operations for the area corresponding to the physical address.
  • the processor may enable a kernel mode execution operation for the area corresponding to the physical address.
  • the processor may update the sw bit and w bit of the page table attribute to 0.
  • the processor may update the sx bit of the page table attribute to 1.
  • the processor may determine that the region corresponding to the physical address is not included in the kernel code region.
  • the processor may disable kernel mode execution operations for the area corresponding to the physical address.
  • the processor may update the sw bit and w bit of the page table attribute to 1.
  • the processor may update the sx bit of the page table attribute to 0.
  • the processor updates the page table properties based on whether the operation is enabled or disabled, which is determined independently of the page table properties. , page table properties can be maintained as true values.
  • the processor may cache the updated page table attributes along with the page table entries in the translation lookaside buffer.
  • the processor may use a policy of caching recently retrieved page table entries in a translation index buffer.
  • the page table attribute of the page table entry cached in the conversion index buffer may be the page table attribute updated by the processor (eg, kernel code area determination unit).
  • FIG. 9 is a diagram illustrating an operation of a processor updating page table properties when a page table entry for a virtual address of an access request is cached in a translation index buffer, according to an embodiment.
  • the processor may cache page table properties updated by the processor (eg, kernel code area determination unit) in the translation index buffer.
  • the processor eg, kernel code area determination unit
  • Page table properties can be treated as if they had not been manipulated by an attacker.
  • the processor may, in response to cases where the page table entry is cached in the translation lookaside buffer, skip comparing the established range register to the obtained physical address.
  • the processor may determine whether to enable or disable at least one operation based on page table attributes of the page table entry.
  • the processor may treat the page table attribute as not being manipulated by the attacker.
  • the processor can determine whether to enable or disable the operation included in the reliable page table attribute even without determining whether the area corresponding to the physical address is included in the kernel code area.
  • the processor according to one embodiment may check whether an operation is enabled or disabled in response to a request for access to memory after or together with address translation.
  • a processor according to one embodiment enables or disables operations based on the exact physical address that the processor uses to access memory, similar to a virtual address-based mechanism that uses page tables to translate addresses. You can decide whether or not. Otherwise, an attacker can manipulate specific page table entries to bypass checks and execute or corrupt kernel code pages.
  • the processor according to one embodiment may check a request to access memory before accessing the cache.
  • the processor according to one embodiment aims to protect kernel code integrity, and for the integrity of the kernel code, not only does it limit write operations to the kernel code area that stores the kernel code, but also restricts write operations to the kernel code area and the kernel code area while in kernel mode. Execution behavior for other code (e.g. external code) stored in other areas may also need to be restricted. Processors typically do not flush their cache when entering kernel mode, so the cache may contain some code for the user program. If an additional security mechanism checks memory accesses outside the cache, an attacker can bypass the mechanism by causing the kernel to jump to a cached user program. To prevent such code from executing with kernel privileges while the processor is in kernel mode, page table attributes between the processor core and the cache can be inspected.
  • a processor according to one embodiment may exclude new hardware logic between address translation and L1 cache access. Adding logic to check physical addresses inevitably increases gate and wire delays and potentially introduces another pipeline stage. As a result, significant performance degradation may occur. For example, Rocket Chip Generator's PMP implementation may try to avoid adding logic where physical addresses are checked. As described above, the processor according to one embodiment may not add logic by extending the page table worker instead of the MMU or L1 cache.
  • the processor may be checked using the TLB entry updated by the MMU along with address translation for memory accesses.
  • the MMU lies between the processor core and the cache for address translation, so that any access request that violates the processor's policy according to one embodiment may result in a protection fault, even if it results in a memory access TLB hit in the cache.
  • a transformation-free MMU can be utilized by simply adding additional hardware to the page table workers, without adding new hardware between the MMU and L1 cache.
  • a processor may update (e.g., sanitize) a page table entry (or a page table attribute of a page table entry) upon a TLB miss by taking advantage of existing hardware logic to inspect the page table attributes of the page table entry. ), you can implement the desired policy.
  • the processor may require that the operating system kernel be changed. For example, changes to the page fault handler may be required.
  • page faults can occur regularly during the process of demand paging. An application's requests for additional virtual pages are served with the virtual page first, and physical pages can be provisioned when the page is touched.
  • page faults recognized by the TLB and handled by the operating system kernel may be included. After a page fault, the application can resume execution from the instruction that caused the page fault.
  • the page fault handling procedure may need to be updated because writes to kernel code pages cause the same page fault.
  • the processor may update page table properties and cause access to be denied upon a TLB miss. While the kernel handles this error, it checks whether the page is writable, then considers the error handled and can resume execution at the instruction that caused the error. However, even though the page is marked as writable in the page table entry, the same protection error may occur again because the processor according to one embodiment deletes the page table entry again.
  • the page fault handler can be adjusted so that the kernel verifies that the virtual address causing the page fault points to a physical address within the kernel code page.
  • the kernel may determine that a page fault has occurred due to kernel code page protection of the processor according to one embodiment if the page table entry corresponding to the virtual address is valid, the access does not violate the page attribute, and the entry point is kernel code. You can point to a page.
  • the kernel can terminate the process that caused the error or quietly ignore the write.
  • the processor according to one embodiment may be implemented by, for example, expanding the Rocket Chip Generator of the Freedom U500 Dev Kit, and the processor according to one embodiment may improve performance, energy consumption, chip area, and critical path latency. ) can be measured using the Xilinx VCU118 evaluation kit. Experiments using application (e.g. Beebs and SPEC CPU 2006) and operating system kernel benchmarks have shown that processors according to one embodiment may have a low impact on application ( ⁇ 0.5%) and operating system ( ⁇ 3%) performance. there is. The cost is low in terms of chip area (0.13%) and energy consumption ( ⁇ 2%) and may not increase critical path delay.
  • application e.g. Beebs and SPEC CPU 2006
  • operating system kernel benchmarks have shown that processors according to one embodiment may have a low impact on application ( ⁇ 0.5%) and operating system ( ⁇ 3%) performance. there is.
  • the cost is low in terms of chip area (0.13%) and energy consumption ( ⁇ 2%) and may not increase critical path delay.
  • a processor By expanding the Rocket Chip Generator, a processor (PRIVLOCK) according to one embodiment can be implemented and the system can be evaluated on an FPGA through the Freedom U500 V707 FPGA development kit. Ports from the development kit can be used specifically for the Xilinx VCU118 evaluation kit.
  • the commit ID may be 943ab4ac2cefbbabdeda9447ec0f6231f6235f1e.
  • the default for the U500 platform can be used, which has four RockerTiles, each RockerTiles containing one Rocket core, 16KB of L1 data cache, and 16KB of L1 instruction cache. .
  • the GNU toolchain for RISC-V processors could be used to compile kernel programs and user programs, and the commit ID could be b4dae89f85bf882852c6186b1284df11065bfcd9.
  • the prototype runs with 2GB of external memory, operates at 100MHz, and can run Linux kernel version 4.15.0.
  • the prototype can be configured to operate at 100 MHz following Rocket Chip's default configuration, unmodified, on the U500 platform.
  • FIG. 10 is a diagram illustrating the results of measuring the performance of a processor according to an embodiment and a processor according to a comparative example using LMBench.
  • the performance overhead of the processor may not be noticeable. Protection faults slow things down by about 30%, but as can be seen in application benchmarks, they are intermittent and may not significantly affect system performance. For all benchmarks, the overhead of the four previous operations may not have been visible because the results were not reported.
  • the processor (PRIVLOCK) may measure the page fault handler of the operating system kernel. Therefore, it is possible that additional checking may affect the performance of memory management operations and related operating system services.
  • the potential impact of a processor (PRIVLOCK) according to one embodiment on operating system performance can be measured through the widely used LMBench.
  • Figure 3 shows the results along with the processor overhead for comparative embodiments that provide similar security guarantees.
  • the processor (PRIVLOCK) according to one embodiment may also not degrade operating system performance. For reference, as will be explained later, the 30% overhead of a protection fault may not be noticeable in most applications. This may be because programs are generally optimized to reduce the number of protection errors.
  • the overhead of the processor (PRIVLOCK) is significantly lower than software-only mechanisms (SecVisor and Nested Kernel) and may be similar to hardware-assisted mechanisms (Kargos and RiskiM).
  • SecVisor and Nested Kernel two software-only mechanisms that ensure kernel code integrity evaluated by LMBench, can have up to 10x and 3x overhead, respectively. This may be much larger than the overhead of the processor (PRIVLOCK) according to one embodiment.
  • Kargos and RiskiM are hardware-assisted mechanisms that can detect kernel code integrity violations. Both may have similar or better performance overhead compared to the processor (PRIVLOCK) according to one embodiment (about 3% and 30%, respectively).
  • the context switch overhead of the processor (PRIVLOCK) can be compared to emulated software-only protection.
  • Deterministic, software-only protection of page table integrity requires sanitization of newly used page tables at each context switch and can increase context switch latency.
  • the kernel can be instrumented and a software-only mechanism emulated to read 16 pages (64KB) on every context switch containing 16 page tables.
  • Table 1 shows the results of context switch latency measured with LMBench.
  • the number of pages that need to be checked at each context switch is always greater than 16, it may be chosen to check 16 pages in the experiment. Therefore, the minimum expected overhead can be reflected in the numbers presented.
  • it may be necessary to check all valid page table entries in the new page table and if the page table maps more than 64 MB of memory including data pages, the page table must contain at least 16 pages containing valid page table entries. You may have to have it.
  • the additional check performed by the kernel can significantly reduce the speed of context switches compared to the processor (PRIVLOCK) according to one embodiment.
  • FIG. 11 illustrates the execution time of a workload of a system having a processor according to an embodiment normalized to the execution time of a system having a processor according to a comparative embodiment according to an embodiment.
  • the processor for applications that do not cause a large number of page faults, it can be expected that the processor (PRIVLOCK) according to one embodiment will not cause performance degradation.
  • additional hardware may increase the waiting time of some paths in the page table worker to be introduced, and may not increase the waiting time of the task in terms of cycle.
  • Beebs Bristol/Embecosm Embedded Benchmark Suite [39] can be used, a benchmark suite designed to evaluate embedded systems derived from MiBench, the WCET benchmark and DSPStone. The remaining two workloads were found to have memory safety bugs and cannot be run, so 78 of the 80 workloads in the suite can run.
  • 11 may show the execution time of each workload normalized to the execution time of a system without a processor (PRIVLOCK) according to an embodiment when the processor (PRIVLOCK) according to an embodiment is activated.
  • Each workload can be run 10 times, averaged, and normalized execution time calculated. As expected, the performance overhead can be unnoticeable, staying in the 0.5% range and, in geometric mean, less than 0.3%.
  • Figure 12 shows normalized execution times of 12 workloads of the SPEC 2006 benchmark suite according to one embodiment.
  • SPEC 2006 benchmark suite may be used. Due to the prototype's limited computing power and file system size, it may not be able to run the latest version of SPEC 2017. For the same reason, a smaller traininput can be used rather than a larger ref input. As shown in Figure 12, a system with a processor (PRIVLOCK) according to one embodiment can execute non-trivial programs with almost zero performance overhead (e.g., -0.07%).
  • Table 2 describes the impact on the chip area of the processor according to one embodiment.
  • the processor (PRIVLOCK) takes advantage of additional hardware resources, it provides additional security guarantees without significant performance degradation. Without this additional component, the processor (PRIVLOCK) according to one embodiment may have executed more CPU instructions and had a higher performance overhead to check the page table contents.
  • the cost of additional resources can be assessed in several ways. Chip area can be measured according to ASIC (Application Specific Integrated Circuit) flow and FPGA utilization. The potential cost of energy consumption can be measured by both the prototype running on the FPGA and the Vivado Design Suite's ability to estimate the expected power consumption of the implemented design.
  • ASIC Application Specific Integrated Circuit
  • the Yosys open synthesis suite (Yosys) can be used to calculate an estimate of the chip area.
  • the freely available libraries included in FreePDK45 [48] can be used.
  • Table 2 can show the area estimates of the upper modules and the overall system based on the estimates of the different hardware components of interest.
  • the processor (PRIVLOCK) according to one embodiment has four range registers, the area cost may be only 0.13%.
  • a processor according to one embodiment (PRIVLOCK) with four range registers can be used for performance and security evaluation.
  • Table 2 shows that most of the area cost occurs in the additional registers of CSRFile under the Rocket core and the kernel code area determination unit (PRIVLOCKCHECKER) of the Page Table Walker (PTW).
  • a system implementing a processor (PRIVLOCK) according to one embodiment may have few peripheral devices.
  • Four RocketTiles can take up most of the chip area. In fact, it can be expected that there will be many more peripherals in the system, making the relative area cost of the processor (PRIVLOCK) according to one embodiment much smaller.
  • Table 3 describes the critical path latency of the processor according to one embodiment.
  • the critical path delays of some related modules can be collected and compared to see if the processor (PRIVLOCK) according to one embodiment significantly increases the critical path delay and relaxes delay constraints.
  • Table 3 shows the critical path delays of related modules.
  • the processor (PRIVLOCK) according to one embodiment may not violate the delay constraint of 2500 ps met by the baseline system.
  • the critical path of the related module may not increase significantly either.
  • Table 4 describes FPGA Resource Utilization of the processor according to one embodiment.
  • the impact of the processor (PRIVLOCK) according to one embodiment on FPGA utilization in addition to the estimated chip area may be presented.
  • Table 4 shows that in terms of resource utilization, when implemented in an FPGA, the area cost of the processor (PRIVLOCK) according to one embodiment is small ( ⁇ 3%).
  • FIG. 13 is a diagram illustrating normalized additional energy consumption of a processor according to an embodiment.
  • Table 5 describes the composition of each set used to evaluate the additional energy consumption of the processor according to one embodiment.
  • Table 6 describes the estimated power consumption when the processor is implemented in an FPGA according to one embodiment.
  • Additional hardware components may consume additional energy while the system is running.
  • the expected cost of energy consumption can be estimated in two ways. Energy consumption may be measured while executing a subset of the Beebs benchmark suite on an FPGA implemented system using a processor (PRIVLOCK) according to one embodiment.
  • PRIVLOCK processor
  • the energy consumption of a set of workloads can be measured.
  • Table 5 can describe the workloads included in each set.
  • the results e.g., 1.87% in geometric mean
  • the newly added hardware components for the processor (PRIVLOCK) may suggest that the newly added hardware components for the processor (PRIVLOCK) according to one embodiment do not cause significant energy overhead.
  • the built-in power estimation function of Xilinx Vivado [57] can be used to obtain the expected power consumption.
  • Table 6 can show that, similar to the conclusion of the energy measurements, the additional power consumption is expected to be small ( ⁇ 1%).
  • Three synthetic attacks showing possible attacks to tamper with kernel code integrity can be implemented, and a processor (PRIVLOCK) according to one embodiment can successfully prevent all synthetic attacks.
  • the first attack can create write access to one of the kernel code pages, to ensure that the write is recognized as illegal. Although this attack can be prevented without difficulty by existing mechanisms using traditional page table-based protection, the attack can succeed on the tested system because kernel code pages are configured to be writable by default. Regardless of this lack of page table properties, the attack may stop and a protection fault may occur in the kernel when the processor (PRIVLOCK) according to one embodiment is enabled.
  • the second can be written for a scenario where an attacker stores malicious code in a kernel data page and attempts to execute it.
  • An attacker may need to not only prepare a page containing code, but also manipulate the corresponding page table entries to make the page executable while the process is running in privileged mode.
  • This procedure can be implemented successfully, and unprotected systems may not detect the attack.
  • the kernel may not be able to prevent procedures involving direct manipulation of page tables, as suggested in previous work.
  • the processor (PRIVLOCK) according to one embodiment is not designed to detect such behavior, but prevents attacks when the processor jumps to malicious code located outside the physical kernel code page. may not be able to detect or prevent this attack during the page table manipulation stage.
  • the third attack aims to modify kernel code pages, but may be more advanced than the first in that it uses newly created virtual pages for the kernel code pages. Unlike the first attack, the operating system kernel may not be able to detect this attack unless it is hardened with some mechanisms [5, 13] to prevent or mitigate malicious page table modification.
  • the implemented attack successfully compromises the kernel code page when the processor (PRIVLOCK) according to one embodiment is not enabled, but does not compromise the kernel code page when the processor (PRIVLOCK) according to one embodiment is overwritten. Attacks can be prevented. Even if there are additional virtual pages, writes can be directed to the physical kernel code page.
  • the attack creates a new mapping as a writable page, but the processor (PRIVLOCK) according to one embodiment may clear this attribute when an entry is loaded into the TLB and the processor recognizes this page as write-protected.
  • the embodiments described above may be implemented with hardware components, software components, and/or a combination of hardware components and software components.
  • the devices, methods, and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, and a field programmable gate (FPGA).
  • ALU arithmetic logic unit
  • FPGA field programmable gate
  • It may be implemented using a general-purpose computer or a special-purpose computer, such as an array, programmable logic unit (PLU), microprocessor, or any other device capable of executing and responding to instructions.
  • the processing device may execute an operating system (OS) and software applications running on the operating system. Additionally, a processing device may access, store, manipulate, process, and generate data in response to the execution of software.
  • OS operating system
  • a processing device may access, store, manipulate, process, and generate data in response to the execution of software.
  • a single processing device may be described as being used; however, those skilled in the art will understand that a processing device includes multiple processing elements and/or multiple types of processing elements. It can be seen that it may include.
  • a processing device may include multiple processors or one processor and one controller. Additionally, other processing configurations, such as parallel processors, are possible.
  • Software may include a computer program, code, instructions, or a combination of one or more of these, which may configure a processing unit to operate as desired, or may be processed independently or collectively. You can command the device.
  • Software and/or data may be used on any type of machine, component, physical device, virtual equipment, computer storage medium or device to be interpreted by or to provide instructions or data to a processing device. , or may be permanently or temporarily embodied in a transmitted signal wave.
  • Software may be distributed over networked computer systems and stored or executed in a distributed manner.
  • Software and data may be stored on a computer-readable recording medium.
  • the method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium.
  • a computer-readable medium may include program instructions, data files, data structures, etc., singly or in combination, and the program instructions recorded on the medium may be specially designed and constructed for the embodiment or may be known and available to those skilled in the art of computer software. It may be possible.
  • Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks.
  • Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc.
  • the hardware devices described above may be configured to operate as one or multiple software modules to perform the operations of the embodiments, and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

일 실시예에 따른 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치는, 프로세서가 머신 모드(machine mode)인 동안, 커널 코드(kernel code)가 저장된 커널 코드 영역의 물리 주소(physical address)에 기초하여 범위 레지스터(range register)를 설정(configure)하고, 상기 프로세서가 커널 모드(kernel mode)인 동안 페이지(page)의 가상 주소에 기초한 액세스 요청을 수신하는 경우에 응답하여, 상기 페이지의 상기 가상 주소에 대한 페이지 테이블 엔트리(page table entry)를 이용하여 상기 페이지의 물리 주소를 획득하며, 상기 설정된 범위 레지스터를 상기 획득된 물리 주소와 비교함으로써, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하고, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부에 기초하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블(enable) 또는 디스에이블(disable) 여부를 결정하는 프로세서를 포함할 수 있다.

Description

커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치 및 방법
이하, 커널 코드가 저장된 메모리 영역에 대한 동작을 제어하는 기술이 개시된다.
운영 체제 커널은 다양한 레벨들에서 시스템을 관리하는 권한 있는 소프트웨어 구성 요소를 포함할 수 있다. 사용자 프로세스들과 긴밀하게 상호 작용하고 대부분의 리소스들을 관리하는 운영 체제 커널에 대한 공격은, 공격자에게 전체 시스템을 강력한 제어를 수여할 수 있다. 커널이 실행하는 코드는 커널의 중심에 존재할 수 있다. 코드는 커널이 동작하는 방법을 정의하므로, 런타임에 온전하게 유지되어야 할 수 있다. 커널 코드 무결성은 커널이 실행하는 코드가 런타임에 온전하게 유지되어야 하는 특성을 나타낼 수 있다. 커널 코드 무결성은 공격자에 의하여 두 가지 방법으로 위반될 수 있다.
예를 들어, 커널 코드 무결성은 공격자에 의한 커널 코드의 수정을 통해 위반될 수 있다. 프로세서는 커널의 권한으로 수정된 코드를 실행하도록 만들 수 있다. 예를 들어, 일부 시스템 호출 핸들러들이 덮어씌워짐으로써, 공격자는 커널이 대상 시스템 호출을 핸들링하는 방식을 변경할 수 있다.
예를 들어, 커널 코드 무결성은 커널 코드가 포함되지 않은 새로운 위치(예: 데이터 페이지)로부터의 실행을 통해 위반될 수 있다. 커널은 일반적으로 이 새로운 위치로 점프하지 않을 수 있지만, 공격자는 커널이 간접적인 점프 대상들을 결정하기 위하여 이용하는 리턴 주소들 또는 함수 포인터들과 같은, 코드에 대한 하나 이상의 포인터들을 조작할 수 있다.
공격자는 커널 코드 무결성을 위반할 인센티브가 존재할 수 있다. 인센티브는 피해자 시스템을 조작할 수 있는 높은 레벨의 자유를 제공하는 것을 포함할 수 있다. 예를 들어, iOS 기기에 대한 제일브레이크 툴(jailbreak tool), 일반적으로 기기가 전술한 페이지 테이블 기반 보호로 보호되지 않을 때, Apple 앱 스토어의 외부로부터 어플리케이션을 설치하도록 커널을 패치할 수 있다. 일부 사용자 레벨 프로그램들이 기기가 Android 플랫폼에 기반하는지 여부를 결정하는 것을 시도하는 경우에도, 이러한 공격자는 커널에 코드를 삽입함으로써 확인을 쉽게 무효화(nullify)할 수 있다.
컴퓨터 시스템의 보안의 초석으로 간주되고 있음에도 불구하고, 기존 및 배포된 많은 보호 메커니즘들은 공격에 취약할 수 있다. 예를 들어, Microsoft Windows는 KPP(Kernel Patch Protection)라는 기능을 가질 수 있고, 이전 iOS는 또한 유사한 기능을 가질 수 있다. 기존 및 배포된 많은 보호 메커니즘들은, 커널 코드 페이지의 스냅샷을 주기적으로 검사함으로써 알 수 없는 취약점을 악용한 공격자에 의하여 커널 코드 내용이 수정되지 않는 것을 보장할 수 있다. 불행히도, 이러한 방어를 알고 있는 공격자는 확인들 사이에서만 커널을 수정함으로써 방어를 우회할 수 있다.
이러한 조작을 물리칠 수 있는 보다 더 강력한 메커니즘은 페이지 테이블 속성들을 사용하는 것이지만, 보다 더 권한이 있는 소프트웨어 레이어(예: 하이퍼바이저)에 의존함으로써 또는 페이지 테이블 관리의 유연성을 희생하여, 페이지 테이블의 무결성이 보장되는 것을 요구할 수 있다. 예를 들어, Hypervision 및 SPROBES는 TrustZone에 의해 보호되는 Secure Monitor 및 Secure OS에 의존할 수 있고, HVCI는 하이퍼바이저에 의존할 수 있다. KTRR에 대한 세부사항들은 공개되지 않았지만, 메커니즘은 커널 페이지 테이블에 대한 업데이트를 제한함으로써 커널의 가상 주소 공간을 관리하는 유연성을 제한할 수 있다.
RISC-V ISA 사양은 물리적 주소 기반 액세스 제어의 형태를 구현하기 위한 표준들을 이미 포함하고, 작업 그룹은 향상된 버전을 준비하는 중일 수 있다. 이 확장은 물리적 메모리 보호(physical memory protection; PMP)라고 불리고, 주로 수퍼바이저 모드(예: 커널 모드) 프로그램 및 사용자 모드 프로그램이 머신 모드 프로그램의 주소에 액세스하는 것을 금지하도록 설계될 수 있다. 이 표준은 최대 16개의 다른 물리적 주소 범위들 및 대응하는 액세스 제어 정책을 정의할 수 있는 4개의 구성 레지스터들을 정의할 수 있다. 16개의 범위들의 우선 순위는, 16개의 정책들 중 최대 하나가 하나의 물리적 주소에 적용되도록, 엄격하게 지정될 수 있다.
물리적 메모리 보호(PMP)는 머신 레이어 소프트웨어를 보호하는 데 유용한 것으로 입증되었지만, 커널 코드 무결성을 보호하는 데 사용될 수 없을 수 있다. 물리적 메모리 보호(PMP)는 읽기 가능한(readable; R), 쓰기 가능한(writable; W) 및 실행 가능한(executable; X) 허가들(permissions)을 나타내는 3비트를 각 주소 범위에 연관시킬 수 있고, 이는 실행 전용 물리적 메모리 영역들을 생성하는 것을 가능하게 할 수 있다. 운영 체제 커널은, 머신 모드 소프트웨어가 이러한 속성들을 사용하여 코드 페이지들을 보호하기 위해 코드 페이지를 실행 전용으로 만드는 것을 요청할 수 있습니다. 그러나, 커널은 커널 코드 페이지들의 외부로부터 실행하도록 커널 스스로를 속이는 것을 방지할 수 없다. 물리적 메모리 보호(PMP)는 프로세서가 현재 실행 중인 모드를 고려하지 않고 특정 물리적 주소에 대하여 정의한 16개의 정책들 중 하나만 적용하기 때문일 수 있다. 결과적으로, 수퍼바이저 모드에서 실행되는 운영 체제 커널이 사용자 프로그램의 코드 페이지로부터 코드를 실행하는 것을 금지하는 것은 가능하지 않을 수 있다. 물리적 메모리 보호(PMP)는 수퍼바이저 모드 및 사용자 모드 코드 모두가 물리적 주소 범위로부터 실행되는 것을 허용해야 하기 때문일 수 있다. 물리적 메모리 보호(PMP)의 주요 목표는 나머지로부터 머신 모드 레이어를 보호하는 것이기 때문에, 이는 물리적 메모리 보호(PMP)의 결함이 아닐 수 있다.
현재 버전의 물리적 메모리 보호(PMP)는 머신 모드에서도 코드 무결성을 보호하는 것이 가능하지 않을 수 있다. 현재 물리적 메모리 보호(PMP)의 사양에 따르면, 하나의 허가만이 주소 일치 사양으로 인하여, 각 주소와 연관될 수 있다. 이러한 이유로 수퍼바이저 및 사용자 프로그램들의 주소 범위들은, 해당 페이지들에 대한 액세스 제어를 수퍼바이저 레벨 프로그램에 위임(delegate)하기 위하여 실행 가능한 것으로 마킹되어야 할 수 있다. 이를 통해, 해당 페이지는 머신 모드에서도 실행될 수 있다. 결과적으로, 머신 모드의 취약점은, 프로세서가 머신 모드에서 실행되는 동안 공격자가 사용자의 메모리에 위치한 페이로드를 실행할 수 있다는 것을 포함할 수 있다. 이러한 한계를 극복하기 위해, 향상된 사양의 초안은, 머신 모드에서 외부 코드의 실행을 위협으로 간주하고 일 실시예에 따른 프로세서와 유사한 사양을 포함할 수 있다. 새로운 사양은, 머신 모드에서 구성된 주소 범위에 속하지 않는 주소를 실행할 수 없도록 만들 수 있다. 따라서, 프로세서가 주소 범위 레지스터들을 사용하여 실행 가능한 코드 페이지의 허용 목록(allowlist)을 정의하는 반면 레지스터는 현재 물리적 메모리 보호(PMP)의 거부 목록들(denylists)만 될 수 있다.
일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 프로세서가 머신 모드(machine mode)인 동안, 커널 코드(kernel code)가 저장된 커널 코드 영역의 물리 주소(physical address)에 기초하여 범위 레지스터(range register)를 설정(configure)하는 단계를 포함할 수 있다. 일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 상기 프로세서가 커널 모드(kernel mode)인 동안 페이지(page)의 가상 주소에 기초한 액세스 요청을 수신하는 경우에 응답하여, 상기 페이지의 상기 가상 주소에 대한 페이지 테이블 엔트리(page table entry)를 이용하여 상기 페이지의 물리 주소를 획득하는 단계를 포함할 수 있다. 일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 상기 설정된 범위 레지스터를 상기 획득된 물리 주소와 비교함으로써, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하는 단계를 포함할 수 있다. 일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부에 기초하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블(enable) 또는 디스에이블(disable) 여부를 결정하는 단계를 포함할 수 있다.
상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작(write operation)을 디스에이블하는 단계를 포함할 수 있다.
상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(execute operation)을 인에이블하는 단계를 포함할 수 있다.
상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역과 다른 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(excute operation)을 디스에이블(disable)하는 단계를 포함할 수 있다.
상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는, 상기 페이지 테이블 엔트리의 페이지 테이블 속성(page table attribute)과 독립적으로, 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계를 포함할 수 있다.
상기 범위 레지스터를 설정하는 단계는, 상기 프로세서가 머신 모드인 동안, 커널 코드를 가지는 페이지를 미리 결정된 크기를 가지는 청크(chunk)의 경계(boundary)에 따라 정렬(align)하는 단계를 포함할 수 있다.
상기 범위 레지스터를 설정하는 단계는, 상기 커널 코드를 적어도 하나의 커널 코드 청크(kernel code chunk)로 저장하는 단계를 포함할 수 있다. 상기 범위 레지스터를 설정하는 단계는, 각 커널 코드 청크(kernel code chunk)에 대하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 적어도 일부를 설정하는 단계를 포함할 수 있다.
상기 범위 레지스터를 설정하는 단계는, 각 커널 코드 청크의 시작 물리 주소에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 베이스 비트(base bit)를 설정하는 단계를 포함할 수 있다. 상기 범위 레지스터를 설정하는 단계는, 해당 커널 코드 청크의 크기에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 마스크 비트(mask bit)를 설정하는 단계를 포함할 수 있다.
상기 범위 레지스터를 설정하는 단계는, 상기 범위 레지스터의 베이스 비트 및 마스크 비트를 설정한 경우에 응답하여, 상기 범위 레지스터의 밸리드 비트(valid bit) 및 락 비트(lock bit)를 설정하는 단계를 포함할 수 있다.
상기 페이지의 물리 주소를 획득하는 단계는, 변환 색인 버퍼(translation lookaside buffer; TLB)에 상기 액세스 요청의 상기 가상 주소에 대한 상기 페이지 테이블 엔트리가 캐시(cache)되어 있는지 여부를 확인하는 단계를 포함할 수 있다. 일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 상기 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 설정된 범위 레지스터와 상기 획득된 물리 주소의 비교를 생략하는 단계를 포함할 수 있다.
일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성에 기초하여 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계를 포함할 수 있다.
일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 상기 결정된 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부에 기초하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성을 업데이트하는 단계를 포함할 수 있다. 일 실시예에 따른 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법은, 상기 업데이트된 페이지 테이블 속성을 상기 페이지 테이블 엔트리와 함께 변환 색인 버퍼에 캐시하는 단계를 포함할 수 있다.
상기 획득된 물리 주소에 대응하는 영역 커널 코드 영역에 포함되는지 여부를 판단하는 단계는, 상기 범위 레지스터의 마스크 비트에 기초하여, 상기 물리 주소 중 부분 주소를 결정하는 단계를 포함할 수 있다.
상기 획득된 물리 주소에 대응하는 영역 커널 코드 영역에 포함되는지 여부를 판단하는 단계는, 상기 결정된 부분 주소가 상기 범위 레지스터의 베이스 비트의 적어도 일부에 매칭되는 경우 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 것을 판단하는 단계를 포함할 수 있다.
일 실시예에 따른 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치는, 프로세서가 머신 모드(machine mode)인 동안, 커널 코드(kernel code)가 저장된 커널 코드 영역의 물리 주소(physical address)에 기초하여 범위 레지스터(range register)를 설정(configure)하고, 상기 프로세서가 커널 모드(kernel mode)인 동안 페이지(page)의 가상 주소에 기초한 액세스 요청을 수신하는 경우에 응답하여, 상기 페이지의 상기 가상 주소에 대한 페이지 테이블 엔트리(page table entry)를 이용하여 상기 페이지의 물리 주소를 획득하며, 상기 설정된 범위 레지스터를 상기 획득된 물리 주소와 비교함으로써, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하고, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부에 기초하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블(enable) 또는 디스에이블(disable) 여부를 결정하는 프로세서를 포함할 수 있다.
상기 프로세서는, 상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다. 상기 프로세서는, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작(write operation)을 디스에이블할 수 있다.
상기 프로세서는, 상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다. 상기 프로세서는, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(execute operation)을 인에이블할 수 있다.
상기 프로세서는, 상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다. 상기 프로세서는, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역과 다른 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(excute operation)을 디스에이블(disable)할 수 있다.
상기 프로세서는, 상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다. 상기 프로세서는, 상기 페이지 테이블 엔트리의 페이지 테이블 속성(page table attribute)과 독립적으로, 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다.
상기 프로세서는, 상기 프로세서가 머신 모드인 동안, 커널 코드를 가지는 페이지를 미리 결정된 크기를 가지는 청크(chunk)의 경계(boundary)에 따라 정렬(align)할 수 있다.
상기 프로세서는, 상기 커널 코드를 적어도 하나의 커널 코드 청크(kernel code chunk)로 저장할 수 있다. 상기 프로세서는, 각 커널 코드 청크(kernel code chunk)에 대하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 적어도 일부를 설정할 수 있다.
상기 프로세서는, 각 커널 코드 청크의 시작 물리 주소에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 베이스 비트(base bit)를 설정할 수 있다. 상기 프로세서는, 해당 커널 코드 청크의 크기에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 마스크 비트(mask bit)를 설정할 수 있다.
상기 프로세서는, 상기 범위 레지스터의 베이스 비트 및 마스크 비트를 설정한 경우에 응답하여, 상기 범위 레지스터의 밸리드 비트(valid bit) 및 락 비트(lock bit)를 설정할 수 있다.
상기 프로세서는, 변환 색인 버퍼(translation lookaside buffer; TLB)에 상기 액세스 요청의 상기 가상 주소에 대한 상기 페이지 테이블 엔트리가 캐시(cache)되어 있는지 여부를 확인할 수 있다. 상기 프로세서는, 상기 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 설정된 범위 레지스터와 상기 획득된 물리 주소의 비교를 생략할 수 있다.
상기 프로세서는, 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성에 기초하여 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다.
상기 프로세서는, 상기 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있지 않은 경우에 응답하여, 페이지 테이블로부터 상기 가상 주소에 대한 상기 페이지 테이블 엔트리를 검색할 수 있다. 상기 프로세서는, 상기 검색된 페이지 테이블 엔트리에 기초하여, 상기 가상 주소에 매핑된 상기 페이지의 상기 물리 주소를 획득할 수 있다.
상기 프로세서는, 상기 결정된 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부에 기초하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성을 업데이트할 수 있다. 상기 프로세서는, 상기 업데이트된 페이지 테이블 속성을 상기 페이지 테이블 엔트리와 함께 변환 색인 버퍼에 캐시할 수 있다.
상기 프로세서는, 상기 범위 레지스터의 마스크 비트에 기초하여, 상기 물리 주소 중 부분 주소를 결정할 수 있다. 상기 프로세서는, 상기 결정된 부분 주소가 상기 범위 레지스터의 베이스 비트의 적어도 일부에 매칭되는 경우 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 것을 판단할 수 있다.
커널 코드 무결성은 커널 페이지 테이블 무결성을 먼저 보호하지 않고도 보장될 수 있다. 프로세서의 액세스 제어 논리를 재사용함으로써 모든 메모리 액세스들을 검사하는 작은 하드웨어 확장은 도입될 수 있다.
일 실시예에 따른 프로세서는 성능과 에너지 소비뿐만 아니라 칩 면적과 임계 경로 지연에도 작은 영향을 미치도록 설계되고 구현될 수 있다. 메커니즘은 포괄적으로 평가될 수 있다.
일 실시예에 따른 프로세서는 제안된 마이크로아키텍처 변경 사항들을 평가하기 위하여, RTL에서 RISC-V SoC, Rocket Chip의 구현을 확장함으로써 구현될 수 있고, FPGA 기반 프로토타입에 대한 실험으로 평가될 수 있다.
도 1은 일 실시예에 따른 프로세서의 동작을 설명하기 위한 도면이다.
도 2는 일 실시예에 따른 프로세서가 커널 코드 영역에 대한 동작을 제어하기 위한 방법을 설명하기 위한 도면이다.
도 3은 일 실시예에 따른 범위 레지스터의 설정 동작을 설명하기 위한 도면이다.
도 4는 일 실시예에 따른 복수의 비트들을 가지는 범위 레지스터의 구조를 설명하기 위한 도면이다.
도 5는 일 실시예에 따른 프로세서가 액세스 요청의 가상 주소에 매핑된 물리 주소를 획득하는 동작을 설명하기 위한 도면이다.
도 6는 일 실시예에 따른 프로세서가 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하는 동작을 설명하기 위한 도면이다.
도 7는 일 실시예에 따른 프로세서가 물리 주소에 대응하는 영역에 대한 동작의 인에이블 또는 디스에이블 여부를 결정하는 동작을 설명하기 위한 도면이다.
도 8은 일 실시예에 따른 프로세서가 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 변환 색인 버퍼에 캐시되어 있지 않은 경우 페이지 테이블 속성을 업데이트하는 동작을 설명하기 위한 도면이다.
도 9은 일 실시예에 따른 프로세서가 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 변환 색인 버퍼에 캐시되어 있는 경우 페이지 테이블 속성을 업데이트하는 동작을 설명하기 위한 도면이다.
도 10은 일 실시예에 따른 프로세서 및 비교 실시예에 따른 프로세서의 성능을 LMBench를 이용하여 측정한 결과를 설명하기 위한 도면이다.
도 11은 일 실시예에 따른 비교 실시예에 따른 프로세서를 가지는 시스템의 실행 시간으로 정규화된 일 실시예에 따른 프로세서를 가지는 시스템의 워크로드의 실행 시간을 도시한다.
도 12는 일 실시예에 따른 SPEC 2006 벤치마크 제품군의 12개의 워크로드들의 정규화된 실행 시간을 도시한다.
도 13은 일 실시예에 따른 프로세서의 정규화된 추가적인 에너지 소모를 설명하기 위한 도면이다.
실시예들에 대한 특정한 구조적 또는 기능적 설명들은 단지 예시를 위한 목적으로 개시된 것으로서, 다양한 형태로 변경되어 구현될 수 있다. 따라서, 실제 구현되는 형태는 개시된 특정 실시예로만 한정되는 것이 아니며, 본 명세서의 범위는 실시예들로 설명한 기술적 사상에 포함되는 변경, 균등물, 또는 대체물을 포함한다.
제1 또는 제2 등의 용어를 다양한 구성요소들을 설명하는데 사용될 수 있지만, 이런 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 해석되어야 한다. 예를 들어, 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소는 제1 구성요소로도 명명될 수 있다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, "포함하다" 또는 "가지다" 등의 용어는 설명된 특징, 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함으로 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 해당 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가진다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 갖는 것으로 해석되어야 하며, 본 명세서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 실시예들을 첨부된 도면들을 참조하여 상세하게 설명한다. 첨부 도면을 참조하여 설명함에 있어, 도면 부호에 관계없이 동일한 구성 요소는 동일한 참조 부호를 부여하고, 이에 대한 중복되는 설명은 생략하기로 한다.
도 1은 일 실시예에 따른 프로세서의 동작을 설명하기 위한 도면이다.
일 실시 예에 따르면, 프로세서는 프로세서에서 실행되는 프로그램들에 의한 데이터 액세스를 처리하기 위해 가상 메모리 기술을 사용할 수 있다. 예를 들어, 프로그램들은 응용 프로그램들, 운영 체제들, 장치 드라이버들, 가상 기계들, 주변 장치들에 의해 실행되는 소프트웨어 등을 포함할 수 있다.
일반적으로, 프로세서 내의 프로그램에 의해 데이터가 액세스될 때, 데이터를 포함하는 소정의 크기(예: 4 kB, 2 MB)의 블록 또는 "페이지"가 대용량 저장 장치(예: 디스크 드라이브, 반도체 메모리)로부터 프로세서 내 메모리에서의 이용 가능한 물리적 위치로 복사되거나 메모리에 새롭게 생성될 수 있다. 프로그램들이 메모리에서의 페이지들의 물리적 위치들을 추적하도록 요구받는 것을 피하기 위해, 프로세서가 프로그램들에 대한 페이지들의 물리적 위치들을 추적할 수 있다. 프로그램들은 페이지들의 물리적 위치들에 기초한 주소들(또는 물리 주소들)을 사용하여 메모리에 액세스하는 대신, 대응하는 프로그램들에 특정한 로컬 주소 공간들인 가상 주소 공간들의 가상 주소들을 사용하여 메모리에 액세스할 수 있다. 프로그램의 관점에서, 가상 주소들은 데이터가 메모리에 저장되는 실제 물리적 위치들을 나타내고, 그에 따라 가상 주소들을 사용하여 프로그램들이 메모리 액세스를 수행할 수 있다. 그러나, 가상 주소들은 메모리의 페이지들에 데이터가 저장되는 실제 위치들의 물리 주소들에 직접 매핑되지 않을 수 있다. 프로세서는 페이지들의 물리적 위치들을 추적하는 일환으로, 메모리 액세스 요청들에서의 프로그램들에 의해 사용되는 가상 주소들을 데이터가 실제로 위치한 물리 주소들로 변환할 수 있다. 그 다음 프로세서는 물리 주소들을 사용하여 프로그램들에 대한 메모리 액세스를 수행할 수 있다.
일 실시예에 따르면, 프로세서는, 메인 메모리의 물리 주소를 프로그램에 의해 사용되는 가상 메모리 주소로 추상화할 수 있다. 가상 주소와 물리 주소 사이의 변환은 전형적으로, 메모리 관리 유닛(memory management unit; MMU)으로 지칭되는 하드웨어에 의해 수행될 수 있다.
가상 주소 및 물리 주소 간의 변환을 위해, 메모리 관리 유닛(MMU)은 페이지 테이블을 포함할 수 있다. 페이지 테이블은 페이지 테이블 엔트리(page table entry; PTE)(또는 엔트리(entry))를 메모리에 저장된 데이터의 페이지들에 대한 가상 주소 대 물리 주소 변환 정보와 포함하는 프로세서의 메모리에 저장된 레코드를 포함할 수 있다. 예를 들어, 페이지 테이블은 가상 주소들에 대응하는 물리 주소들로의 매핑들을 가질 수 있다. 페이지 테이블에서의 검색은 페이지 테이블 워크(page table walk)로 지칭될 수 있고, 페이지 테이블 워커(page table walker; PTW)로서 지칭되는 메모리 관리 유닛(MMU)의 하드웨어에 의해 수행될 수 있다. 예를 들어, 메모리 관리 유닛(MMU)은 소정의 가상 주소의 메모리에 액세스하기 위한 액세스 요청을 프로그램으로부터 수신하면, 페이지 테이블 워크를 수행함으로써 페이지 테이블로부터 대응하는 물리 주소 정보를 획득할 수 있다.
전술한 페이지 테이블 워크들이 상대적으로 느리기 때문에, 페이지 테이블 워크들을 수행하는 것을 피하는 것이 바람직할 수 있다. 따라서, 프로세서는 페이지 테이블 워크들 동안 획득된 페이지 테이블 엔트리들(또는 페이지 테이블 엔트리들에 기초한 정보)의 제한된 수의 카피를 저장하기 위해 사용되는 로컬 캐시들인 변환 색인 버퍼(translation lookaside buffer; TLB)들을 포함한다. 동작 동안, 프로세서는, 가상 주소 및 물리 주소 간의 변환을 수행하기 위하여, TLB로부터 캐싱된 페이지 테이블 엔트리들을 획득하는 것을 시도할 수 있다.
TLB에는 복수의 페이지 테이블 엔트리들이 저장될 수 있다. 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 TLB 내에 캐시되어 있으면(예: TLB 히트(TLB hit)이면), 해당 변환이 즉시 이용 가능할 수 있다. 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 TLB 내에 캐시되어 있지 않으면(예: TLB 미스(TLB miss)이면), 페이지 테이블 워크를 통해 페이지 테이블 엔트리를 획득하고, 획득된 페이지 테이블 엔트리의 카피를 TLB에 캐싱할 수 있다.
이하, 본 명세서에서 주로 일 실시예에 따른 커널 코드 영역에 대한 동작을 제어하기 위한 방법을 수행하는 RISC-V 아키텍처 확장에 기초하여 설명한다.
RISC-V는 축소 명령어 집합 컴퓨팅(reduced instruction set computing)(RISC) 명령어 집합 아키텍처(instruction set architecture)(ISA)의 오픈 소스 구현을 포함할 수 있다. 메타데이터 태그는 각 워드에 대한 명령어 및 데이터 둘 모두에 배치된다. RISC-V 아키텍처에서 워드는 64 비트일 수 있다. RISC-V 아키텍처는 상이한 워드 크기 변형성을 제공할 수 있다. 예를 들어, RV64는 64 비트 워드 크기이고 RV32는 32 비트 워드 크기일 수 있다. 레지스터 및 사용자 주소 공간의 너비 또는 크기는 워드 크기에 따라 다를 수 있다. 태그 크기 또는 너비는 워드 크기 또는 너비와 독립적일 수 있지만, 예시적으로, 태그 크기 또는 너비는 워드 크기 또는 너비와 동일할 수 있다.
RISC-V 아키텍처는 예를 들어, ["The RISC-V Instruction Set Manual Vol. I, User-Level ISA, Version 2.0", May 6, 2014, Waterman, Andrew, et. al., ("also referred to as the "RISC-V user level ISA")]에 설명된 바와 같은 사용자 레벨 명령어를 포함하며, 이 문헌은 본 명세서에서 참조로 포함되고, 예를 들어 RISCV.ORG 웹 사이트 및 버클리 소재의 유니버시티 오브 캘리포니아(University of California)를 통해 Technical Report UCB/EECS-2014-54로서 대중에게 입수 가능하다. RISC-V 아키텍처는 또한 예를 들어 ["The RISC-V Instruction Set Manual Volume II: Privileged Architecture, Version 1.7", May 9, 2015, also referred to as the "RISC-V privileged ISA")]에 설명된 바와 같이, 오퍼레이팅 시스템, 부착형 외부 디바이스 등을 실행하는데 필요한 권한 있는 명령어 및 추가 기능성을 포함하는 권한 있는 아키텍처를 통합하며, 이 문헌은 본 명세서에서 참조로 포함되고, 예를 들어, RISCV.ORG 웹 사이트 및 버클리 소재의 University of California를 통해 Technical Report UCB/EECS-2015-49로서 대중에게 입수 가능하다.
RISC-V 아키텍처의 실시예는 다음과 같은 네 개의 RISC-V 권한 레벨을 가질 수 있다: 사용자/애플리케이션(user/application; U) 권한 레벨에 대한 레벨 0, 수퍼바이저(supervisor; S) 권한 레벨에 대한 레벨 1, 하이퍼바이저(hypervisor; H) 권한 레벨에 대한 레벨 2, 및 머신(machine; M) 권한 레벨에 대한 레벨 3. 프로세서는 사용자 모드(user mode)인 동안, 사용자/애플리케이션 권한 레벨을 가질 수 있다. 프로세서는, 커널 모드(kernel mode)인 동안, 수퍼바이저 권한 레벨을 가질 수 있다. 프로세서는, 머신 모드(machine mode)인 동안, 머신 권한 레벨을 가질 수 있다. RISC-V 권한 레벨은 최고 내지 최저의 0부터 3까지의 순위가 매겨질 수 있고, 레벨 0이 가장 낮은 권한 레벨을 나타내고, 레벨 3이 가장 높은 권한 레벨을 나타낼 수 있다. 이러한 권한 레벨은 상이한 컴포넌트들 간에 보호를 제공하는데 사용될 수 있으며, 현재 권한 레벨 또는 모드에서 허용되지 않는 연산을 수행하는 코드를 실행하려 시도하면 기본 실행 환경으로 향하게 하는 트랩과 같은 예외가 일어나도록 유발할 수 있다.
머신 레벨(예: 프로세서가 머신 모드인 동안 가지는 권한 레벨)은 가장 높은 권한을 가질 수 있고, RISC-V 하드웨어 플랫폼에서 유일한 강제적 권한 레벨(mandatory privilege level)일 수 있다. 머신 모드(M-모드)에서 실행되는 코드는 머신 구현으로의 액세스 레벨이 낮기 때문에 본질적으로 신뢰성을 가질 수 있다. 사용자 모드(U-모드) 및 수퍼바이저 모드(S-모드)는 각각 통상의 애플리케이션 및 오퍼레이팅 시스템용으로 의도되지만, 하이퍼바이저 모드(H-모드)는 가상 머신 모니터를 지원하도록 의도될 수 있다. 각 권한 레벨은 임의적 확장과 변형성을 가진 핵심 권한 ISA 확장 세트를 가질 수 있다.
RISC-V 아키텍처의 구현은 적어도 M-모드를 지원하여야 하고 대부분의 구현은 적어도 U-모드 및 M-모드를 지원한다는 것을 유의하여야 할 수 있다. S-모드는 수퍼바이저 레벨 오퍼레이팅 시스템의 코드와 M-모드에서 실행되는 다른 보다 권한 있는 코드 간의 추가 분리를 제공하기 위해 추가될 수 있다. 사용자 또는 애플리케이션 코드는 전형적으로 트랩(예를 들어, 수퍼바이저 호출, 페이지 폴트(page fault)) 또는 인터럽트가 발생하여 지원되는 상위 권한 모드 또는 레벨(예를 들어, H, S 또는 M 모드) 중 하나에서 실행되는 트랩 핸들러로 제어를 강제로 이전할 때까지 U-모드에서 실행될 수 있다. 이후 트랩 핸들러의 코드가 실행된 다음 트랩을 유발한 원래 사용자 코드 또는 애플리케이션으로 제어가 반환될 수 있다. 이러한 사용자 코드 또는 애플리케이션의 실행은 트랩 핸들러 호출을 트리거했던 U-모드의 원래의 트랩된 명령어에서 또는 그 이후에서 재개될 수 있다.
RISC-V 구현에서 지원되는 모드들의 다양한 조합은, 예시적으로, 단일 M 모드, M 및 U를 가지는 두 개의 모드들, M, S 및 U를 가지는 세 개의 모드들, 또는 M, H, S, 및 U를 가지는 네 개의 모드들을 포함할 수 있다.
RISC-V 아키텍처는 하나 이상의 연관된 권한 레벨에 의해 판독되고 수정될 수 있는 제어 상태 레지스터(Control Status Register; CSR)를 가질 수 있다. CSR은 네 개의 권한 레벨 중 첫 번째 권한 레벨과 첫 번째 권한 레벨보다 높은 네 개 권한 레벨 중 임의의 다른 권한 레벨에서 액세스 가능할 수 있다. 예를 들어, 프로그램이 U-모드(예: 레벨 0)에서 실행 중일 때 규칙 캐시 미스와 같은 트랩이 발생하면, 제어는 규칙 캐시 미스 핸들러 코드와 같은 상위 권한 또는 모드(예: 레벨 1 내지 3 중 임의의 레벨)에서 실행 중인 트랩 핸들러로 이전될 수 있다. 트랩이 발생하면, 정보는 M-모드에서 실행되는 트랩 핸들러에 액세스 가능한 CSR에 배치될 수 있다. M-모드에서 실행되는 트랩 핸들러에 액세스 가능한 CSR은, 더 낮은 권한 레벨에서 실행되는 임의의 다른 코드(예: H, S 또는 U 모드에서 액세스 불가능한 코드)에 액세스 불가능할 수 있다.
많은 임베디드 시스템들에서, 운영 체제 커널은 프로세스들 간의 격리(isolation) 및 액세스 제어 정책들의 시행(enforcement)을 포함한 리소스 관리를 책임질 수 있다. 이러한 책임은, 커널이 간결하게 작성되는 것을 어렵게 만들 수 있고, 매년 새로운 보안 취약점들이 발견되는 것을 초래할 수 있다. 보안 취약점들 중 하나를 알고 있는 공격자는 페이지 테이블들 또는 코드를 포함하는 커널의 메모리 페이지들을 임의로 읽거나 수정하기 위한 수단들을 획득할 수 있다.
강력한 공격자가 우회할 수 있는 정책들 중 하나는 커널 코드 무결성(kernel code integrity)을 포함할 수 있다. 커널 코드 무결성은 운영 체제 커널이 커널에 속하지 않은 코드의 조각들을 실행하도록 속지 않아야 하는 특성을 나타낼 수 있다. 시스템이 이 정책(policy)을 시행하는 데 실패하면, 공격자는 거의 임의적인 방식으로 피해자 시스템을 조작할 수 있는 힘(power)을 얻을 수 있다. 예를 들어, 공격자는 임의의 어플리케이션 레벨의 보안 메커니즘 또는 어플리케이션 배포에 관한 공급자 설치된(vendor-installed) 보안 정책도 우회할 수 있다.
이러한 위협들로 인해, 이러한 공격들을 방지하기 위한 메커니즘은 연구 커뮤니티 및 장치 제조업체들에 의하여 찾아질 수 있다. 오늘날 대부분의 프로세서들은 운영 체제 커널이 특수 페이지 테이블 속성들(attributes)을 커널 코드를 포함하는 페이지들에 연관시키는 것을 가능하게 할 수 있다. 특수 페이지 테이블 속성들을 이용하여, 프로세서는 커널 권한이 있는 모드(예: 수퍼바이저 모드)에서 실행되는 동안 커널 코드를 수정하거나 커널 코드의 외부에서 실행하려는 모든 시도를 거부할 수 있다. 커널 코드 페이지를 읽기 전용으로 만드는 것은 커널 코드 페이지의 이러한 바람직하지 않은 수정들을 금지하지만, 커널 코드 페이지들의 외부로부터의 실행의 방지는 모든 페이지 테이블들에 정책이 적용되는 것이 요구될 수 있다. 후자의 페이지 테이블 속성은 일반적으로 PXN(Privileged Execute Never) 또는 SMEP(Supervisor Mode Execution Prevention)라고 불릴 수 있다. 프로세서가 수퍼바이저 모드(예: 커널 권한 레벨을 가지는 커널 모드)에서 실행되는 동안, 설정될 때, 페이지들은 실행 가능하지 않은 것으로 간주될 수 있다. 이는, 원하는 목표를 달성하기 위하여, 커널 코드 페이지용을 제외하고 커널이 생성하는 모든 페이지 테이블 엔트리들은 비트 세트를 가져야 하는 것을 의미할 수 있다. 그럼에도 불구하고, 최신 운영 체제 커널들은, 커널에 의하여 승인된 메모리 컨텐츠들만이 커널의 권한으로 실행되는 것을 보장하기 위하여 이 기능을 채택할 수 있다.
페이지 테이블 속성들을 가지는 기존 보호는, 페이지 테이블들을 직접 손상시키는 커널 위업(exploits)에 취약할 수 있다. 커널이 각 프로세스에 대해 하나 이상의 페이지 테이블들을 유지 관리하고 반복적으로 수정해야 하기 때문에, 페이지 테이블들은 운영 체제 커널에 의하여 쓰기 가능한 것으로 유지되어야 할 수 있다. 그러므로, 커널 취약점을 악용하는 공격자는 종래 기술에서 제안된 바와 같이, 공격자의 코드를 포함하는 물리적 페이지를 포인팅하는 권한 있는 실행 가능한 가상 페이지를 생성하기 위하여 커널이 페이지 테이블 엔트리를 직접 손상시키도록 속일 수 있다.
따라서, 커널 코드 무결성은 페이지 테이블이 악의적인 수정들로부터 자유로운 경우에만 보장될 수 있다. 기존 메커니즘들은 종종 작은 임베디드 시스템들에서 바람직하지 않은 페이지 테이블을 손상시키는 이러한 공격들을 물리치기 위하여 다른 신뢰할 수 있는 소프트웨어 구성 요소에 의존할 수 있다. 예를 들어, 기존 메커니즘은, 페이지 테이블 업데이트를 ARM TruseZone에 의해 보호되는 신뢰할 수 있는 소프트웨어로 리디렉션할 수 있다. 다른 예를 들어, 기존 메커니즘은, 페이지 테이블 무결성을 위해 하이퍼바이저(hypervisor)에 의존할 수 있다.
본 명세서에서, 커널이 페이지 테이블 무결성에 의존하지 않고 커널 코드 무결성을 보호하는 것을 가능하게 하는 작은 하드웨어 확장으로서 일 실시예에 따른 프로세서(본 명세서에서, 'PRIVLOCK'라고도 표현됨)이 개시될 수 있다. 일 실시예에 따른 프로세서를 이용하여, 커널은 프로세서가 커널의 권한으로 커널 승인된 코드만 실행하는 것을 보장할 수 있다. 일 실시예에 따른 프로세서는 임베디드 시스템에서 커널 코드 페이지들이 관리되는 방법에 대한 세 가지 관찰에 기반할 수 있다.
첫째, 커널 코드를 포함하는 물리적 또는 가상 페이지들의 세트는 자주 변경되지 않을 수 있다. 코어 커널을 포함하는 대부분의 페이지들은, 부팅 시 할당(allocate)되고 런타임 동안 온전하게(intact) 유지될 수 있다. 운영 체제 커널들은 장치 드라이버들과 같은 추가 기능들을 위해 추가 코드를 동적으로 로딩하지만, 이는 특히 주변 장치들의 고정된 세트를 자주 이용하는 임베디드 시스템에서 드물게 발생할 수 있다.
둘째, 운영 체제는 물리적 주소 공간에서 메모리 페이지를 관리하는 데 어느 정도의 유연성을 가질 수 있다. 프로그램들은 코드 또는 데이터 메모리에 액세스하기 위하여 가상 주소들을 이용하고, 커널은 필요한 경우 이러한 페이지들을 물리적 주소 공간에 다시 위치시킬 수 있다.
셋째, 메모리 관리 장치(memory management unit; MMU)는 커널 코드 페이지들을 보호하는 데 필요한 모든 속성 확인들을 구현할 수 있다. 유일한 추가 요구사항은 커널 코드 무결성을 보호하기 위하여 원하는 액세스 제어 정책을 준수하도록 속성들을 적절하게 제거(properly sanitize)하는 것을 포함할 수 있다.
이러한 관찰들 외에도, 일 실시예에 따른 프로세서는 승인된 커널 코드를 포함하는 주소 범위들 또는 페이지들의 세트를 정의하는 데 커널이 이용하는 추가 프로세서 제어 레지스터들(additional inprocessor control registers)(예: RISC-V 프로세서의 제어 및 상태 레지스터들(Control and Status Registers; CSRs))를 도입할 수 있다. 값을 이용하여, 일 실시예에 따른 프로세서는 프로세서가 특권 모드에서 실행되는 동안 지정된 물리적 메모리 페이지에서만 명령어들을 가져오고 페이지에 쓰기를 거부하는 것을 보장할 수 있다. 이 아키텍처 확장을 통해, 커널 코드 무결성은 더 이상 페이지 테이블의 무결성에 의존하지 않을 수 있다. 커널은 필요에 따라 커널의 페이지 테이블을 자유롭게 관리할 수 있다. 추가 제어 레지스터들의 무결성은, 많은 임베디드 시스템들에서 자주 해당하는, 시스템이 추가적인 코드를 로딩하지 않아야 하는 것을 가정하면, 시스템 부팅 후 일부 중요한 읽기 전용 레지스터를 쓰기 방지(write-protect)하는 데 일반적으로 사용되는 잠금 메커니즘에 의해 보호될 수 있다.
일 실시예에 따르면, 위협 모델은 커널 수준 공격에 대한 방어 메커니즘이 가정하는 일반적인 위협 모델을 따를 수 있다. 공격자는, 공격자가 지정한 메모리 위치들을 커널의 권한으로 읽거나 수정하도록 커널을 속일 수 있는 하나 이상의 커널 취약점들을 알고 있는 것으로 가정될 수 있다. 이는 커널이 정기적으로 읽고 수정하는 페이지 테이블을 포함할 수 있다. 운영 체제 커널 및 언더라잉 프로세서(underlying processor)는 이를 무력화하기 위해 최첨단 방어 메커니즘을 구현할 수 있다. 예를 들어, 페이지 테이블 엔트리는 PXN/SMEP와 같은 속성들을 포함하고, 커널은 특정 페이지를 실행 가능하지 않은 권한으로 만들 수 있다.
커널은 또한 합법적인 커널 코드 페이지에 대한 페이지 테이블 엔트리만 실행 가능한 권한으로 설정되도록 신중하게 작성될 수 있다. 이 위협 모델에서, 공격자는 페이지 테이블을 직접 수정함으로써 페이지에 대한 실행 가능한 권한 매핑을 생성하는 악성 코드 스니펫이 포함된 메모리 페이지를 준비함으로써 이 방어를 우회할 수 있다. 공격자는 그 이후에, 커널이 페이지로부터 실행되도록 할 수 있다. 일 실시예에 따른 프로세서는 커널 코드에 대해 구성된 물리적 페이지들을 이용하여 각 TLB 리필의 페이지 테이블 엔트리들을 소독(sanitizing)함으로써 이를 중지할 수 있다.
일 실시예에 따르면, 커널 코드 무결성을 효율적이고 효과적으로 보호하기 위해, 하드웨어는 두 번 변경되고, 운영 체제 커널은 한 번 변경될 수 있다. 그림 1은 두 가지 하드웨어 변경 사항이 나타날 수 있다. 일 실시예에 따른 프로세서는 커널 코드 페이지의 위치와 크기를 유지하는 추가 제어 레지스터(그림 2에서 후술됨), 및 페이지 테이블 워커에서 정책을 시행하기 위하여 페이지 테이블 엔트리를 검사하는 조합 로직을 추가할 수 있다. 커널에서, 페이지 폴트 핸들러(page fault handler)는 페이지 폴트(page fault)가 일 실시예에 따른 프로세서에 의하여 시행된 정책의 위반으로 인한 것인지 추가로 확인하도록 수정될 수 있다.
이하, RISC-V 프로세서와 Linux 커널을 대상으로 하는 설계 및 구현에 대해 자세히 설명한다. 다만, 이에 한정하는 것은 아니고, 일 실시예에 따른 메커니즘은 가상 메모리 시스템이 있는 모든 운영 체제 커널 및 범용 프로세서에 적용될 수 있다. 프로토타입에 대한 자세한 내용은 도 10 내지 도 13에서 후술한다.
도 1에서 나타난 바와 같이, 일 실시예에 따른 프로세서는 하드웨어 구성요소들을 포함할 수 있다. 동작(①)에서, 프로세서는, 부팅 시 커널 코드 범위들을 설정(configure)할 수 있다. 동작(②)에서, 프로세서는, 설정된 커널 코드 범위들에 기초하여, 페이지 테이블 워커(PTW)에 포함된 범위 레지스터들(range registers)을 설정할 수 있다.
그 이후에, 프로세서는 커널 모드인 동안, 액세스 요청을 수신할 수 있다. 프로세서는 커널 코드 영역 판단부(kernel code region determiner)(PRIVLOCKCHECKER)를 포함할 수 있다. 동작(③)에서, 프로세서의 커널 코드 영역 판단부(PRIVLOCKCHECKER)는, 액세스 요청의 가상 주소에 매핑된 물리 주소를 수신할 수 있다. 프로세서의 커널 코드 영역 판단부(PRIVLOCKCHECKER)는 범위 레지스터와 수신된 물리 주소와 비교함으로써, 물리 주소에 대응하는 영역(예: 물리 주소에 대응하는 메모리의 부분 영역)이 커널 코드 영역에 포함되는지 여부를 판단할 수 있다. 프로세서는, 물리 주소에 대응하는 영역에 대한 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다. 프로세서는, 결정된 동작에 대한 인에이블 또는 디스에이블 여부에 기초하여 페이지 테이블 속성을 업데이트(예: 소독(sanitize))할 수 있다. 동작(④)에서, 프로세서의 커널 코드 영역 판단부(PRIVLOCKCHECKER)는, 변환 색인 버퍼(TLB)에게 업데이트된 페이지 테이블 속성을 가지는 페이지 테이블 엔트리(sanitized_pte)를 전달할 수 있다. 프로세서의 구체적인 동작은 도 2에서 후술한다.
도 2는 일 실시예에 따른 프로세서가 커널 코드 영역에 대한 동작을 제어하기 위한 방법을 설명하기 위한 도면이다.
일 실시예에 따른 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치는, 프로세서를 포함할 수 있다. 이하, 커널 코드 영역에 대한 동작을 제어하기 위한 프로세서의 동작을 설명한다.
단계(210)에서, 프로세서는 머신 모드(machine mode)인 동안, 범위 레지스터(range register)를 설정(configure)할 수 있다. 프로세서는, 커널 코드(kernel code)가 저장된 커널 코드 영역의 물리 주소(physical address)에 기초하여 범위 레지스터를 설정할 수 있다. 예를 들어, 프로세서는 부팅(booting) 시, 머신 모드일 수 있다. 프로세서는 운영 체제 커널을 머신 모드에서 실행하는 동안, CSRFile 인터페이스를 통해 코어(예: 로켓 코어(Rocket Core))의 범위 레지스터를 설정할 수 있다.
일 실시예에 따르면, 물리적 주소의 비트 개수를 가지는 컨트롤 레지스터는 도입될 수 있다. 예시적으로, 물리적 주소의 비트 개수는 32일 수 있다. 컨트롤 레지스터의 개수는 설계에 따라 설정될 수 있다. 예시적으로, 프로세서는 4개의 컨트롤 레지스터들을 포함할 수 있다. 범위 레지스터 및 범위 레지스터의 설정은 도 3 내지 도 4에서 후술한다.
단계(220)에서, 프로세서는 커널 모드(kernel mode)인 동안, 페이지(page)의 가상 주소에 기초한 액세스 요청을 수신하는 경우에 응답하여, 페이지의 물리 주소를 획득할 수 있다. 프로세서는, 페이지 테이블 엔트리(page table entry)를 이용하여, 액세스 요청의 가상 주소에 매핑된 물리 주소를 획득할 수 있다. 페이지 테이블 엔트리는, 액세스 요청의 가상 주소 및 해당 가상 주소와 매핑된 물리 주소에 관한 정보를 포함할 수 있다. 물리 주소의 획득은 도 5에서 후술한다.
단계(230)에서, 프로세서는, 설정된 범위 레지스터를 획득된 물리 주소와 비교함으로써, 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단할 수 있다. 예를 들어, 프로세서의 페이지 테이블 워커(PTW)는 커널 코드 영역 판단부(예: 도 1의 커널 코드 영역 판단부(PRIVLOCKCHECKER))를 포함할 수 있다. 프로세서의 커널 코드 영역 판단부는, 액세스 요청의 가상 주소에 매핑된 물리 주소를 수신할 수 있다. 프로세서의 커널 코드 영역 판단부는 범위 레지스터와 수신된 물리 주소와 비교함으로써, 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단할 수 있다.
일 실시예에 따르면, 페이지 테이블 워커(PTW)는 복수의 범위 레지스터들을 포함할 수 있다. 커널 코드 영역 판단부는, 복수의 범위 레지스터들 각각에 대하여, 해당 범위 레지스터와 물리 주소를 비교함으로써, 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단할 수 있다. 커널 코드 영역 판단부는, 물리 주소에 대응하는 영역이 복수의 범위 레지스터들 중 적어도 하나의 범위 레지스터에 의하여 결정된 범위에 포함되는 것에 기초하여, 해당 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 것을 결정할 수 있다. 커널 코드 영역 판단부는, 물리 주소에 대응하는 영역이 복수의 범위 레지스터들에 의하여 결정된 범위들에 포함되지 않는 것에 기초하여, 해당 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되지 않는 것을 결정할 수 있다. 범위 레지스터 및 물리 주소의 비교를 통한 물리 주소의 커널 코드 영역 포함 여부 판단은 도 6에서 후술한다.
단계(240)에서, 프로세서는 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부에 기초하여, 물리 주소에 대응하는 영역에 대한 동작에 대한 인에이블(enable) 또는 디스에이블(disable) 여부를 결정할 수 있다. 물리 주소에 대응하는 영역에 대한 동작은 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작을 포함할 수 있다.
메모리의 영역에 대한 쓰기 동작은, 메모리의 영역에 데이터를 저장하는 동작으로서, 해당 영역에 커널 모드인 동안 데이터를 저장하는 커널 모드의 쓰기 동작 및 해당 영역에 사용자 모드인 동안 데이터를 저장하는 사용자 모드의 쓰기 동작을 포함할 수 있다.
메모리의 영역에 대한 실행 동작은, 메모리의 영역에 저장된 데이터(예: 프로그램 코드)에 기초한 프로그램을 실행하는 동작으로서, 커널 모드인 동안 해당 영역에 저장된 데이터에 기초한 프로그램을 실행하는 커널 모드의 실행 동작 및 사용자 모드인 동안 해당 영역에 저장된 데이터에 기초한 프로그램을 실행하는 사용자 모드의 실행 동작을 포함할 수 있다. 동작의 인에이블 또는 디스에이블 여부의 결정은 도 7에서 후술한다.
일 실시예에 따르면, 페이지 테이블 엔트리는 가상 주소 및 해당 가상 주소에 매핑된 물리 주소를 포함할 수 있다. 페이지 테이블 엔트리는, 페이지 테이블 속성과 함께 저장될 수 있다. 페이지 테이블 속성은, 대응하는 페이지 테이블 엔트리의 물리 주소를 가지는 메모리 영역에 대한 동작(예: 커널 모드의 쓰기 동작, 사용자 모드의 쓰기 동작, 커널 모드의 쓰기 동작, 사용자 모드의 실행 동작)의 인에이블 또는 디스에이블 여부에 관한 정보를 포함할 수 있다. 예를 들어, 페이지 테이블 속성은, 커널 모드의 쓰기 동작의 인에이블 여부를 지시하는 비트(예: sw 비트), 사용자 모드의 쓰기 동작의 인에이블 여부를 지시하는 비트(예: w 비트), 커널 모드의 실행 동작의 인에이블 여부를 지시하는 비트(예: sx 비트), 및 사용자 모드의 실행 동작의 인에이블 여부를 지시하는 비트(예: x 비트)를 가질 수 있다. 페이지 테이블 속성의 업데이트는 도 8에서 후술한다.
도 3은 일 실시예에 따른 범위 레지스터의 설정 동작을 설명하기 위한 도면이다.
도 4는 일 실시예에 따른 복수의 비트들을 가지는 범위 레지스터의 구조를 설명하기 위한 도면이다.
단계(310)에서, 프로세서는, 머신 모드인 동안, 커널 코드를 가지는 페이지를 미리 결정된 크기를 가지는 청크(chunk)의 경계(boundary)에 따라 정렬(align)할 수 있다.
후술하겠으나, 프로세서는 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하기 위하여, 복수의 비트들로 표현된 물리 주소의 일부를 범위 레지스터와 비교할 수 있다. 예시적으로, 프로세서는 물리 주소 중 하나 이상의 상위 비트들(upper bits)에 대응하는 부분 주소를 범위 레지스터와 비교할 수 있다. 프로세서는, 물리 주소에 대응하는 메모리 영역이 커널 코드 영역에 포함되는지 여부를 판단하는 데 물리 주소 중 상위 비트들에 대응하는 부분 주소가 요구되도록, 커널 코드를 저장할 수 있다. 프로세서는 커널 코드가 저장된 커널 코드 영역을 미리 결정된 크기를 가지는 청크(예: 16MB의 청크, 16KB의 청크)의 경계에 따라 정렬할 수 있다. 예시적으로, 16MB는 224에 대응하므로, 16MB의 청크의 경계는, 32 비트들로 표현된 물리 주소 중 8개의 상위 비트들에 의하여 결정될 수 있다. 16MB의 청크의 경계는 24개의 하위 비트들 각각이 모두 0의 값을 가질 수 있다.
단계(320)에서, 프로세서는, 커널 코드를 적어도 하나의 커널 코드 청크(kernel code chunk)로 저장할 수 있다. 커널 코드 청크는, 커널 코드의 적어도 일부가 연속적으로 저장된 메모리의 영역을 의미할 수 있다. 커널 코드 청크는, 커널 코드에 대응하는 커널 코드 페이지로 지칭될 수 있다. 커널 코드는 복수의 커널 코드 청크들로 저장될 수 있다.
일 실시예에 따르면, 커널 코드 영역 판단부(예: 도 1의 커널 코드 영역 판단부(PRIVLOCKCHECKER))는 각 커널 코드 청크가 크기에 맞춰 정렬되어야 하는 것을 요구하기 때문에, 커널 코드 페이지는 일 실시예에 따른 프로세서에 의해 보호되고 정렬되어야 할 수 있다. 성능에 영향을 미치지 않으면서 작은 변경으로 커널 코드 청크를 정렬할 수 있는 것이 발견될 수 있다. 운영 체제 커널들은 일반적으로 수 메가바이트에서 수십 메가바이트의 코드를 가질 수 있다. 예를 들어, 구현에서 실행되는 Linux 커널은 약 3.04MB의 코드를 가질 수 있다. 커널 코드 청크가 2MB 경계에 맞춰질 수 있다. 결과적으로, 2개의 2MB의 커널 코드 청크들은 초래될 수 있고, 프로세서는 2개의 2MB의 커널 코드 청크들에 대한 2개의 범위 레지스터들의 사용할 수 있다. 커널 코드 청크의 정렬은 링커 스크립트(linker script)가 변경됨으로써 수행될 수 있다.
단계(330)에서, 프로세서는, 각 커널 코드 청크에 대하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 적어도 일부를 설정할 수 있다. 프로세서는, 복수의 커널 코드 청크들을 통해 커널 코드를 저장한 경우, 복수의 커널 코드 청크들에 대응하는 복수의 범위 레지스터들을 포함할 수 있다. 복수의 범위 레지스터들 각각은, 복수의 커널 코드 청크들 중 하나의 커널 코드 청크에 대응할 수 있다.
일 실시예에 따르면, 프로세서는, 각 커널 코드 청크의 시작 물리 주소에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 베이스 비트(base bit)를 설정할 수 있다. 범위 레지스터의 베이스 비트는, 범위 레지스터가 대응하는 커널 코드 청크의 시작 물리 주소에 관한 정보를 가질 수 있다. 예시적으로, 범위 레지스터의 복수의 비트들 중 20개의 상위 비트들인 베이스 비트는, 범위 레지스터가 대응하는 커널 코드 청크의 시작 물리 주소에 기초하여 결정될 수 있다. 예를 들어, 프로세서는 베이스 비트 중 일부(예: 18개의 비트들)는, 범위 레지스터가 대응하는 커널 코드 청크의 시작 물리 주소와 같은 값으로 결정될 수 있다.
예시적으로, 범위 레지스터는 32개의 비트들을 가질 수 있다. 베이스 비트는 범위 레지스터의 상위 20개 비트들일 수 있다. 20개의 비트들을 가지는 베이스 비트는, 2개의 상위 비트들은 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부의 판단과 독립적인 범위 레지스터에 대한 정보에 관한 비트들일 수 있다. 베이스 비트 중 2개의 상위 비트들 외의 18개의 비트들은, 범위 레지스터가 대응하는 커널 코드 청크의 시작 물리 주소와 같은 값을 가질 수 있다.
일 실시예에 따르면, 프로세서는, 각 커널 코드 청크의 크기에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 마스크 비트를 설정할 수 있다. 범위 레지스터의 마스크 비트는, 범위 레지스터가 대응하는 커널 코드 청크의 크기에 관한 정보를 가질 수 있다.
예시적으로, 마스크 비트는 베이스 비트에 후속하는 범위 레지스터의 10개 비트들일 수 있다. 10개의 비트들을 가지는 마스크 비트는, 각 커널 코드 청크의 크기에 기초하여 설정될 수 있다. 후술하겠으나, 프로세서는 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하기 위하여, 물리 주소의 일부와 범위 레지스터의 적어도 일부를 비교할 수 있다. 범위 레지스터의 적어도 일부(예: 베이스 비트)와 비교할 물리 주소의 상위 비트들은 커널 코드 청크의 크기에 기초하여 결정될 수 있다.
이하, 물리 주소는 32개의 비트들로 표현되는 경우 커널 코드 청크의 크기에 따라 마스크 비트를 설정하는 동작의 예시에 관하여 설명한다.
예시적으로, 커널 코드 청크의 크기가 16MB인 경우, 16MB는 224에 대응하므로, 해당 커널 코드 청크에 포함된 물리 주소의 24개의 하위 비트들은 서로 다른 값들을 가질 수 있다. 다시 말해, 해당 커널 코드 청크에 포함되었는지 여부는 물리 주소의 상위 8개의 비트들에 기초하여 결정될 수 있다. 프로세서는 범위 레지스터와 비교할 물리 주소의 상위 비트들을 8개의 상위 비트들로 결정할 수 있다. 프로세서는, 범위 레지스터와 비교할 물리 주소의 일부를, 미리 결정된 개수(예: 8개)에 마스크 비트에 기초하여 결정된 개수가 합산된 개수의 상위 비트들로 결정할 수 있다. 프로세서는, 커널 코드 청크의 크기가 16MB인 경우, 마스크 비트를 0000000000(2)으로 설정할 수 있다. 프로세서는, 마스크 비트가 0000000000(2)으로 설정된 경우, 물리 주소 중에서, 미리 결정된 개수(예: 8개)에 마스크 비트에 기초하여 결정된 개수(예: 0개)가 합산된 개수(예: 8개)의 상위 비트들을 범위 레지스터와 비교할 수 있다.
예시적으로, 커널 코드 청크의 크기가 1MB인 경우, 1MB는 220에 대응하므로, 해당 커널 코드 청크에 포함된 물리 주소의 20개의 하위 비트들은 서로 다른 값들을 가질 수 있다. 다시 말해, 해당 커널 코드 청크에 포함되었는지 여부는 물리 주소의 상위 12개의 비트들에 기초하여 결정될 수 있다. 프로세서는 범위 레지스터와 비교할 물리 주소의 상위 비트들을 12개의 상위 비트들로 결정할 수 있다. 프로세서는, 범위 레지스터와 비교할 물리 주소의 일부를, 미리 결정된 개수(예: 8개)에 마스크 비트에 기초하여 결정된 개수가 합산된 개수의 상위 비트들로 결정할 수 있다. 프로세서는, 커널 코드 청크의 크기가 1MB인 경우, 마스크 비트를 1111000000(2)으로 설정할 수 있다. 프로세서는, 마스크 비트가 1111000000(2)으로 설정된 경우, 물리 주소 중에서, 미리 결정된 개수(예: 8개)에 마스크 비트에 기초하여 결정된 개수(예: 4개)가 합산된 개수(예: 12개)의 상위 비트들을 범위 레지스터와 비교할 수 있다.
예시적으로, 커널 코드 청크의 크기가 16KB인 경우, 16KB는 214에 대응하므로, 해당 커널 코드 청크에 포함된 물리 주소의 14개의 하위 비트들은 서로 다른 값들을 가질 수 있다. 다시 말해, 해당 커널 코드 청크에 포함되었는지 여부는 물리 주소의 상위 18개의 비트들에 기초하여 결정될 수 있다. 프로세서는 범위 레지스터와 비교할 물리 주소의 상위 비트들을 18개의 상위 비트들로 결정할 수 있다. 프로세서는, 범위 레지스터와 비교할 물리 주소의 일부를, 미리 결정된 개수(예: 18개)에 마스크 비트에 기초하여 결정된 개수가 합산된 개수의 상위 비트들로 결정할 수 있다. 프로세서는, 커널 코드 청크의 크기가 16MB인 경우, 마스크 비트를 1111111111(2)으로 설정할 수 있다. 프로세서는, 마스크 비트가 1111111111(2)으로 설정된 경우, 물리 주소 중에서, 미리 결정된 개수(예: 8개)에 마스크 비트에 기초하여 결정된 개수(예: 10개)가 합산된 개수(예: 18개)의 상위 비트들을 범위 레지스터와 비교할 수 있다.
일 실시예에 따르면, 프로세서는, 범위 레지스터의 베이스 비트 및 마스크 비트를 설정한 경우에 응답하여, 범위 레지스터의 밸리드 비트(valid bit) 및 락 비트(lock bit)를 설정할 수 있다.
범위 레지스터의 밸리드 비트는, 범위 레지스터가 커널 코드 청크에 대응하는지 여부에 관한 정보를 가질 수 있다. 범위 레지스터들의 개수가 커널 코드 청크의 개수보다 많은 경우, 범위 레지스터들 중 적어도 하나의 범위 레지스터는 커널 코드 청크에 대응하지 않을 수 있다. 예시적으로, 범위 레지스터들이 4개이고, 커널 코드 청크가 3개인 경우, 범위 레지스터들 중 3개의 범위 레지스터들 각각은 하나의 커널 코드 청크에 대응하고, 범위 레지스터들 중 나머지 1개의 범위 레지스터는 커널 코드 청크에 대응하지 않을 수 있다.
예시적으로, 밸리드 비트는 마스크 비트에 후속하는 1개의 비트일 수 있다. 프로세서는, 커널 코드 청크에 기초하여 범위 레지스터의 베이스 비트, 및 마스크 비트를 설정한 경우에 응답하여, 밸리드 비트의 값을 1로 설정할 수 있다. 프로세서는 커널 코드 청크가 대응하는 범위 레지스터를 설정한 이후, 설정되지 않은 범위 레지스터에 대하여 밸리드 비트의 값을 0으로 설정할 수 있다.
프로세서는 범위 레지스터의 밸리드 비트가 1로 설정된 경우, 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부의 판단에 해당 범위 레지스터를 이용할 수 있다. 범위 레지스터의 밸리드 비트가 0으로 설정된 경우, 프로세서는 해당 범위 레지스터는 커널 코드 청크에 대응하지 않는 것으로 판단할 수 있다. 결과적으로, 프로세서는, 범위 레지스터의 밸리드 비트가 0으로 설정된 경우, 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부의 판단으로부터 해당 범위 레지스터의 이용을 배제할 수 있다.
범위 레지스터의 락 비트는, 범위 레지스터의 설정 완료 여부에 관한 정보를 가질 수 있다. 락 비트는, 한 번 설정되는 비울 수 없는 스티키(sticky) 비트일 수 있다. 예시적으로, 락 비트는 밸리드 비트에 후속하는 1개의 비트일 수 있다. 프로세서는, 머신 모드인 동안, 커널 코드 청크에 기초하여 범위 레지스터의 베이스 비트, 마스크 비트, 및 밸리드 비트를 설정할 수 있다. 프로세서는, 커널 코드 청크에 기초하여 범위 레지스터의 베이스 비트, 마스크 비트, 및 밸리드 비트를 설정한 이후에, 해당 범위 레지스터의 락 비트를 1로 설정할 수 있다. 프로세서는, 범위 레지스터의 락 비트이 1로 설정된 경우, 범위 레지스터에 대한 추가적인 쓰기 동작 및/또는 업데이트 동작을 무시할 수 있다. 프로세서는, 커널 코드 청크가 대응하는 범위 레지스터를 설정한 이후에, 나머지 범위 레지스터에 대하여 밸리드 비트의 값을 0으로 설정한 이후에, 0으로 설정된 밸리드 비트의 범위 레지스터의 락 비트를 1로 설정할 수 있다.
일 실시예에 따른 프로세서는, 범위 레지스터의 락 비트를 통해, 범위 레지스터를 업데이트하기 위한 특별한 명령어들을 실행 가능한 강력한 공격자(attacker)일지라도 이미 설정된 범위 레지스터들을 손상시킬 수 없으므로, 범위 레지스터들에 의하여 결정된 범위들을 변경할 수 없다. 따라서, 일 실시예에 따른 프로세서는 범위 레지스터의 락 비트의 값이 1로 설정된 이후, 해당 범위 레지스터에 대한 추가적인 쓰기 동작 및/또는 업데이트 동작을 무시할 수 있다.
도 5는 일 실시예에 따른 프로세서가 액세스 요청의 가상 주소에 매핑된 물리 주소를 획득하는 동작을 설명하기 위한 도면이다.
일 실시예에 따른 프로세서는, 커널 모드인 동안 가상 주소에 액세스 요청을 수신한 경우에 응답하여, 가상 주소에 대한 페이지 테이블 엔트리를 이용하여 가상 주소에 매핑된 물리 주소를 획득할 수 있다. 가상 주소에 대한 페이지 테이블 엔트리는, 변환 색인 버퍼(translation lookaside buffer; TLB)에 캐시(cache)되어 있을 수 있고, 또는 변환 색인 버퍼에 캐시되어 있지 않을 수도 있다.
단계(510)에서, 프로세서는 변환 색인 버퍼에 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 캐시되어 있는지 여부를 확인할 수 있다. 일 실시예에 따르면, 최근에 이용된 페이지 테이블 엔트리는 변환 색인 버퍼에 캐시되어 있을 수 있다.
도 8에서 후술하겠으나, 일 실시예에 따르면, 프로세서는 페이지 테이블 엔트리는 변환 색인 버퍼에 캐시되는 경우, 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부에 기초하여, 페이지 테이블 엔트리에 대한 페이지 테이블 속성을 업데이트할 수 있다. 프로세서는 업데이트된 페이지 테이블 속성과 함께 페이지 테이블 엔트리를 변환 색인 버퍼에 캐시할 수 있다. 따라서, 일 실시예에 따르면, 프로세서는, 변환 색인 버퍼에 이미 캐시되어 있는 페이지 테이블 엔트리의 페이지 테이블 속성이 커널 코드 영역 판단부의 판단에 기초하여 업데이트된 것으로 취급할 수 있다. 예를 들어, 프로세서는, 변환 색인 버퍼에 캐시된 페이지 테이블 엔트리의 페이지 테이블 속성은 공격자에 의하여 조작되지 않은 것으로 취급할 수 있다.
단계(520)에서, 프로세서는 변환 색인 버퍼에 페이지 테이블 엔트리가 캐시되어 있지 않은 경우에 응답하여, 페이지 테이블로부터 가상 주소에 대한 페이지 테이블 엔트리를 검색할 수 있다. 페이지 테이블 엔트리는, 가상 주소 및 가상 주소에 매핑된 물리 주소를 가질 수 있다. 프로세서는, 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 변환 색인 버퍼에 캐시되어 있지 않은 것을 확인할 수 있다. 프로세서는, 액세스 요청의 가상 주소에 기초하여, 페이지 테이블로부터 가상 주소에 대한 페이지 테이블 엔트리를 검색할 수 있다.
단계(530)에서, 프로세서는 검색된 페이지 테이블 엔트리에 기초하여, 가상 주소에 매핑된 페이지의 물리 주소를 획득할 수 있다.
단계(540)에서, 프로세서는 변환 색인 버퍼에 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 변환 색인 버퍼에 캐시된 페이지 테이블 엔트리에 기초하여 페이지의 물리 주소를 획득할 수 있다.
도 6는 일 실시예에 따른 프로세서가 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하는 동작을 설명하기 위한 도면이다.
단계(610)에서, 프로세서는 범위 레지스터의 마스크 비트에 기초하여, 물리 주소 중 부분 주소를 결정할 수 있다. 부분 주소는, 물리 주소 중에서 범위 레지스터와 비교할 부분 주소를 의미할 수 있다. 예를 들어, 물리 주소는 32개의 비트들로 표현될 수 있다. 범위 레지스터의 마스크 비트가 1111000000(2)의 값으로 설정된 경우, 프로세서는 물리 주소 중에서, 미리 결정된 개수(예: 8개)에 마스크 비트에 의하여 결정된 개수(예: 4개)가 합산된 개수(예: 12개)의 상위 비트들을 부분 주소로 결정할 수 있다.
단계(620)에서, 프로세서는, 결정된 부분 주소가 범위 레지스터의 베이스 비트의 적어도 일부에 매칭되는 경우에 응답하여, 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 것을 판단할 수 있다. 프로세서는 물리 주소에 저장된 코드가 커널 코드인 것을 판단할 수 있다.
예시적으로, 범위 레지스터의 베이스 비트의 값은 14 비트들만큼 왼쪽으로 시프팅된 후에 커널 코드 청크의 시작 물리 주소로서 이용될 수 있다. 범위 레지스터의 마스크 비트의 값은 14비트들만큼 왼쪽으로 시프팅될 수 있고, 마스크 값을 구성하기 위해 마스크 비트의 값에 선행하는 미리 결정된 개수의 비트들이 1로 설정되어 추가(prepend)될 수 있다. 예시적으로, 프로세서는 물리 주소(addr)에 대응하는 영역은 수학식 1에 따라 커널 코드 영역에 포함되는지 여부를 판단할 수 있다.
[수학식 1]
Figure PCTKR2023007599-appb-img-000001
프로세서는, 물리 주소(addr)가 수학식 1을 만족하는 경우, 물리 주소에 대응하는 영역이 범위 레지스터가 대응하는 커널 코드 영역에 포함되는 것을 결정할 수 있다. 프로세서는, 물리 주소(addr)가 수학식 1을 만족하지 않는 경우, 물리 주소에 대응하는 영역이 범위 레지스터가 대응하는 커널 코드 영역에 포함되지 않는 것을 결정할 수 있다.
도 7는 일 실시예에 따른 프로세서가 물리 주소에 대응하는 영역에 대한 동작의 인에이블 또는 디스에이블 여부를 결정하는 동작을 설명하기 위한 도면이다.
단계(710)에서, 프로세서는 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 물리 주소에 대응하는 영역에 대한 쓰기 동작(write operation)을 디스에이블할 수 있다.
예를 들어, 프로세서는, 물리 주소에 대응하는 영역에 대한 커널 모드의 쓰기 동작을 디스에이블할 수 있다. 프로세서는 페이지 테이블 엔트리의 페이지 테이블 속성의 sw 비트를 0으로 설정함으로써, 커널 모드인 동안 물리 주소에 대응하는 영역에 대한 쓰기 동작을 제한할 수 있다.
예를 들어, 프로세서는, 물리 주소에 대응하는 영역에 대한 사용자 모드의 쓰기 동작을 디스에이블할 수 있다. 프로세서는 페이지 테이블 엔트리의 페이지 테이블 속성의 w 비트를 0으로 설정함으로써, 사용자 모드인 동안 물리 주소에 대응하는 영역에 대한 쓰기 동작을 제한할 수 있다.
비교 실시예에 따르면, 커널 코드 영역에 대한 쓰기 동작이 인에이블되는 경우, 공격자는 커널 코드 영역에 악성 코드를 저장할 수 있다. 커널 코드 영역에 악성 코드가 저장되면, 프로세서가 커널 모드인 동안 커널 코드 영역에 저장된 악성 코드를 실행할 수도 있다. 이와 달리, 일 실시예에 따르면, 프로세서는 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우, 물리 주소에 대응하는 영역에 대한 쓰기 동작을 디스에이블함으로써, 공격자에 의하여 커널 코드 영역에 커널 코드와 다른 코드(예: 악성 코드)가 저장되는 것을 방지할 수 있다.
단계(720)에서, 프로세서는 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 커널 모드인 동안 물리 주소에 대응하는 영역에 대한 실행 동작(execute operation)을 인에이블할 수 있다.
예를 들어, 프로세서는, 물리 주소에 대응하는 영역에 대한 커널 모드의 실행 동작을 인에이블할 수 있다. 프로세서는 페이지 테이블 엔트리의 페이지 테이블 속성의 sx 비트를 1로 설정함으로써, 커널 모드인 동안 물리 주소에 대응하는 영역에 대한 실행 동작을 허용할 수 있다.
단계(730)에서, 프로세서는 획득된 물리 주소에 대응하는 영역이 커널 코드 영역과 다른 영역에 포함되는 경우에 응답하여, 커널 모드인 동안 물리 주소에 대응하는 영역에 대한 실행 동작을 디스에이블할 수 있다.
예를 들어, 프로세서는, 물리 주소에 대응하는 영역에 대한 커널 모드의 실행 동작을 디스에이블할 수 있다. 프로세서는 페이지 테이블 엔트리의 페이지 테이블 속성의 x 비트를 0으로 설정함으로써, 커널 모드인 동안 물리 주소에 대응하는 영역에 대한 실행 동작을 제한할 수 있다.
비교 실시예에 따르면, 공격자는 커널 코드와 다른 코드(예: 악성 코드)를 메모리의 일부 영역에 저장할 수 있다. 공격자는, 다른 코드가 저장된 일부 영역에 대한 커널 모드의 실행 동작을 인에이블할 수 있다. 다시 말해, 공격자는, 다른 코드를 메모리의 일부 영역에 저장하고, 프로세서가 메모리의 일부 영역을 커널 코드 영역으로 인식하도록 조작할 수 있다. 비교 실시예에 따른 프로세서는, 커널 모드인 동안 일부 영역에 저장된 악성 코드를 실행할 수도 있다. 이와 달리, 일 실시예에 따르면, 프로세서는 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되지 않는 경우, 물리 주소에 대응하는 영역에 대한 커널 모드의 실행 동작을 디스에이블함으로써, 커널 모드인 동안 다른 코드(예: 악성 코드)를 실행하는 것을 방지할 수 있다.
단계(740)에서, 프로세서는 페이지 테이블 엔트리의 페이지 테이블 속성과 독립적으로, 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다. 가상 주소에 대한 페이지 테이블 엔트리는, 페이지 테이블 속성을 가질 수 있다. 전술한 바와 같이, 페이지 테이블 속성은, 페이지 테이블 엔트리의 물리 주소에 대응하는 영역에 대하여 커널 모드의 쓰기 동작, 사용자 모드의 쓰기 동작, 커널 모드의 실행 동작, 또는 사용자 모드의 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부에 관한 정보를 포함할 수 있다.
일 실시예에 따른 프로세서는, 공격자에 의한 페이지 테이블 속성의 조작으로 인하여, 물리 주소에 대응하는 영역에 인에이블되어야 하는 동작을 디스에이블한 것으로 또는 디스에이블되어야 하는 동작을 인에이블한 것으로 속는 것을 방지할 수 있다.
예를 들어, 공격자는 커널 코드가 저장된 커널 코드 영역에 대하여 쓰기 동작이 디스에이블되어야 함에도 불구하고, 인에이블된 것으로 조작할 수 있다. 공격자는 커널 코드 영역에 대한 페이지 테이블 엔트리의 페이지 테이블 속성에서, w 비트 또는 sw 비트 중 적어도 하나의 비트를 1로 조작할 수 있다. 예를 들어, 공격자는 커널 코드 영역과 다른 영역에 대하여 실행 동작이 디스에이블되어야 함에도 불구하고, 인에이블된 것으로 조작할 수 있다. 예시적으로, 공격자는 커널 코드 영역과 다른 영역에 대한 페이지 테이블 엔트리의 페이지 테이블 속성에서, sx 비트를 1로 조작할 수 있다.
비교 실시예에 따르면, 프로세서는, 물리 주소에 대응하는 영역에 대한 쓰기 동작 및/또는 실행 동작의 인에이블 또는 디스에이블 여부를 페이지 테이블 속성에 기초하여 결정할 수 있다. 결과적으로, 공격자가 페이지 테이블 속성을 조작한 경우, 비교 실시예에 따른 프로세서는 조작된 페이지 테이블 속성에 기초하여 쓰기 동작 및/또는 실행 동작의 인에이블 또는 디스에이블 여부를 결정할 수 있다. 이와 달리, 일 실시예에 따른 프로세서는, 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하고, 판단 결과에 기초하여 물리 주소에 대응하는 영역에 대한 쓰기 동작 및/또는 실행 동작의 인에이블 또는 디스에이블 여부를 결정할 수 있다. 결과적으로, 공격자가 페이지 테이블 속성을 조작한 경우에도, 일 실시예에 따른 프로세서는, 커널 코드 영역에 포함 여부의 판단 결과에 따라 올바른 동작의 인에이블 또는 디스에이블 여부를 결정할 수 잇다.
도 8은 일 실시예에 따른 프로세서가 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 변환 색인 버퍼에 캐시되어 있지 않은 경우 페이지 테이블 속성을 업데이트하는 동작을 설명하기 위한 도면이다.
일 실시예에 따르면, 전술한 바와 같이, 프로세서는 페이지 테이블 엔트리의 페이지 테이블 속성과 독립적으로, 물리 주소에 대응하는 영역에 대한 동작(예: 쓰기 동작, 실행 동작)의 인에이블 또는 디스에이블 여부를 결정할 수 있다. 프로세서는, 결정된 동작의 인에이블 또는 디스에이블 여부에 따라 페이지 테이블 속성을 설정할 수 있다.
단계(810)에서, 프로세서는 결정된 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부에 기초하여, 페이지 테이블 엔트리의 페이지 테이블 속성을 업데이트할 수 있다. 본 명세서에서, 페이지 테이블 엔트리의 페이지 테이블 속성을 업데이트하는 것은, 페이지 테이블 속성(또는 페이지 테이블 엔트리)을 소독(sanitize)하는 것으로도 표현될 수 있다.
예를 들어, 프로세서는 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 것을 결정할 수 있다. 프로세서는, 물리 주소에 대응하는 영역에 대한 커널 모드의 쓰기 동작 및 사용자 모드의 쓰기 동작을 디스에이블할 수 있다. 프로세서는, 물리 주소에 대응하는 영역에 대한 커널 모드의 실행 동작을 인에이블할 수 있다. 프로세서는, 페이지 테이블 속성의 sw 비트 및 w 비트를 0으로 업데이트할 수 있다. 프로세서는, 페이지 테이블 속성의 sx 비트를 1로 업데이트할 수 있다.
예를 들어, 프로세서는 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되지 않는 것을 결정할 수 있다. 프로세서는, 물리 주소에 대응하는 영역에 대한 커널 모드의 실행 동작을 디스에이블할 수 있다. 프로세서는, 페이지 테이블 속성의 sw 비트 및 w 비트를 1로 업데이트할 수 있다. 프로세서는, 페이지 테이블 속성의 sx 비트를 0으로 업데이트할 수 있다.
일 실시예에 따르면, 프로세서는 공격자가 물리 주소에 대응하는 영역의 페이지 테이블 속성을 조작한 경우에도, 페이지 테이블 속성과 독립적으로 결정된 동작의 인에이블 또는 디스에이블 여부에 기초하여 페이지 테이블 속성을 업데이트함으로써, 페이지 테이블 속성을 참 값으로 유지할 수 있다.
단계(820)에서, 프로세서는 업데이트된 페이지 테이블 속성을 페이지 테이블 엔트리와 함께 변환 색인 버퍼에 캐시할 수 있다. 일 실시예에 따르면, 프로세서는, 최근에 검색된 페이지 테이블 엔트리를 변환 색인 버퍼에 캐시하는 정책을 이용할 수 있다. 이후, 프로세서는 변환 색인 버퍼에 캐시되어 있는 페이지 테이블 엔트리의 페이지 테이블 속성은 프로세서(예: 커널 코드 영역 판단부)에 의하여 업데이트된 페이지 테이블 속성일 수 있다.
도 9은 일 실시예에 따른 프로세서가 액세스 요청의 가상 주소에 대한 페이지 테이블 엔트리가 변환 색인 버퍼에 캐시되어 있는 경우 페이지 테이블 속성을 업데이트하는 동작을 설명하기 위한 도면이다.
일 실시예에 따르면, 전술한 바와 같이, 프로세서는 프로세서(예: 커널 코드 영역 판단부)에 의하여 업데이트된 페이지 테이블 속성을 변환 색인 버퍼에 캐시할 수 있다. 결과적으로, 프로세서는, 변환 색인 버퍼에 캐시되어 있는 페이지 테이블 엔트리의 페이지 테이블 속성에 대하여, 커널 코드 영역의 포함 여부 판단 및/또는 동작에 대한 인에이블 또는 디스에이블 여부의 결정을 수행하지 않더라도, 해당 페이지 테이블 속성은 공격자의 조작되지 않은 것으로 취급할 수 있다.
단계(910)에서, 프로세서는 변환 색인 버퍼에 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 설정된 범위 레지스터와 획득된 물리 주소의 비교를 생략할 수 있다.
단계(920)에서, 프로세서는 페이지 테이블 엔트리의 페이지 테이블 속성에 기초하여 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정할 수 있다.
일 실시예에 따르면, 프로세서는 변환 색인 버퍼에 페이지 테이블 엔트리가 캐시되어 있는 경우, 페이지 테이블 속성은 공격자의 조작되지 않은 것으로 취급할 수 있다. 프로세서는, 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하지 않더라도, 신뢰할 수 있는 페이지 테이블 속성에 포함된 동작의 인에이블 또는 디스에이블 여부를 결정할 수 있다.
일 실시예에 따른 프로세서는, 메모리에 대한 액세스 요청에 대하여, 동작의 인에이블 또는 디스에이블 여부를 주소 변환 후에 또는 주소 변환과 함께 검사할 수 있다. 다시 말해, 일 실시예에 따른 프로세서는, 페이지 테이블을 사용하여 주소를 변환하는 가상 주소 기반 메커니즘과 유사하게, 프로세서가 메모리에 액세스하는 데 사용하는 정확한 물리 주소에 기초하여 동작의 인에이블 또는 디스에이블 여부를 결정할 수 있다. 그렇지 않은 경우, 공격자는 특정 페이지 테이블 엔트리를 조작하여 검사를 우회하고 커널 코드 페이지를 실행하거나 손상시킬 수 있다.
일 실시예에 따른 프로세서는, 메모리에 대한 액세스 요청에 대하여, 캐시 액세스 전에 검사할 수 있다. 일 실시예에 따른 프로세서는 커널 코드 무결성을 보호하는 것을 목표로 하며, 커널 코드의 무결성을 위하여, 커널 코드를 저장하는 커널 코드 영역에 대한 쓰기 동작의 제한뿐만 아니라, 커널 모드인 동안 커널 코드 영역과 다른 영역에 저장된 다른 코드(예: 외부 코드)에 대한 실행 동작도 함께 제한되어야 할 수 있다. 프로세서는 일반적으로 커널 모드에 들어갈 때 캐시를 플러시하지 않으므로, 캐시는 사용자 프로그램에 대한 일부 코드가 포함될 수 있다. 추가 보안 메커니즘이 캐시 외부의 메모리 액세스를 검사하는 경우, 공격자는 커널이 캐시된 사용자 프로그램으로 점프하도록 함으로써 메커니즘을 우회할 수 있다. 이러한 코드가 커널의 권한으로 프로세서가 커널 모드인 동안 실행되는 것을 방지하기 위하여, 프로세서 코어와 캐시 간의 페이지 테이블 속성은 검사될 수 있다.
일 실시예에 따른 프로세서는, 주소 변환과 L1 캐시 액세스 간의 새로운 하드웨어 로직을 배제할 수 있다. 물리 주소를 검사하는 로직을 추가하는 것은, 필연적으로 게이트 및 와이어 지연을 증가시키고, 잠재적으로 다른 파이프라인 단계를 도입할 수 있다. 그 결과, 상당한 성능 저하가 발생될 수 있다. 예를 들어, Rocket Chip Generator의 PMP 구현은, 물리 주소를 검사하는 위치에 로직을 추가하지 않기 위하여 노력할 수 있다. 전술한 바와 같이, 일 실시예에 따른 프로세서는 MMU 또는 L1 캐시 대신에, 페이지 테이블 워커를 확장함으로써 로직을 추가하지 않을 수 있다.
결과적으로, 일 실시예에 따른 프로세서는, 메모리 액세스에 대하여 주소 변환과 함께 MMU에 의해 업데이트된 TLB 엔트리를 사용하여 검사될 수 있다. MMU는 주소 변환을 위한 프로세서 코어 및 캐시 사이에 놓여있어서, 모든 액세스 요청들은 캐시에서 메모리 접근 TLB 히트가 될지라도 일 실시예에 따른 프로세서의 정책을 위반하면 보호 위반(protection fault)를 유발할 수 있다. MMU 및 L1 캐시 사이에 새로운 하드웨어를 추가하지 않고도, 오로지 페이지 테이블 워커에 추가적인 하드웨어만을 추가함으로써 변형 없는 MMU가 활용될 수 있다.
일 실시예에 따른 프로세서는, 페이지 테이블 엔트리의 페이지 테이블 속성을 검사하기 위한 기존 하드웨어 로직의 이점을 활용함으로써, TLB 미스마다 페이지 테이블 엔트리(또는 페이지 테이블 엔트리의 페이지 테이블 속성)를 업데이트(예: 소독)함으로써 원하는 정책을 시행할 수 있다.
일 실시예에 따른 프로세서는, 운영 체제 커널이 변경되는 것이 요구될 수 있다. 예를 들어, 페이지 오류 핸들러에 대한 변경이 요구될 수 있다. 컴퓨팅 시스템들에서, 페이지 오류들은 요청 페이징(demand paging)의 과정에서, 정기적으로 발생할 수 있다. 추가 가상 페이지에 대한 어플리케이션의 요청들은 가상 페이지와 함께 먼저 제공되고, 물리적 페이지는 페이지가 터치될 때 프로비저닝(provision)될 수 있다.
여기에서, TLB가 인식하고 운영 체제 커널이 핸들링하는 페이지 오류가 포함될 수 있다. 페이지 폴트 후, 어플리케이션은 페이지 폴트를 유발한 명령어로부터 실행을 재개할 수 있다. 일 실시예에 따른 프로세서를 사용하기 위하여, 커널 코드 페이지에 대한 쓰기가 동일한 페이지 폴트를 유발하기 때문에, 페이지 폴트 핸들링 절차가 업데이트되어야 할 수 있다. 커널이 쓰기 가능한 가상 페이지를 커널 코드 페이지에 매핑하고 이에 쓰는 경우, 일 실시예에 따른 프로세서는 TLB 미스 시 페이지 테이블 속성을 업데이트하고 액세스가 거부되도록 유발할 수 있다. 커널이 이 오류를 핸들링하는 동안, 페이지가 쓰기 가능한지 확인한 후 오류가 처리된 것으로 간주하고 오류가 발생한 명령에서 실행을 재개할 수 있다. 그러나, 페이지 테이블 엔트리에 페이지가 쓰기 가능하다고 표시되어 있음에도, 일 실시예에 따른 프로세서가 페이지 테이블 엔트리를 다시 삭제하기 때문에 동일한 보호 오류가 다시 발생할 수 있다.
페이지 오류를 유발한 가상 주소가 커널 코드 페이지 내의 물리적 주소를 가리키는지를 커널이 확인하도록 페이지 오류 핸들러가 조정될 수 있다. 커널은 가상 주소에 대응하는 페이지 테이블 엔트리가 유효한 경우 일 실시예에 따른 프로세서의 커널 코드 페이지 보호에 의해 페이지 폴트가 발생한 것으로 판단할 수 있고, 액세스는 페이지 속성을 위반하지 않으며, 진입점은 커널 코드 페이지를 가리킬 수 있다. 커널은 보안 정책에 따라 오류를 일으킨 프로세스를 종료하거나 쓰기를 조용히 무시할 수 있다.
이하, 일 실시예에 따른 프로세서의 성능을 비교 실시예에 따른 프로세서와 비교함으로써 설명한다.
일 실시예에 따른 프로세서는, 예시적으로, Freedom U500 Dev Kit의 Rocket Chip Generator를 확장함으로써 구현될 수 있고, 일 실시예에 따른 프로세서가 성능, 에너지 소비, 칩 면적 및 임계 경로 지연(critical path latency)에 미치는 영향은 Xilinx VCU118 평가 키트를 사용하여 측정될 수 있다. 어플리케이션(예: Beebs 및 SPEC CPU 2006) 및 운영 체제 커널 벤치마크들을 이용한 실험들에서, 일 실시예에 따른 프로세서는 어플리케이션(<0.5%) 및 운영 체제(<3%) 성능에 낮은 영향을 미칠 수 있다. 칩 면적(0.13%) 및 에너지 소비(<2%) 측면에서 비용도 낮고, 임계 경로 지연을 증가시키지 않을 수 있다.
Rocket Chip Generator가 확장됨으로써 일 실시예에 따른 프로세서(PRIVLOCK)가 구현될 수 있고 Freedom U500 V707 FPGA 개발 키트를 통해 FPGA에서 시스템이 평가될 수 있다. 특히 Xilinx VCU118 평가 키트용으로 개발 키트의 포트가 사용될 수 있다. 예시적으로, 커밋 ID는 943ab4ac2cefbbabdeda9447ec0f6231f6235f1e일 수 있다. Rocket Chip의 구성으로, 4개의 RockerTile들을 가지는 U500 플랫폼에 대한 기본값(default)가 사용될 수 있고, 각각의 RockerTiles은 하나의 Rocket 코어, 16KB의 L1 데이터 캐시, 및 16KB의 L1 명령어 캐시를 포함할 수 있다. 예를 들어, 커널 프로그램 및 사용자 프로그램을 컴파일하기 위해 RISC-V 프로세서용 GNU 툴체인이 사용될 수 있고, 커밋 ID는 b4dae89f85bf882852c6186b1284df11065bfcd9일 수 있다. 프로토타입은 2GB의 외부 메모리로 실행되고 100MHz에서 작동하며 Linux 커널 버전 4.15.0을 실행할 수 있다. 프로토타입은 U500 플랫폼에서 수정되지 않은 Rocket Chip의 기본(default) 구성을 따라 100MHz에서 작동하도록 구성될 수 있다.
도 10은 일 실시예에 따른 프로세서 및 비교 실시예에 따른 프로세서의 성능을 LMBench를 이용하여 측정한 결과를 설명하기 위한 도면이다.
도 10에 나타난 바와 같이, 일 실시예에 따른 프로세서(PRIVLOCK)의 성능 오버헤드는 눈에 띄지 않을 수 있다. 보호 오류는 약 30% 정도 느려지지만 애플리케이션 벤치마크에서 볼 수 있듯이 간헐적 작동이기 때문에 시스템 성능에 크게 영향을 미치지 않을 수 있다. 모든 벤치마크에 대해 4가지 이전 작업들의 오버헤드는, 결과가 보고되지 않았기 때문에, 표시할 수 없었을 수 있다.
일 실시예에 따른 프로세서(PRIVLOCK)은, 전술한 바와 같이, 운영 체제 커널의 페이지 오류 핸들러를 계측할 수 있다. 따라서, 추가적인 체크가 메모리 관리 동작들 및 관련 운영 체제 서비스들의 성능에 영향을 미칠 가능성이 있다. 널리 사용되는 LMBench를 통해 일 실시예에 따른 프로세서(PRIVLOCK)이 운영 체제 성능에 미치는 잠재적 영향이 측정될 수 있다. 그림 3은 유사한 보안 보장을 제공하는 비교 실시예들에 따른 프로세서의 오버헤드와 함께 결과를 보여줄 수 있다. 예상대로, 일 실시예에 따른 프로세서(PRIVLOCK)은 운영 체제 성능도 또한 저하시키지 않을 수 있다. 참고로, 후술하겠으나, 보호 오류(protection fault)의 30% 오버헤드는 대부분의 어플리케이션들에서 눈에 띄지 않을 수 있다. 프로그램은 일반적으로 보호 오류 수를 줄이기 위해 최적화되어 있기 때문일 수 있다.
도 10에서, 비교 실시예들에 따른 프로세서에서 보고된 성능 효과가 나타날 수 있다. 일 실시예에 따른 프로세서(PRIVLOCK)의 오버헤드는 소프트웨어 전용 메커니즘(SecVisor 및 Nested Kernel)보다 상당히 낮고 하드웨어 지원 메커니즘(Kargos 및 RiskiM)과 유사할 수 있다. LMBench로 평가된 커널 코드 무결성을 보장하는 두 가지 소프트웨어 전용 메커니즘인 SecVisor 및 Nested Kernel은 각각 최대 10배 및 3배의 오버헤드를 가질 수 있다. 이것은 일 실시예에 따른 프로세서(PRIVLOCK)의 오버헤드보다 훨씬 클 수 있다. Kargos 및 RiskiM 커널 코드 무결성 위반을 감지할 수 있는 하드웨어 지원 메커니즘입니다. 둘 다(각각 약 3% 및 30%) 일 실시예에 따른 프로세서(PRIVLOCK)과 비교하여 유사하거나 더 나은 성능 오버헤드를 가질 수 있다.
소프트웨어 전용 메커니즘과 비교하여 일 실시예에 따른 프로세서(PRIVLOCK)의 잠재적인 이점을 강조하기 위해, 일 실시예에 따른 프로세서(PRIVLOCK)의 컨텍스트 전환 오버헤드는 에뮬레이트된 소프트웨어 전용 보호와 비교될 수 있다. 페이지 테이블 무결성의 확정적인 소프트웨어 전용 보호는 각 컨텍스트 스위치에서 새로 사용된 페이지 테이블들의 소독(sanitization)를 요구하고, 컨텍스트 스위치 대기 시간을 증가시킬 수 있다. 16개의 페이지 테이블들을 포함하는 모든 컨텍스트 스위치에서 16페이지(64KB)를 읽도록 커널은 계측되고 소프트웨어 전용 메커니즘이 에뮬레이트될 수 있다.
표 1은 LMBench로 측정된 컨텍스트 스위치 대기 시간의 결과를 나타낼 수 있다.
[표 1]
Figure PCTKR2023007599-appb-img-000002
각 컨텍스트 스위치에서 확인해야 하는 페이지 수는 항상 16보다 크므로, 실험에서 16페이지를 조사하는 것이 선택될 수 있다. 따라서 최소 예상 오버헤드가 제시된 수에 반영될 수 있다. 모든 컨텍스트 스위치마다, 새 페이지 테이블에서 유효한 모든 페이지 테이블 엔트리들을 검사해야 할 수 있고, 페이지 테이블이 데이터 페이지를 포함하여 64MB 이상의 메모리를 매핑하는 경우 페이지 테이블은 유효한 페이지 테이블 엔트리를 포함하는 적어도 16페이지들을 가져야 할 수 있다. 결과에서 나타난 바와 같이, 커널이 수행하는 추가 체크는 일 실시예에 따른 프로세서(PRIVLOCK)과 비교하여 컨텍스트 스위치들의 속도를 크게 저하시킬 수 있다.
도 11은 일 실시예에 따른 비교 실시예에 따른 프로세서를 가지는 시스템의 실행 시간으로 정규화된 일 실시예에 따른 프로세서를 가지는 시스템의 워크로드의 실행 시간을 도시한다.
많은 수의 페이지 폴트들을 유발하지 않는 어플리케이션들의 경우, 일 실시예에 따른 프로세서(PRIVLOCK)가 성능 저하를 유발하지 않을 것이 예상될 수 있다. 후술하겠으나, 추가 하드웨어는 소개할 페이지 테이블 워커에서 일부 경로들의 대기 시간을 증가시킬 수 있고, 주기 측면에서 작업의 대기 시간을 증가시키지 않을 수 있다. 첫 번째 어플리케이션 성능 연구에서, MiBench, WCET 벤치마크 및 DSPStone로부터 파생된 임베디드 시스템들을 평가하기 위하여 설계된 벤치마크 제품군(benchmark suite)인 Bristol/Embecosm Embedded Benchmark Suite(Beebs)[39]가 사용될 수 있다. 나머지 2개의 워크로드들은 메모리 안전 버그들을 가지는 것으로 확인되어 실행되지 않기 때문에, 제품군에서 80개의 워크로드들 중 78개가 실행될 수 있다. 도 11은 일 실시예에 따른 프로세서(PRIVLOCK)이 활성화된 경우 일 실시예에 따른 프로세서(PRIVLOCK)이 없는 시스템의 실행 시간으로 정규화된 각 워크로드의 실행 시간을 나타낼 수 있다. 각 워크로드는 10번 실행되고, 평균이 계산되고, 정규화된 실행 시간이 계산될 수 있다. 예상된 대로, 성능 오버헤드는 눈에 띄지 않을 수 있고, 0.5% 범위 내에서 유지되며, 기하 평균에서는 0.3% 미만일 수 있다.
도 12는 일 실시예에 따른 SPEC 2006 벤치마크 제품군의 12개의 워크로드들의 정규화된 실행 시간을 도시한다.
일 실시예에 따른 프로세서(PRIVLOCK)의 보호 하에 있는 중요하지 않은 대규모 프로그램의 성능을 평가하기 위하여, SPEC 2006 벤치마크 제품군이 이용될 수 있다. 프로토타입의 제한된 컴퓨팅 성능과 파일 시스템 크기 때문에, 최신 버전인 SPEC 2017을 실행할 수 없을 수 있다. 같은 이유로, 보다 더 큰 ref 입력보다 작은 traininput이 이용될 수 있다. 도 12에서 나타난 바와 같이, 일 실시예에 따른 프로세서(PRIVLOCK)이 있는 시스템은 성능 오버헤드가 거의 0(예: -0.07%)인 사소하지 않은 프로그램을 실행할 수 있다.
표 2는 일 실시예에 따른 프로세서의 칩 영역(chip area)에 대한 영향(impact)를 설명한다.
[표 2]
Figure PCTKR2023007599-appb-img-000003
일 실시예에 따른 프로세서(PRIVLOCK)은 추가 하드웨어 리소스의 이점을 활용하기 때문에, 상당한 성능 저하 없이 추가 보안 보장을 제공합니다. 일 실시예에 따른 프로세서(PRIVLOCK)은, 이러한 추가 구성 요소가 없었으면, 페이지 테이블 컨텐츠를 확인하기 위해 더 많은 CPU 명령어들을 실행하고 더 높은 성능 오버헤드를 가졌을 수 있다. 추가 자원의 비용은 여러 가지 방법으로 평가될 수 있다. ASIC(Application Specific Integrated Circuit) 흐름과 FPGA 활용에 따른 칩 면적이 측정될 수 있다. 에너지 소비의 잠재적 비용은 FPGA에서 실행 중인 프로토타입과 구현된 디자인의 예상 전력 소비를 추정하는 Vivado Design Suite의 기능 모두에 의해 측정될 수 있다.
일 실시예에 따른 프로세서(PRIVLOCK)을 가지는 시스템이 ASIC으로 구현될 때, 칩 면적의 추정을 계산하기 위하여 Yosys 오픈 합성 제품군(Yosys)이 사용될 수 있다. 셀 라이브러리에서, FreePDK45[48]에 포함된 무료로 사용 가능한 라이브러리가 사용될 수 있다. 표 2는 관심 있는 여러 하드웨어 구성 요소들의 추정에 따라 상위 모듈과 전체 시스템의 면적 추정을 나타낼 수 있다. 전반적으로, 일 실시예에 따른 프로세서(PRIVLOCK)이 4개의 범위 레지스터들을 가질 때, 면적 비용은 0.13%에 불과할 수 있다. 4개의 범위 레지스터들을 가지는 일 실시예에 따른 프로세서(PRIVLOCK)은 성능 및 보안 평가에 사용될 수 있다. 표 2는 대부분의 면적 비용이 Rocket 코어 아래 CSRFile의 추가 레지스터들과 페이지 테이블 워커(PTW)의 커널 코드 영역 판단부(PRIVLOCKCHECKER)에서 발생하는 것을 나타낼 수 있다. 숫자에서 알 수 있듯이, 일 실시예에 따른 프로세서(PRIVLOCK)을 구현한 시스템은 주변 장치가 거의 없을 수 있다. 4개의 RocketTiles은 대부분의 칩 면적을 차지할 수 있다. 실제로, 시스템에 훨씬 더 많은 주변 장치가 있을 것으로 예상될 수 있으므로, 일 실시예에 따른 프로세서(PRIVLOCK)의 상대적 면적 비용을 훨씬 더 적게 만들 수 있다.
표 3은 일 실시예에 따른 프로세서의 임계 경로 지연(critical path latency)을 설명한다.
[표 3]
Figure PCTKR2023007599-appb-img-000004
칩 면적 외에도, 일 실시예에 따른 프로세서(PRIVLOCK)이 임계 경로 지연을 크게 증가시키고 지연 제약을 완화시키는지 알아보기 위하여, 일부 관련 모듈들의 임계 경로 지연은 수집되고 비교될 수 있다. 표 3은 관련 모듈들의 임계 경로 지연을 나타낸다. 테스트된 모든 구성들에서, 일 실시예에 따른 프로세서(PRIVLOCK)은 베이스라인(baseline) 시스템이 충족하는 지연 제약 조건 2500ps를 위반하지 않을 수 있다. 관련 모듈의 임계 경로도 크게 증가하지 않을 수 있다.
표 4는 일 실시예에 따른 프로세서의 FPGA 리소스 활용(FPGA Resource Utilization)을 설명한다.
[표 4]
Figure PCTKR2023007599-appb-img-000005
잠재적인 면적 비용에 대한 또 다른 추정으로서, 추정된 칩 면적 외에 FPGA 활용에 대한 일 실시예에 따른 프로세서(PRIVLOCK)의 영향이 제시될 수 있다. 표 4는 자원 활용 측면에서도 FPGA에서 구현될 때, 일 실시예에 따른 프로세서(PRIVLOCK)의 면적 비용이 작은(<3%) 것을 나타낼 수 있다.
도 13은 일 실시예에 따른 프로세서의 정규화된 추가적인 에너지 소모를 설명하기 위한 도면이다.
표 5는 일 실시예에 따른 프로세서의 추가적인 에너지 소모를 평가하기 위하여 이용된 각 세트의 구성(composition)을 설명한다.
표 6은 일 실시예에 따른 프로세서의 FPGA 구현되는 경우 추정된 전력 소모를 설명한다.
[표 5]
Figure PCTKR2023007599-appb-img-000006
[표 6]
Figure PCTKR2023007599-appb-img-000007
추가 하드웨어 구성 요소들은, 시스템이 실행되는 동안 추가 에너지를 소비할 수 있다. 두 가지 방법을 통해 에너지 소비의 예상 비용은 추정될 수 있다. 일 실시예에 따른 프로세서(PRIVLOCK)을 사용하여 FPGA 구현 시스템에서 Beebs 벤치마크 제품군의 하위 집합을 실행하는 동안 에너지 소비가 측정될 수 있다.
폴링(polling) 기반 전력 측정의 제한된 세분성으로 인해, 워크로드 세트의 에너지 소비가 측정될 수 있다. 표 5는 각 세트에 포함된 워크로드를 설명할 수 있다. 결과(예: 기하학적 평균에서 1.87%)는 일 실시예에 따른 프로세서(PRIVLOCK)에 대해 새로 추가된 하드웨어 구성 요소들이 상당한 에너지 오버헤드를 유발하지 않음이 시사될 수 있다. FPGA에서 측정을 보완하기 위한 또 다른 측정으로, 시스템이 FPGA에서 구현될 때, 예상되는 전력 소비를 획득하기 위해 Xilinx Vivado[57]의 빌트인 전력 추정 기능이 사용될 수 있다. 표 6은 에너지 측정의 결론과 유사하게 추가 전력 소비가 작을 것(<1%)으로 예상되는 것을 보여줄 수 있다.
커널 코드 무결성을 변조하는 가능한 공격을 보여주는 세 가지 합성 공격들이 구현될 수 있고, 일 실시예에 따른 프로세서(PRIVLOCK)은 모든 합성 공격들을 성공적으로 방지할 수 있다.
첫 번째 공격은, 쓰기가 불법으로 인식되는지 확인하기 위하여, 커널 코드 페이지 중 하나에 대한 쓰기 액세스를 만들 수 있다. 이 공격은, 기존의 메커니즘이 전통적인 페이지 테이블 기반 보호를 사용하여 어려움 없이 방지할 수 있지만, 커널 코드 페이지가 기본적으로 쓰기 가능하도록 구성되어 있기 때문에 테스트된 시스템에서 공격이 성공할 수 있다. 이러한 페이지 테이블 속성들의 부족과 관계없이, 일 실시예에 따른 프로세서(PRIVLOCK)이 인에이블링될 때 공격이 중지되고 커널에 보호 오류가 발생할 수 있다.
두 번째는 공격자가 악성 코드를 커널 데이터 페이지에 저장하고 실행을 시도하는 시나리오에 대하여 작성될 수 있다. 공격자는 코드가 포함된 페이지를 준비할 뿐만 아니라 대응하는 페이지 테이블 엔트리들을 조작하여 프로세스가 특권 모드(privileged mode)에서 동작하는 동안 페이지를 실행 가능하게 만들어야 할 수 있다. 이 절차는 성공적으로 구현될 수 있고, 보호되지 않은 시스템은 공격을 감지하지 못할 수 있다. 첫 번째 작업과 달리, 커널은 이전 작업에서 제안한 것처럼 페이지 테이블들의 직접적인 조작을 포함하는 절차를 방지할 수 없을 수 있다. 일 실시예에 따른 프로세서(PRIVLOCK)은 이러한 행위를 검출하도록 설계되지 않았지만, 프로세서가 물리적 커널 코드 페이지 외부에 위치된 악성 코드로 점프할 때 공격을 방지하기 때문에, 일 실시예에 따른 프로세서(PRIVLOCK)은 페이지 테이블 조작 단계에서 이 공격을 검출하거나 방지할 수 없을 수 있다.
세 번째 공격은 커널 코드 페이지들을 수정하는 것을 목표로 하지만, 커널 코드 페이지에 대해 새로 생성된 가상 페이지를 사용한다는 점에서 첫 번째 공격보다 고급일 수 있다. 첫 번째 공격과 달리, 운영 체제 커널은 악성 페이지 테이블 수정을 방지하거나 완화하기 위한 일부 메커니즘들[5, 13]로 강화되지 않는 한, 이 공격을 검출할 수 없을 수 있다. 예상된 대로, 구현된 공격은 일 실시예에 따른 프로세서(PRIVLOCK)이 인에이블링되지 않을 때 커널 코드 페이지를 성공적으로 손상시키지만, 일 실시예에 따른 프로세서(PRIVLOCK)은 커널 코드 페이지가 덮어쓰일 때 공격을 방지할 수 있다. 추가 가상 페이지가 있더라도, 쓰기는 물리적 커널 코드 페이지로 전달될 수 있다. 공격은 새 매핑을 쓰기 가능한 페이지로 생성하지만, 일 실시예에 따른 프로세서(PRIVLOCK)은 엔트리가 TLB에 로드되고 프로세서가 이 페이지를 쓰기 방지된 것으로 인식할 때 이 속성을 클리어링(clear) 수 있다.
이상에서 설명된 실시예들은 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치, 방법 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 컨트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.
실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있으며 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.
위에서 설명한 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 또는 복수의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
이상과 같이 실시예들이 비록 한정된 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 이를 기초로 다양한 기술적 수정 및 변형을 적용할 수 있다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.
그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (29)

  1. 프로세서에 의하여 수행되는 커널 코드 영역에 대한 동작을 제어하기 위한 방법에 있어서,
    프로세서가 머신 모드(machine mode)인 동안, 커널 코드(kernel code)가 저장된 커널 코드 영역의 물리 주소(physical address)에 기초하여 범위 레지스터(range register)를 설정(configure)하는 단계;
    상기 프로세서가 커널 모드(kernel mode)인 동안 페이지(page)의 가상 주소에 기초한 액세스 요청을 수신하는 경우에 응답하여, 상기 페이지의 상기 가상 주소에 대한 페이지 테이블 엔트리(page table entry)를 이용하여 상기 페이지의 물리 주소를 획득하는 단계;
    상기 설정된 범위 레지스터를 상기 획득된 물리 주소와 비교함으로써, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하는 단계; 및
    상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역(kernel code region)에 포함되는지 여부에 기초하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블(enable) 또는 디스에이블(disable) 여부를 결정하는 단계
    를 포함하는 방법.
  2. 제1항에 있어서,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는,
    상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작(write operation)을 디스에이블하는 단계를 포함하는,
    방법.
  3. 제1항에 있어서,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는,
    상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(execute operation)을 인에이블하는 단계를 포함하는,
    방법.
  4. 제1항에 있어서,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는,
    상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역과 다른 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(execute operation)을 디스에이블(disable)하는 단계를 포함하는,
    방법.
  5. 제1항에 있어서,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계는,
    상기 페이지 테이블 엔트리의 페이지 테이블 속성(page table attribute)과 독립적으로, 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계를 포함하는,
    방법.
  6. 제1항에 있어서,
    상기 범위 레지스터를 설정하는 단계는,
    상기 프로세서가 머신 모드인 동안, 커널 코드를 가지는 페이지를 미리 결정된 크기를 가지는 청크(chunk)의 경계(boundary)에 따라 정렬(align)하는 단계를 포함하는,
    방법.
  7. 제1항에 있어서,
    상기 범위 레지스터를 설정하는 단계는,
    상기 커널 코드를 적어도 하나의 커널 코드 청크(kernel code chunk)로 저장하는 단계; 및
    각 커널 코드 청크(kernel code chunk)에 대하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 적어도 일부를 설정하는 단계를 포함하는,
    방법.
  8. 제1항에 있어서,
    상기 범위 레지스터를 설정하는 단계는,
    각 커널 코드 청크의 시작 물리 주소에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 베이스 비트(base bit)를 설정하는 단계; 및
    해당 커널 코드 청크의 크기에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 마스크 비트(mask bit)를 설정하는 단계를 포함하는,
    방법.
  9. 제1항에 있어서,
    상기 범위 레지스터를 설정하는 단계는,
    상기 범위 레지스터의 베이스 비트 및 마스크 비트를 설정한 경우에 응답하여, 상기 범위 레지스터의 밸리드 비트(valid bit) 및 락 비트(lock bit)를 설정하는 단계를 포함하는,
    방법.
  10. 제1항에 있어서,
    상기 페이지의 물리 주소를 획득하는 단계는,
    변환 색인 버퍼(translation lookaside buffer; TLB)에 상기 액세스 요청의 상기 가상 주소에 대한 상기 페이지 테이블 엔트리가 캐시(cache)되어 있는지 여부를 확인하는 단계를 포함하고,
    상기 방법은,
    상기 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 설정된 범위 레지스터와 상기 획득된 물리 주소의 비교를 생략하는 단계
    를 더 포함하는 방법.
  11. 제1항에 있어서,
    변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성에 기초하여 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는 단계
    를 더 포함하는 방법.
  12. 제1항에 있어서,
    상기 페이지의 물리 주소를 획득하는 단계는,
    상기 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있지 않은 경우에 응답하여, 페이지 테이블로부터 상기 가상 주소에 대한 상기 페이지 테이블 엔트리를 검색하는 단계; 및
    상기 검색된 페이지 테이블 엔트리에 기초하여, 상기 가상 주소에 매핑된 상기 페이지의 상기 물리 주소를 획득하는 단계를 포함하는,
    방법.
  13. 제1항에 있어서,
    상기 결정된 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부에 기초하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성을 업데이트하는 단계; 및
    상기 업데이트된 페이지 테이블 속성을 상기 페이지 테이블 엔트리와 함께 변환 색인 버퍼에 캐시하는 단계
    를 더 포함하는 방법.
  14. 제1항에 있어서,
    상기 획득된 물리 주소에 대응하는 영역 커널 코드 영역에 포함되는지 여부를 판단하는 단계는,
    상기 범위 레지스터의 마스크 비트에 기초하여, 상기 물리 주소 중 부분 주소를 결정하는 단계; 및
    상기 결정된 부분 주소가 상기 범위 레지스터의 베이스 비트의 적어도 일부에 매칭되는 경우 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 것을 판단하는 단계를 포함하는,
    방법.
  15. 하드웨어와 결합되어 제1항 내지 제14항 중 어느 하나의 항의 방법을 실행시키기 위하여 컴퓨터 판독 가능한 기록매체에 저장된 컴퓨터 프로그램.
  16. 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치에 있어서,
    프로세서가 머신 모드(machine mode)인 동안, 커널 코드(kernel code)가 저장된 커널 코드 영역의 물리 주소(physical address)에 기초하여 범위 레지스터(range register)를 설정(configure)하고, 상기 프로세서가 커널 모드(kernel mode)인 동안 페이지(page)의 가상 주소에 기초한 액세스 요청을 수신하는 경우에 응답하여, 상기 페이지의 상기 가상 주소에 대한 페이지 테이블 엔트리(page table entry)를 이용하여 상기 페이지의 물리 주소를 획득하며, 상기 설정된 범위 레지스터를 상기 획득된 물리 주소와 비교함으로써, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부를 판단하고, 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는지 여부에 기초하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블(enable) 또는 디스에이블(disable) 여부를 결정하는 프로세서
    를 포함하는 전자 장치.
  17. 제16항에 있어서,
    상기 프로세서는,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하고,
    상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 물리 주소에 대응하는 영역에 대한 쓰기 동작(write operation)을 디스에이블하는,
    전자 장치.
  18. 제16항에 있어서,
    상기 프로세서는,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하고,
    상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(execute operation)을 인에이블하는,
    전자 장치.
  19. 제16항에 있어서,
    상기 프로세서는,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하고,
    상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역과 다른 영역에 포함되는 경우에 응답하여, 상기 프로세서가 커널 모드인 동안 상기 물리 주소에 대응하는 영역에 대한 실행 동작(excute operation)을 디스에이블(disable)하는,
    전자 장치.
  20. 제16항에 있어서,
    상기 프로세서는,
    상기 쓰기 동작 또는 실행 동작 중 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하고,
    상기 페이지 테이블 엔트리의 페이지 테이블 속성(page table attribute)과 독립적으로, 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는,
    전자 장치.
  21. 제16항에 있어서,
    상기 프로세서는,
    상기 프로세서가 머신 모드인 동안, 커널 코드를 가지는 페이지를 미리 결정된 크기를 가지는 청크(chunk)의 경계(boundary)에 따라 정렬(align)하는,
    전자 장치.
  22. 제16항에 있어서,
    상기 프로세서는,
    상기 커널 코드를 적어도 하나의 커널 코드 청크(kernel code chunk)로 저장하고,
    각 커널 코드 청크(kernel code chunk)에 대하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 적어도 일부를 설정하는,
    전자 장치.
  23. 제16항에 있어서,
    상기 프로세서는,
    각 커널 코드 청크의 시작 물리 주소에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 베이스 비트(base bit)를 설정하고,
    해당 커널 코드 청크의 크기에 기초하여, 해당 커널 코드 청크에 대응하는 범위 레지스터의 마스크 비트(mask bit)를 설정하는,
    전자 장치.
  24. 제16항에 있어서,
    상기 프로세서는,
    상기 범위 레지스터의 베이스 비트 및 마스크 비트를 설정한 경우에 응답하여, 상기 범위 레지스터의 밸리드 비트(valid bit) 및 락 비트(lock bit)를 설정하는,
    전자 장치.
  25. 제16항에 있어서,
    상기 프로세서는,
    변환 색인 버퍼(translation lookaside buffer; TLB)에 상기 액세스 요청의 상기 가상 주소에 대한 상기 페이지 테이블 엔트리가 캐시(cache)되어 있는지 여부를 확인하고,
    상기 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 설정된 범위 레지스터와 상기 획득된 물리 주소의 비교를 생략하는,
    전자 장치.
  26. 제16항에 있어서,
    상기 프로세서는,
    변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있는 경우에 응답하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성에 기초하여 상기 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부를 결정하는,
    전자 장치.
  27. 제16항에 있어서,
    상기 프로세서는,
    상기 변환 색인 버퍼에 상기 페이지 테이블 엔트리가 캐시되어 있지 않은 경우에 응답하여, 페이지 테이블로부터 상기 가상 주소에 대한 상기 페이지 테이블 엔트리를 검색하고,
    상기 검색된 페이지 테이블 엔트리에 기초하여, 상기 가상 주소에 매핑된 상기 페이지의 상기 물리 주소를 획득하는,
    전자 장치.
  28. 제16항에 있어서,
    상기 프로세서는,
    상기 결정된 적어도 하나의 동작에 대한 인에이블 또는 디스에이블 여부에 기초하여, 상기 페이지 테이블 엔트리의 페이지 테이블 속성을 업데이트하고,
    상기 업데이트된 페이지 테이블 속성을 상기 페이지 테이블 엔트리와 함께 변환 색인 버퍼에 캐시하는,
    전자 장치.
  29. 제16항에 있어서,
    상기 프로세서는,
    상기 범위 레지스터의 마스크 비트에 기초하여, 상기 물리 주소 중 부분 주소를 결정하고,
    상기 결정된 부분 주소가 상기 범위 레지스터의 베이스 비트의 적어도 일부에 매칭되는 경우 상기 획득된 물리 주소에 대응하는 영역이 커널 코드 영역에 포함되는 것을 판단하는,
    전자 장치.
PCT/KR2023/007599 2022-09-01 2023-06-02 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치 및 방법 Ceased WO2024048922A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2022-0110820 2022-09-01
KR1020220110820A KR102728269B1 (ko) 2022-09-01 2022-09-01 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치 및 방법

Publications (1)

Publication Number Publication Date
WO2024048922A1 true WO2024048922A1 (ko) 2024-03-07

Family

ID=90098215

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/007599 Ceased WO2024048922A1 (ko) 2022-09-01 2023-06-02 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치 및 방법

Country Status (2)

Country Link
KR (1) KR102728269B1 (ko)
WO (1) WO2024048922A1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130283004A1 (en) * 2008-05-30 2013-10-24 Vmware, Inc. Virtualization with Multiple Shadow Page Tables
KR20170060815A (ko) * 2015-11-25 2017-06-02 삼성전자주식회사 메모리의 커널영역을 보호하기 위한 전자장치 및 방법
KR20200116311A (ko) * 2019-04-01 2020-10-12 서울대학교산학협력단 커널 무결성 검증 장치 및 그 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130283004A1 (en) * 2008-05-30 2013-10-24 Vmware, Inc. Virtualization with Multiple Shadow Page Tables
KR20170060815A (ko) * 2015-11-25 2017-06-02 삼성전자주식회사 메모리의 커널영역을 보호하기 위한 전자장치 및 방법
KR20200116311A (ko) * 2019-04-01 2020-10-12 서울대학교산학협력단 커널 무결성 검증 장치 및 그 방법

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HYUNGON MOON ; JINYONG LEE ; DONGIL HWANG ; SEONHWA JUNG ; JIWON SEO ; YUNHEUNG PAEK: "Architectural Supports to Protect OS Kernels from Code-Injection Attacks and Their Applications", ACM TRANSACTIONS ON DESIGN AUTOMATION OF ELECTRONIC SYSTEMS., ACM, NEW YORK, NY., US, vol. 23, no. 1, 31 August 2017 (2017-08-31), US , pages 1 - 25, XP058372772, ISSN: 1084-4309, DOI: 10.1145/3110223 *
MA JUN; CHONG TING; LI LEI; LIU HAO; ZHANG XIGE; LIU LIANG; YUAN YIDONG: "Construction of RISC-V Lightweight Trusted Execution Environment Based on Hardware Extension", 2021 IEEE INTERNATIONAL CONFERENCE ON POWER, INTELLIGENT COMPUTING AND SYSTEMS (ICPICS), IEEE, 29 July 2021 (2021-07-29), pages 237 - 242, XP033968414, DOI: 10.1109/ICPICS52425.2021.9524261 *

Also Published As

Publication number Publication date
KR20240031724A (ko) 2024-03-08
KR102728269B1 (ko) 2024-11-08

Similar Documents

Publication Publication Date Title
Connor et al. {PKU} pitfalls: Attacks on {PKU-based} memory isolation systems
US8578483B2 (en) Systems and methods for preventing unauthorized modification of an operating system
Suh et al. Secure program execution via dynamic information flow tracking
WO2022154195A1 (ko) 모바일 신뢰 실행 환경의 보안성 강화를 위한 장치
Suh et al. CSAIL
Wang et al. Seimi: Efficient and secure smap-enabled intra-process memory isolation
Wang et al. Design and implementation of SecPod, a framework for virtualization-based security systems
IL297388B2 (en) Translation table address storage circuitry
Deng et al. Dancing with wolves: Towards practical event-driven vmm monitoring
Enomoto et al. Efficient Protection Mechanism for CPU Cache Flush Instruction Based Attacks
Ojha et al. Timecache: Using time to eliminate cache side channels when sharing software
Chevalier et al. Co-processor-based behavior monitoring: Application to the detection of attacks against the system management mode
Huang et al. SoK: A comparison study of arm TrustZone and CCA
KR20190060109A (ko) 명령어 레벨 데이터 격리 방법 및 장치
KR20250153235A (ko) 어드레스 의존적 체크
Jang et al. SelMon: reinforcing mobile device security with self-protected trust anchor
US11216280B2 (en) Exception interception
Rosenblum et al. Virtual machine-provided context sensitive page mappings
Lee et al. GENESIS: A Generalizable, Efficient, and Secure Intra-kernel Privilege Separation
Green et al. Safebet: Secure, simple, and fast speculative execution
KR102728269B1 (ko) 커널 코드 영역에 대한 동작을 제어하기 위한 전자 장치 및 방법
Jang et al. Revisiting the arm debug facility for os kernel security
Lin et al. HyperKRP: A kernel runtime security architecture with a tiny hypervisor on commodity hardware
Takekoshi et al. BadAML: Exploiting Legacy Firmware Interfaces to Compromise Confidential Virtual Machines
Yitbarek et al. Neverland: Lightweight Hardware Extensions for Enforcing Operating System Integrity

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23860608

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23860608

Country of ref document: EP

Kind code of ref document: A1