Use PAL like a "Chipsec for ARM" Tool

[JaredWright]

Summary

The goal of this discussion is to brainstorm if/how PAL could be extended to provide a capability similar to the Chipsec project, but for ARMv8 instead of Intel x86_64.

Background Context

The PAL project contains an experimental driver (devpal) that allows an application to leverage the entire PAL generated APIs from a userspace application. This interaction works by forwarding all instruction APIs as requests over an IOCTL interface. The driver executes instructions on an applications behalf, and then formats and returns any applicable outputs. This allows PAL to be used very similar to Chipsec, so that researchers/developers/testers can peek/poke privileged CPU state from a convenient (albeit dangerous) execution context. At the moment, the devpal driver only supports Linux and Windows for the Intel x86_64 architecture.

Proposed Changes

As a first step, the devpal driver could be extended to support Linux on ARM by adding support for instructions in the A64 instruction set. This would give a userspace application the ability to peek/poke at the instructions and registers owned by whichever execution state Linux maintains control of (EL1, EL2, etc).

After that, there are a ton of ways this idea could be expanded

What could this be used for?

• Expedite security research activities on the ARMv8 platform
• Enable the development of security-focused regression tests similar to Chipsec
• Provide a convenient way to research and learn about the ARMv8 platform

Challenges

The A64 instruction set operates fundamentally different from the x86 world. In x86, most system instructions take arguments in the form of values passed through general-purpose registers (e.g. load a value into RAX, which gets used an an input to an instruction). This makes it very simple to pass instruction input/output values across an IOCTL interface.

In contrast, most A64 system instructions take inputs as values embedded within the instruction's encoding. This means that input values to an instruction can't be provided as easily at runtime (they are usually determined at compile time).

One possible way to address this challenge would be to figure out a way to implement handlers for two different instructions in an ARMv8 version of the linux devpal driver:

1. sys.c
2. sysl.c

The thought here is that almost every instruction in A64 is just an alias of the SYS (write-like) or SYSL (read-like) instructions. PAL is smart enough to derive the fields that make up the encoding of those instructions, and could provide those as inputs to forward across the driver's IOCTL interface. Hence, SYS and SYSL could execute pretty much any system instruction by writing an opcode to memory, then executing it. Note: this implementation would require a system configured to allow write+execute memory pages.

[JaredWright]

This idea is being actively developed over the summer of 2022.