IBM AIX Continuous Availability Features - IBM Redbooks

To continue running in a key-protected environment, legacy kernel extensions receive special
support from the kernel. Any extension converted to use keys is still in an environment with a
mixture of key-aware and key-unsafe functions. A key-aware kernel extension might call a
service that is in a key-unsafe kernel extension.
When a key-unsafe function is called, the kernel must, in effect, transparently insert special
glue code into the call stack between the calling function and the key-unsafe called function.
This is done automatically, but it is worth understanding the mechanism because the inserted
glue code is visible in stack callback traces.
When legacy code is called, either directly by calling an exported function or indirectly by
using a function pointer, the kernel must:
1. Save the caller's current key access rights (held in the AMR).
2. Save the caller's link register (LR).
3. Replace the current AMR value with one granting broad data access rights.
4. Proceed to call the key-unsafe function, with the link register set, so that the called
function returns to the next step.
5. Restore the original caller's AMR and LR values.
6. Return to the original caller.
The AMR update must be performed transparently, thus the new AMR stack had to be
developed. The new resource is also called a context stack. The current context stack pointer
is maintained in the active kmstsave structure, which holds the machine state for the thread
or interrupt context. Use the mst kernel debugger command to display this information. The
context stack is automatically pinned for key-unsafe kernel processes. The setjmpx and
longjmpx kernel services maintain the AMR and the context stack pointer.
When a context stack frame needs to be logically inserted between standard stack frames,
the affected function (actually, the function's traceback table) is flagged with an indicator. The
debugger recognizes this and is able to provide you with a complete display for the stack
trace. The inserted routine is named hkey_legacy_gate. A similar mechanism is applied at
many of the exported entry points into the kernel, where you might observe the use of
kernel_add_gate and kernel_replace_gate.
This processing adds overhead when an exported key-unsafe function is called, but only
when the called function is external to the calling module. Exported functions are represented
by function descriptors that are modified by the loader to enable the AMR changing service to
front-end exported services. Intramodule calls do not rely on function descriptors for direct
calls, and thus are not affected.
All indirect function pointer calls in a key-aware kernel extension go through special
kernel-resident glue code that performs the automatic AMR manipulations as described. If
you call out this way to key-unsafe functions, the glue code recognizes the situation and takes
care of it for you. Hence, a key-aware kernel extension must be compiled with the
-q noinlglue option for glue code.
Key-safe kernel extension
A key-safe kernel extension manages its access to memory, respecting the boundaries of the
kernel and user domains. It does not directly reference either kernel private data structures or
user space addresses. It also does not attempt to protect its own private data (see
“Key-protected kernel extension” on page 86). To become key-safe, the extension must
explicitly select the existing memory domains which it intends to access. This protects the rest
of the system from errors in the key-safe module.
Chapter 3. AIX advanced continuous availability tools and features 85