Monday, December 5, 2011

RTEMS Memory Protection Middle Layer

This is a continuation of my prior post in which I described an API for memory protection. Here I will describe the middle layer that glues the user API to the CPU support code that eventually interacts with hardware to enforce the permission attributes.

For those familiar with RTEMS, this code lives in libcpu and the design mimics that of the cache manager. The middle layer is just 5 functions:

These functions are called via thin wrappers from the high-level API. The install and uninstall entry functions are called iteratively by the higher-level functions that install and uninstall protection domains. The two "verify" functions are used by the high-level API to avoid trying to install invalid entries proactively. The remaining functions interact with the hardware directly to support the memory protection mechanisms.

Next I will briefly explain what each function does in my sparc64 implementation.

_CPU_Memory_protection_Initialize

Disables interrupts

Selectively demaps pages that were loaded during system startup

Flushes the cache

Maps new pages for the kernel core services

Installs exception handlers for MMU misses

_CPU_Memory_protection_Verify_permission

Returns true; needs a little refinement.

_CPU_Memory_protection_Verify_size

Ensures the size (bounds) is a multiple of the supported TLB page size

_CPU_Memory_protection_Install_MPE

Adds a TLB entry for the memory region specified in the MPE

_CPU_Memory_protection_Uninstall_MPE

Removes the TLB entry for the specified memory region

These functions call BSP- and CPU-specific functions to handle the hardware (TLB) interactions and comprise the entire middle layer between the API for memory protection and whatever low-level code enforces the protection mechanism.