The kernel pipes is a standard set of pipes that is created during the kernel initialization, before the first process is ever launched. They are used to request special operations performed by the kernel such as creating and manipulating processes or yielding CPU to another process in the system. There are no kernel calls beside the three ones that are used to pass messages along the pipes and to close the pipe handles.
Each of these pipes has a standardized name for its handle (not a standardized handle, see here for more informations about reasons why "standard handles" and the like are not used) which is used in the source code to refer to its handle each time the need for that pipe arises.
Actually these "pipes" are not pipes at all. They have only one end to which a handle is provided and the other end is handled directly by the kernel, usually even without forcing a thread switch (so this handling is not much less effective than having the functionality being handled by a direct kernel call). However these differences are not visible from the side of the processes trying to communicate through them or to manipulate handles referring to their only ends (actually there is no way for any process but the first one to know whether the particular kernel pipe is a "genuine" one).
A standard kernel API involves the kernel calls being used to request special operations from the kernel directly. For example there is a kernel call to create a process or even kernel calls for manipulating data in files and manipulating files and directories.
The problem occurs when another process (called supervisor) needs to watch what is a process (called supervised process) doing. And the problem becomes even worse when the supervisor needs to alter what the kernel calls requested by the supervised process do and what they return to the supervised process. Usually special solutions like ptrace must be implemented in the kernel to allow this, which complicate the kernel (thus making it less stable) and usually are usable only in tight scenarios (for example ptrace is designed to be used for debuggers and as such is hard to use for example to provide a fake filesystem view to the supervised process).
By contrast, under the Chaos kernel, by merely interposing a process between the kernel and the supervised process we can make the process being its supervisor. The supervisor then can do everything on the "kernel calls" made by the process and the process cannot detect this since the kernel pipes are completely interchangeable for ordinary pipes and even are indistinguishable from them. There is no need to modify the kernel itself in order to make this supervision work, there is not even a need to get a special permission from the kernel to do this kind of supervision nor the need to inform the kernel about it.
The interchangeability of the kernel pipe handles with their "normal" counterparts can also be exploited to add other functionality (such as process enumeration and access control) on top of the bare kernel services provided on the "genuine" kernel pipe handles. This allows even more offloading of the work from the kernel to processes resulting in even more lightweight kernel.
The standard kernel pipe names are shown below:
??? TO BE DOCUMENTED ???