IBM AIX Continuous Availability Features - IBM Redbooks

Note: Kernel keys and keysets, which are described later in this section, are defined here:
► A kernel key is a virtual key that is assigned by the kernel. Kernel programs can use
more virtual keys than exist in the hardware, because many kernel keys can share a
single hardware key.
The kernel data is classified into keys according to function. You can use kernel keys to
define a large number of virtual storage protection keys. Most kernel keys are used only
within the kernel. The sys/skeys.h file contains a list of all keys.
► A kernel keyset is a grouping of kernel keys based on usage scope (see “Kernel
keysets” on page 82). The sys/skeys.h file contains a list of all predefined keysets.
To make a kernel extension key-safe, follow these steps:
1. Decide which exported kernel keyset, if any, should be the basis for your module's keyset.
2. Optionally, remove any unnecessary keys from your copy of this kernel keyset.
3. Convert the kernel keyset to a hardware keyset.
4. Place add or replace (protection) gates (see 3.7.5, “Protection gates” on page 87) at or
near all entry points (except driver initialization) as needed to gain the specific data access
rights required by each entry point. You will no longer have direct access to user space by
default, and you might need to address that issue at a later time.
5. Place your restore gates at or near exit points.
6. Link your extension with the new –b RAS flag to identify it to the system as RAS-aware.
7. Do not specify inline pointer glue (-q inlglue), as previously mentioned.
Note that if you are compiling with the v9 or later xlC compiler, you must specify
–q noinlglue because the default has changed.
Your initialization or configuration entry point cannot start off with a protection gate whose
underlying hardware keyset it must first compute. Only after setting up the necessary
hardware keysets can you implement your protection gates.
The computation of these keysets should be done only once (for example, when the first
instance of an adapter is created). These are global resources used by all instances of the
driver. Until you can use your new protection gates, you must be sure to reference only data
that is unprotected, such as your stack, bss, and data regions.
If this is particularly difficult for some reason, you can statically initialize your hardware keyset
to HKEYSET_GLOBAL. That initial value allows your protection gates to work even before
you have constructed your kernel and hardware keysets, although they would grant the code
following them global access to memory until after the hardware keysets have been properly
initialized. If your extension accepts and queues data for future asynchronous access, you
might also need to use HKEYSET_GLOBAL, but only if this data is allowed to be arbitrarily
key-protected by your callers. Use of the global keyset should be strictly minimized.
If you want to be certain that a hardware keyset is not used unexpectedly, statically initialize it
to HKEYSET_INVALID. A replace gate with this hardware keyset would revoke all access to
memory and cause a DSI almost immediately.
Your protection gates protect kernel data and the data of other modules from many of the
accidental overlays that might originate in your extension. It should not be necessary to
change any of the logic of your module to become key safe. But your module's own data
remains unprotected. The next step is to protect your kernel extension.
Key-protected kernel extension
A key-protected kernel extension goes beyond key safe; it identifies and protects its own
private data, as well as data in other domains, from accidental access. This protection can be
86 IBM AIX Continuous Availability Features