docs: livepatch: convert docs to ReST and rename to *.rst

		use this feature without a clearance from a patch

		distributor. Removal (rmmod) of patch modules is permanently

		disabled when the feature is used. See

		Documentation/livepatch/livepatch.txt for more information.

		Documentation/livepatch/livepatch.rst for more information.

What:		/sys/kernel/livepatch/<patch>/<object>

Date:		Nov 2014

Callbacks can be registered for the following livepatch actions:

  * Pre-patch    - before a klp_object is patched

  * Pre-patch

                 - before a klp_object is patched

  * Post-patch   - after a klp_object has been patched and is active

  * Post-patch

                 - after a klp_object has been patched and is active

                   across all tasks

  * Pre-unpatch  - before a klp_object is unpatched (ie, patched code is

  * Pre-unpatch

                 - before a klp_object is unpatched (ie, patched code is

                   active), used to clean up post-patch callback

                   resources

  * Post-unpatch - after a klp_object has been patched, all code has

  * Post-unpatch

                 - after a klp_object has been patched, all code has

                   been restored and no tasks are running patched code,

                   used to cleanup pre-patch callback resources

-----

The atomic replace can be enabled by setting "replace" flag in struct klp_patch,

for example:

for example::

	static struct klp_patch patch = {

		.mod = THIS_MODULE,

The atomic replace allows:

  + Atomically revert some functions in a previous patch while

  - Atomically revert some functions in a previous patch while

    upgrading other functions.

  + Remove eventual performance impact caused by core redirection

  - Remove eventual performance impact caused by core redirection

    for functions that are no longer patched.

  + Decrease user confusion about dependencies between livepatches.

  - Decrease user confusion about dependencies between livepatches.

Limitations:

------------

  + Once the operation finishes, there is no straightforward way

  - Once the operation finishes, there is no straightforward way

    to reverse it and restore the replaced patches atomically.

    A good practice is to set .replace flag in any released livepatch.

    only when the transition was not forced.

  + Only the (un)patching callbacks from the _new_ cumulative livepatch are

  - Only the (un)patching callbacks from the _new_ cumulative livepatch are

    executed. Any callbacks from the replaced patches are ignored.

    In other words, the cumulative patch is responsible for doing any actions

    enabled patches were called.

  + There is no special handling of shadow variables. Livepatch authors

  - There is no special handling of shadow variables. Livepatch authors

    must create their own rules how to pass them from one cumulative

    patch to the other. Especially that they should not blindly remove

    them in module_exit() functions.

:orphan:

===================

Kernel Livepatching

===================

.. toctree::

    :maxdepth: 1

    livepatch

    callbacks

    cumulative-patches

    module-elf-format

    shadow-vars

.. only::  subproject and html

   Indices

   =======

   * :ref:`genindex`

This document outlines basic information about kernel livepatching.

Table of Contents:

.. Table of Contents:

    1. Motivation

    2. Kprobes, Ftrace, Livepatching

to redirection of code execution; namely: kernel probes, function tracing,

and livepatching:

  + The kernel probes are the most generic. The code can be redirected by

  - The kernel probes are the most generic. The code can be redirected by

    putting a breakpoint instruction instead of any instruction.

  + The function tracer calls the code from a predefined location that is

  - The function tracer calls the code from a predefined location that is

    close to the function entry point. This location is generated by the

    compiler using the '-pg' gcc option.

  + Livepatching typically needs to redirect the code at the very beginning

  - Livepatching typically needs to redirect the code at the very beginning

    of the function entry before the function parameters or the stack

    are in any way modified.

might want to access functions or data from the original source file

that may only be locally accessible. This can be solved by a special

relocation section in the generated livepatch module, see

Documentation/livepatch/module-elf-format.txt for more details.

Documentation/livepatch/module-elf-format.rst for more details.

4.2. Metadata

The patch is described by several structures that split the information

into three levels:

  + struct klp_func is defined for each patched function. It describes

  - struct klp_func is defined for each patched function. It describes

    the relation between the original and the new implementation of a

    particular function.

    only for a particular object ( vmlinux or a kernel module ). Note that

    kallsyms allows for searching symbols according to the object name.

  + struct klp_object defines an array of patched functions (struct

  - struct klp_object defines an array of patched functions (struct

    klp_func) in the same object. Where the object is either vmlinux

    (NULL) or a module name.

    only when they are available.

  + struct klp_patch defines an array of patched objects (struct

  - struct klp_patch defines an array of patched objects (struct

    klp_object).

    This structure handles all patched functions consistently and eventually,

Second, livepatch enters into a transition state where tasks are converging

to the patched state. If an original function is patched for the first

time, a function specific struct klp_ops is created and an universal

ftrace handler is registered[*]. This stage is indicated by a value of '1'

ftrace handler is registered\ [#]_. This stage is indicated by a value of '1'

in /sys/kernel/livepatch/<name>/transition. For more information about

this process, see the "Consistency model" section.

Finally, once all tasks have been patched, the 'transition' value changes

to '0'.

[*] Note that functions might be patched multiple times. The ftrace handler

.. [#]

    Note that functions might be patched multiple times. The ftrace handler

    is registered only once for a given function. Further patches just add

    an entry to the list (see field `func_stack`) of the struct klp_ops.

    The right implementation is selected by the ftrace handler, see

freed when the related function is not modified by the new patch

and func_stack list becomes empty.

See Documentation/livepatch/cumulative-patches.txt for more details.

See Documentation/livepatch/cumulative-patches.rst for more details.

5.4. Disabling

The current Livepatch implementation has several limitations:

  + Only functions that can be traced could be patched.

  - Only functions that can be traced could be patched.

    Livepatch is based on the dynamic ftrace. In particular, functions

    implementing ftrace or the livepatch ftrace handler could not be

  + Livepatch works reliably only when the dynamic ftrace is located at

  - Livepatch works reliably only when the dynamic ftrace is located at

    the very beginning of the function.

    The function need to be redirected before the stack or the function

    this is handled on the ftrace level.

  + Kretprobes using the ftrace framework conflict with the patched

  - Kretprobes using the ftrace framework conflict with the patched

    functions.

    Both kretprobes and livepatches use a ftrace handler that modifies

    is rejected when the handler is already in use by the other.

  + Kprobes in the original function are ignored when the code is

  - Kprobes in the original function are ignored when the code is

    redirected to the new implementation.

    There is a work in progress to add warnings about this situation.