AIKP
Rethinking the kernel’s reach.
What if compromising the kernel didn’t automatically expose every application’s memory? AIKP is my experiment in separating application execution from operating system services, with a memory boundary enforced by hardware.
What is AIKP?
AIKP stands for (A)synchronous (I)ndependent (K)ernel (P)rocessor
AIKP is an experimental processor architecture built around two separate trust domains: an Application Processor (AP) and a Kernel Processor (KP). Each has its own private memory. The aim is to let the kernel manage resources without giving it unrestricted access to the secrets held by applications.
Simply moving the kernel to another CPU core would not provide that protection. The separation needs to be enforced below the kernel, by hardware the KP cannot reconfigure, so a compromised KP cannot simply map and read arbitrary AP memory.
Two processors, different responsibilities
AP · Application Processor
Owns application memory and execution
Applications run alongside a privileged AP supervisor. It manages page tables, page faults, context switching, copy-on-write, signal state and the memory grants used to communicate with the kernel.
Private AP RAM sits inside this trust boundary.
KP · Kernel Processor
Provides operating system services
The kernel retains filesystems, networking, device drivers, credentials and scheduling policy. It requests operations on process objects through a restricted interface to the AP supervisor.
Applications run alongside a privileged AP supervisor. It manages page tables, page faults, context switching, execution state, copy-on-write and the memory grants used to communicate with the kernel. The KP can determine scheduling policy, while the AP supervisor performs the actual protected context transitions.
It has its own private RAM, without unrestricted access to application memory.
The interface is central to the design: a request to fork a process or deliver a signal must not become a way to read or write arbitrary application addresses. The AP supervisor has to validate requests even when they come from the kernel.
Share only what an operation needs
The initial concept used shared memory to pass syscall requests and data between processors. The design is evolving toward temporary memory grants: the AP authorizes specific pages, access permissions and a lifetime for an operation, then revokes access when it finishes.
A filesystem write, for example, could temporarily grant the KP access to only the authorized pages containing the buffer, without making the rest of the application's address space accessible. Device DMA must obey the same boundary, with IOMMU authority outside the KP’s control.
The experiment
I’m exploring the architecture and planning a minimal QEMU prototype: separate processor domains, private memory and a communication mechanism. The first milestone is a simple request from an application to the kernel. The meaningful test comes next: give the KP arbitrary code execution and try to retrieve a secret held in AP-private RAM.
This is a design under investigation, not a demonstrated security guarantee. A compromised kernel could still deny services, interfere with I/O or return malicious data. The narrower goal is to keep that compromise from automatically granting arbitrary access to application memory.
Performance, the AP supervisor’s trusted responsibilities, grant revocation and DMA isolation are all part of the research.
Follow the design
These two posts trace the idea from the original hardware split to the responsibilities of the AP supervisor.
-
Part 1 · The idea
What If the Kernel Couldn’t Read Application Memory?
The original question, the AP/KP memory boundary and a plan for testing it with an intentionally compromised kernel.
-
Part 2 · The responsibilities
Okay, So If the Kernel Can’t Read Application Memory, Who Does All the Kernel Stuff?
How an AP supervisor could handle process memory and execution, with temporary grants, a restricted interface and DMA isolation.