PaperlayerView exact revision on arXiv

Source-linked AI summary

Sprobes: Enforcing Kernel Code Integrity on the TrustZone Architecture

Xinyang Ge, Hayawardh Vijayakumar, Trent Jaeger

arXiv:1410.7747v1cs.CRcs.OS

TL;DR

Smartphone systems need a way to restrict or detect rootkits already injected into running kernels. SPROBES supplies TrustZone-based instruction traps, and five invariants enforced with 12 probes restricted Linux 2.6.38 execution to approved code.

  • Problem

    The paper asks whether available smartphone hardware can restrict or detect rootkits already injected into a running kernel.

    Source: §I · p. 1

  • Method

    SPROBES uses TrustZone to let the secure world instrument chosen normal-world instructions and receive unforgeable traps.

    Source: §I · p. 2

  • Results

    12 SPROBES comprehensively enforced five invariants for Linux 2.6.38, restricting kernel execution to approved code even if the kernel was rootkit-controlled.

    Source: §I · p. 2

  • Takeaways & Limitations

    The paper concludes that enforcing the five invariants guarantees that only approved kernel code executes even when the kernel is fully compromised.

    Source: §IX · p. 10

Abstract

from arXiv · show

Many smartphones now deploy conventional operating systems, so the rootkit attacks so prevalent on desktop and server systems are now a threat to smartphones. While researchers have advocated using virtualization to detect and prevent attacks on operating systems (e.g., VM introspection and trusted virtual domains), virtualization is not practical on smartphone systems due to the lack of virtualization support and/or the expense of virtualization. Current smartphone processors do have hardware support for running a protected environment, such as the ARM TrustZone extensions, but such hardware does not control the operating system operations sufficiently to enable VM introspection. In particular, a conventional operating system running with TrustZone still retains full control of memory management, which a rootkit can use to prevent traps on sensitive instructions or memory accesses necessary for effective introspection. In this paper, we present SPROBES, a novel primitive that enables introspection of operating systems running on ARM TrustZone hardware. Using SPROBES, an introspection mechanism protected by TrustZone can instrument individual operating system instructions of its choice, receiving an unforgeable trap whenever any SPROBE is executed. The key challenge in designing SPROBES is preventing the rootkit from removing them, but we identify a set of five invariants whose enforcement is sufficient to restrict rootkits to execute only approved, SPROBE-injected kernel code. We implemented a proof-of-concept version of SPROBES for the ARM Fast Models emulator, demonstrating that in Linux kernel 2.6.38, only 12 SPROBES are sufficient to enforce all five of these invariants. With SPROBES we show that it is possible to leverage the limited TrustZone extensions to limit conventional kernel execution to approved code comprehensively.

I. INTRODUCTION

Smartphone kernels face rootkits, and the paper asks whether available smartphone hardware can restrict or detect rootkits already injected into a running kernel. It presents SPROBES, a TrustZone-based instrumentation mechanism, and applies it to enforcing approved-code execution.

I. INTRODUCTION

  • Conventional operating systems on smartphones bring rootkit risks; an installed rootkit can control user-space processes and evade traditional antivirus software.The paper notes that complex systems and privileged processes can contain vulnerabilities that enable rootkit installation.Source: §I · p. 1
  • Virtualization is considered too expensive for smartphones, while coprocessors have limited visibility into kernel state and SMM is resource-limited and Intel-only.The introduction frames available smartphone hardware as a basis for restricting or detecting rootkits already injected into a running kernel.Source: §I · p. 1
  • SPROBES lets the secure world trap on any chosen normal-world instruction and receive an unforgeable view of processor state, without requiring operating-system changes.The secure world can select instructions, inspect state, perform monitoring actions, and return control to the normal world.Source: §I · p. 2
  • 12 SPROBES comprehensively enforced five invariants for Linux 2.6.38, restricting kernel execution to approved code even under rootkit control.Most probes are not hit in normal operation; others account for less than 2% of instructions executed or are typically used by VM introspection.Source: §I · p. 2
  • The paper identifies five invariants and a SPROBE placement strategy to restrict normal-world kernel execution to approved code pages, even under rootkit control.The resulting restriction also protects SPROBES from modification by a live rootkit.Source: §I · p. 2

II. PROBLEM OVERVIEW

The problem is to preserve approved kernel-code execution even when an adversary can use a rootkit to alter memory protections or redirect execution. The paper frames this as five security requirements.

II. PROBLEM OVERVIEW

  • W⊕X limits execution to pages selected as legitimate code, but return-oriented programming can still reuse executable code, and address randomization may be defeated by information disclosure.The paper assumes the kernel initially enforces W⊕X over approved code pages while allowing a ROP attack to launch the rootkit.Source: §II · pp. 2–3
  • The threat model assumes initial W⊕X protection over approved kernel code pages, but allows an adversary to launch a rootkit using existing code.A rootkit could disable the WXN bit, allowing writable pages to become executable and enabling code injection.Source: §II · p. 3
  • A rootkit can modify page-table permissions in place or switch to a duplicated page table to make code writable, alter it, and restore executability.Both routes can inject kernel code while making the altered page appear executable again.Source: §II · p. 3
  • Disabling the MMU can bypass virtual-memory protections, while redirecting kernel execution to user-space instructions can run attacker-prepared code.The MMU route may limit the attacker to physical addresses, depending on the operating system's address mappings.Source: §II · p. 3
  • The five requirements forbid kernel execution of user-space code, require W⊕X and the MMU to remain enabled, and require a legitimate page-table base and verified, mediated page-table updates.These are the stated conditions for preserving the kernel's approved-code boundary.Source: §II · p. 3

III. BACKGROUND: TRUSTZONE ARCHITECTURE

TrustZone separates secure and normal worlds while allowing the secure world to view the normal world. However, normal-world control of its own resources limits the secure world's ability to protect the kernel.

III. BACKGROUND: TRUSTZONE ARCHITECTURE

  • TrustZone partitions hardware and software resources between a security-sensitive secure world and a conventional normal world.The secure world is intended to protect the confidentiality and integrity of critical computation.Source: §III · p. 3
  • The processor runs in one world at a time; monitor mode, which resides in the secure world, saves and restores processor state during world switches.Interrupts may be assigned to either world, and the normal world can request monitor-mode entry with a Secure Monitor Call.Source: §III · p. 3
  • TrustZone lets the secure world access normal-world resources, but normal-world resources are unavailable to the processor while it runs in the normal world.Resources are tagged by world, and the normal world can access only resources assigned to it.Source: §III · pp. 3–4
  • The normal world retains control over its memory system and assigned interrupts, so rootkits can tamper with virtual-memory settings without secure-world mediation.Unlike a VMM, the secure world cannot manage normal-world physical memory or locally handled interrupts.Source: §III · p. 4

IV. SPROBES MECHANISM

SPROBES lets the secure world break on selected normal-world instructions and inspect an unforgeable processor state. It substitutes an SMC instruction at each chosen location, invokes a secure-world handler, and resumes the original instruction afterward.

SPROBES mechanism

  • When a SPROBE is hit, the secure world receives an unforgeable view of normal-world processor state, invokes the specified handler, then returns execution to the hit location.The state is passed to the handler as a structure.Source: §IV · p. 4
  • A trustlet inserts a SPROBE by replacing a selected normal-world instruction with SMC, which triggers entry to the secure world.The handler can monitor kernel state before restoring and executing the original instruction.Source: §IV · p. 4
  • SPROBES are hardware-supported, transparent to normal-world software, can target any instruction, and keep their code and data isolated in the secure world.They use ARM's SMC instruction and cross-world memory access; the original normal-world control flow remains unchanged.Source: §IV · p. 4

V. PROTECTING INTEGRITY OF KERNEL CODE

The placement strategy uses five invariants to constrain a compromised normal-world kernel to approved code and protect SPROBES from removal. It combines boot-time configuration with runtime mediation of control registers, page tables, and page faults.

Trust model

  • The strategy assumes trusted secure-world code, a clean kernel until the first user-space process, load-time kernel integrity, and hardware IOMMU protection against malicious DMA.It does not defend against malicious kernel code present before the first user-space process.Source: §V · p. 5

Placement strategy and configuration

  • Before boot, the secure world needs the kernel page-table base and approved code-page locations, and must write-protect the kernel page table.W⊕X and MMU protections are established before the first user-space process; runtime SPROBES then enforce the invariants.Source: §V · p. 5

Approved Kernel Code

  • The design assumes loadable kernel modules are unsupported, because modules can add code beyond the kernel pages approved before boot.Intercepting the init module system call to record module locations is discussed as an alternative, but the general problem is left for future work.Source: §V · p. 5

Enforcing S2

  • To enforce S2, SPROBES monitor every kernel instruction that writes SCTLR and block values that unset WXN, assumed set at initialization.Writes to other SCTLR control bits can also trigger a SPROBE, causing unnecessary overhead through false sharing.Source: §V · p. 6

Enforcing S3

  • To enforce S3, SPROBES mediate TTBR writes, while the secure world validates each page table the first time its base is asserted.Validation checks mappings and permissions, including that approved kernel code is not writable and that code/data pages are not double-mapped.Source: §V · p. 6

Enforcing S4

  • To enforce S4, the secure world write-protects page tables and places a SPROBE at the page-fault handler so each update is mediated.Intended faults proceed normally; legitimate table updates are emulated, while changes that make kernel code writable or other frames executable are blocked.Source: §V · pp. 6–7

Enforcing S1

  • S1 relies on protected page-table entries and validation of new tables to keep PXN set on user-space pages, preventing privileged execution of user code.ARM's fixed exception-vector location and protected vector code prevent replacing the page-fault entry point that mediates table updates.Source: §V · pp. 6–7

Security guarantees

  • Five invariants mediate virtual-memory control and restrict a rootkit to approved code pages, indirectly protecting SPROBES inserted in those pages.The strategy aims to prevent code injection and modification of approved kernel code over the system's lifetime.Source: §V · pp. 4, 7

VI. IMPLEMENTATION

The prototype runs SPROBES on an emulated Cortex-A15 with Linux 2.6.38 in the normal world. Its implementation identifies target instructions from the kernel image and uses secure-world memory mappings and page-fault handling to mediate them.

Implementation

  • The prototype runs Linux 2.6.38 in the normal world on ARM Fast Models' emulated Cortex-A15 and extracts kernel information in advance to locate SPROBES.The kernel is built from source with the GNU ARM bare-metal toolchain; objdump is used to inspect its code layout.Source: §VI · p. 7

SPROBE insertion

  • To replace target instructions, the secure world translates normal-world virtual addresses to physical addresses and maps them in its own page table.Cortex-A15 CP15 performs the translation, and page-table entries use an NS bit to identify the world associated with physical memory.Source: §VI · p. 7

Register-write instrumentation

  • The implementation scans the kernel text for SCTLR writers and inserts SPROBES there to enforce W⊕X protection.It also scans for TTBR writers and instruments TTBCR writers to prevent enabling a second page table.Source: §VI · p. 8

Page-table protection

  • The secure world makes normal-world page tables read-only and inserts a SPROBE at the first page-fault-handler instruction to mediate updates.This prevents normal-world instructions from running before secure-world control and helps preserve processor state for unexpected faults.Source: §VI · p. 8

A. Security Analysis

The security analysis argues that SPROBES can restrict Linux 2.6.38 kernel execution to approved code by detecting virtual-memory changes and enforcing protected memory permissions.

A. Security Analysis

  • 12 SPROBES are grouped into six Type #1 probes, four Type #2 probes, one Type #3 probe, and one Type #4 probe.They protect SCTLR, TTBR, TTBCR, and the page-fault handler, respectively.Source: A. Security Analysis · p. 8
  • The four SPROBE types are intended to detect memory-environment changes, including page-table changes and MMU disabling, so malicious changes cannot bypass secure-world checks.Switching page tables triggers Type #2 and/or Type #3; modifying page-table entries triggers Type #4; disabling the MMU triggers Type #1.Source: A. Security Analysis · p. 8
  • Secure boot is assumed to protect the kernel image file, since modifying it is the identified route to code-integrity compromise without changing the virtual-memory environment.The passage states that checking the image is sufficient for load-time integrity because loading occurs before an adversary is assumed to have system access.Source: A. Security Analysis · p. 8
  • The secure world treats disabling the MMU or W⊕X protection as compromise and enforces non-executable kernel data, unwritable kernel code, and non-executable user pages.A fixed one-to-one mapping between kernel-code pages and physical frames, plus forbidding double mappings, protects executed code frames from modification.Source: A. Security Analysis · p. 8, Figure 5 · p. 9

B. Performance Evaluation

The evaluation estimates probe overhead through instruction counts and hit frequencies on Linux 2.6.38, while cautioning that the emulator cannot provide accurate cycle-based performance results.

B. Performance Evaluation

  • Fast Models does not model accurate cycle counts, so its instruction-count-based benchmark results would not represent real-world software overhead reliably.The model assigns the same time to arithmetic operations and memory accesses.Source: B. Performance Evaluation · p. 9
  • 5,611 additional secure-world instructions, including the original SMC instruction, were executed per SPROBE hit.Instruction counts are a coarse-grained measure that excludes microarchitectural events.Source: B. Performance Evaluation · p. 9
  • Runtime overhead may be close to acceptable: only two SPROBE types are hit during normal runtime, accounting for fewer than 10% of executed instructions.The passage notes that restricting boot-time execution to trusted code may be needed for performance, but could introduce an attack window.Source: B. Performance Evaluation · p. 9
  • VM introspection methods also trap all page faults, so their trap count would be the same, although TrustZone overhead may be higher.Source: B. Performance Evaluation · p. 9
  • 313,836 instructions separated Type #2 hits on average, accounting for 2% of executed instructions; Type #4 hits occurred every 22,424 instructions during boot and every 85,982 after setup.Type #2 probes are hit on each context switch; Type #1 and Type #3 are not hit after boot.Source: Table I · p. 9, B. Performance Evaluation · p. 9
  • Type #1 probes were never hit after initialization, which the authors take as evidence that false sharing can be eliminated to an acceptable range in a real implementation.Source: B. Performance Evaluation · p. 9

VIII. RELATED WORK

Related work addresses kernel integrity and rootkit monitoring through virtual-machine monitors, periodic snapshots, coprocessors, and hardware-assisted checking.

VIII. RELATED WORK

  • SecVisor restricts kernel-space code using physical-memory virtualization, while NICKLE routes instruction fetches to protected copies of authenticated code.SecVisor also checks selected kernel states at mode switches.Source: §VIII · p. 9
  • Petroni et al.'s state-based control-flow monitor periodically snapshots VM memory, but may miss attacks occurring between snapshots.Its practical detection applies mainly to invariant or enumerable memory contents.Source: §VIII · p. 9
  • Livewire uses VM introspection to check kernel-code integrity and verify fixed-value function pointers such as the system-call table.Source: §VIII · p. 9
  • Coprocessor monitors include Zhang et al.'s approach and Copilot, which periodically checksums invariant memory and reports to a remote administration station.The cited work notes that a coprocessor can improve performance compared with VMM-based monitoring, despite potentially lacking full host-processor state access.Source: §VIII · pp. 9–10
  • HyperCheck uses Intel System Management Mode to check VMM state and communicate securely with a remote administration server.Source: §VIII · p. 10

IX. CONCLUSION

The conclusion presents SPROBES as a secure-world mechanism for introspecting the normal-world operating system and protecting kernel-code integrity.

IX. CONCLUSION

  • SPROBES enables the secure world to introspect an operating system running in the normal world.Source: §IX · p. 10
  • The design identifies five invariants and informally argues that 12 SPROBES enforce them comprehensively.Source: §IX · p. 10
  • Enforcing the invariants guarantees that only approved kernel code executes, even when the kernel is fully compromised.Source: §IX · p. 10
Loading 1410.7747v1…