About Hyeseon

About Hyeseon

Hyeseon's walkthrough

Hypernel: A Hardware-Assisted Framework for Kernel Protection without Nested Paging

About the Paper

Fig. 1 - Summary. The MBM and the security solution communicate through the Hypersec agent.
Fig. 2 - The software architecture. Basically the kernel page table is set as read-only such that only Hypernel can modify it.
Fig. 3 - The architecture of the Memory Bus Monitor (MBM). Fetches the write events from the memory controller and compares it with the bitmap on the host memory. Then, if the write event is against the region in the bitmap, raise an interrupt to call Hypersec.
Fig. 4 - The detection logic. Through the process which will be elaborated in the article, the hardware and the software closely work together to quickly detect the write event against the kernel memory region.

Since kernel-level malwares are hard to detect with ordinary security solutions, a specialized "kernel monitor" which taps on the kernel memory region to detect such malwares was deemed essential. When the paper was published, kernel monitors were divided into hardware-based ones, which sacrificed flexibility for speed, and software-based ones, which sacrificed host performance for flexibility. Hardware-based monitors have small memory such that they are harder to compensate for malware evolution or respond to more kinds of malwares. On the other hand, software-based monitors at that time suffered from the performance overhead from nested paging, like virtualization solutions. This meant that a system with a software-based monitor suffered from a performance overhead close to operating system (OS) virtualization while there was only one OS running.

Hypernel targets the ARM system-on-a-chip (SoC), which runs on mobile devices. On it, both software-based approaches, which suffer from virtualization-level overhead, and hardware-based approaches, which are not flexible, were not sufficient. To overcome this seemingly impossible requirements, Hypernel mixed up software-based and hardware-based approaches. Hypernel injects a security monitor at exception level 2 (EL2), which is generally used by a hypervisor, but it does not perform nested paging and uses the kernel-level (EL1) page table as-is while recording regions to monitor on the separate host memory region. After Hypernel marks regions to detect, when there is a write event on the memory bus, the hardware detects it and if it must be reported according to the marking, interrupts to call Hypersec. On an actual ARM device, the runtime performance overhead was only about 3.1%.

Contribution and Information

  • Period of Research and Writing: 10/2015 ~ 11/2017
  • Contribution among Total Participants: Co-first author among five writers (+ two corresponding authors)
  • Role: Co-first author
  • Supervised the paper's direction and writing
  • Software design
  • Technology Used: ARM low-level programming (ARM assembly, UEFI, C, etc.), FPGA, embedded Linux

Abstract

Large OS kernels always suffer from attacks due to their numerous inherent vulnerabilities. To protect the kernel, hypervisors have been employed by many security solutions. However, relying on a hypervisor has a detrimental impact on the system performance due mainly to nested paging. In this paper, we present Hypernel, a security framework combining hardware and software components to address this problem. Hypersec, the software component, provides an isolated execution environment for security solutions, and the hardware monitor component enables a word-granularity monitoring capability on the kernel memory. Our evaluation shows that Hypernel efficiently fulfills the role of a security framework, while imposing mere 3.1% of runtime overhead on the system.

References