Atomic Replace and Cumulative Patches

Atomic Replace와 cumulative patch

여러 livepatch가 같은 function을 서로 다르게 변경하면 설치 순서를 정의해야 하고, 새 patch의 function 구현은 이전 patch 변경 위에 쌓여야 합니다. 같은 function을 여러 patch가 다르게 수정할수록 유지보수가 매우 어려워집니다.

`Atomic Replace`는 이 문제를 cumulative patch로 해결합니다. 새 cumulative patch는 이전 모든 livepatch에서 원하는 변경을 포함하고, 한 transition에서 이전 patch를 완전히 대체합니다.

===================================
Atomic Replace & Cumulative Patches
===================================

There might be dependencies between livepatches. If multiple patches need
to do different changes to the same function(s) then we need to define
an order in which the patches will be installed. And function implementations
from any newer livepatch must be done on top of the older ones.

This might become a maintenance nightmare. Especially when more patches
modified the same function in different ways.

An elegant solution comes with the feature called "Atomic Replace". It allows
creation of so called "Cumulative Patches". They include all wanted changes
from all older livepatches and completely replace them in one transition.

Usage
-----

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

사용법과 장점

Atomic replace는 `struct klp_patch`의 `.replace = true` flag로 활성화합니다. 예제 구조체는 `.mod = THIS_MODULE`, `.objs = objs`와 함께 replace flag를 설정합니다.

모든 process는 새 patch의 code만 사용하도록 migration되고, transition이 끝나면 이전 patch가 자동 disable됩니다. 새 cumulative patch가 더 이상 수정하지 않는 function의 ftrace handler도 투명하게 제거됩니다.

Livepatch 작성자는 cumulative patch source 하나만 유지하면서 fix나 feature를 추가·제거할 수 있어 일관성을 지키기 쉽습니다.

사용자는 transition 완료 뒤 마지막 patch만 system에 남길 수 있어 실제 사용 중인 code를 명확히 볼 수 있습니다. Runtime에 기능 중단 없이 update할 수 있다는 점을 제외하면 kernel behavior를 바꾸는 일반 module처럼 다룰 수 있습니다.

Atomic replace는 이전 patch의 일부 function을 원복하면서 다른 function을 upgrade하고, 더 이상 patch하지 않는 function의 core redirection 성능 비용을 제거하며, patch dependency에 대한 사용자 혼란을 줄입니다.

for example::

        static struct klp_patch patch = {
                .mod = THIS_MODULE,
                .objs = objs,
                .replace = true,
        };

All processes are then migrated to use the code only from the new patch.
Once the transition is finished, all older patches are automatically
disabled.

Ftrace handlers are transparently removed from functions that are no
longer modified by the new cumulative patch.

As a result, the livepatch authors might maintain sources only for one
cumulative patch. It helps to keep the patch consistent while adding or
removing various fixes or features.

Users could keep only the last patch installed on the system after
the transition to has finished. It helps to clearly see what code is
actually in use. Also the livepatch might then be seen as a "normal"
module that modifies the kernel behavior. The only difference is that
it can be updated at runtime without breaking its functionality.


Features
--------

제한과 callback·shadow variable 책임

Operation이 끝난 뒤 교체된 patch를 atomic하게 원래 상태로 복원하는 직접적인 방법은 없습니다. 배포하는 모든 livepatch에 `.replace`를 설정하면 이전 cumulative patch를 다시 추가하는 일이 해당 version으로 downgrade하는 것과 같아집니다.

이 downgrade는 livepatch가 patch·unpatch callback, `module_init()`, `module_exit()`에서 추가 상태 변경을 하지 않을 때 안전합니다. 교체된 patch는 transition이 forced가 아니었던 경우에만 제거 후 다시 load할 수 있습니다.

실행되는 patch·unpatch callback은 새 cumulative livepatch의 callback뿐입니다. 교체되는 이전 patch의 callback은 무시되므로 새 patch가 이전 patch를 올바르게 대체하는 데 필요한 모든 action을 책임져야 합니다.

새 cumulative patch를 더 오래된 patch로 대체하면 필요한 callback이 옛 patch에 없을 수 있어 위험합니다. 반대로 활성 patch 전체의 callback을 모두 실행하면 callback 순서와 상호작용을 관리하기 매우 어려우므로 새 patch만 실행하는 규칙이 여러 시나리오를 단순화합니다.

Shadow variable에는 특별한 자동 처리가 없습니다. 작성자가 cumulative patch 사이의 전달 규칙을 직접 정의해야 하며 `module_exit()`에서 무조건 제거해서는 안 됩니다.

권장 방식은 post-unpatch callback에서 shadow variable을 제거하는 것입니다. 이 callback은 livepatch가 정상적으로 disable된 경우에만 호출됩니다.

The atomic replace allows:

  - Atomically revert some functions in a previous patch while
    upgrading other functions.

  - Remove eventual performance impact caused by core redirection
    for functions that are no longer patched.

  - Decrease user confusion about dependencies between livepatches.


Limitations:
------------

  - 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.
    Then re-adding an older livepatch is equivalent to downgrading
    to that patch. This is safe as long as the livepatches do _not_ do
    extra modifications in (un)patching callbacks or in the module_init()
    or module_exit() functions, see below.

    Also note that the replaced patch can be removed and loaded again
    only when the transition was not forced.


  - 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
    that are necessary to properly replace any older patch.

    As a result, it might be dangerous to replace newer cumulative patches by
    older ones. The old livepatches might not provide the necessary callbacks.

    This might be seen as a limitation in some scenarios. But it makes life
    easier in many others. Only the new cumulative livepatch knows what
    fixes/features are added/removed and what special actions are necessary
    for a smooth transition.

    In any case, it would be a nightmare to think about the order of
    the various callbacks and their interactions if the callbacks from all
    enabled patches were called.


  - 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.

    A good practice might be to remove shadow variables in the post-unpatch
    callback. It is called only when the livepatch is properly disabled.