1. 21 May, 2019 2 commits
  2. 25 Jan, 2019 1 commit
  3. 11 Jan, 2019 1 commit
    • Petr Mladek's avatar
      livepatch: Simplify API by removing registration step · 958ef1e3
      Petr Mladek authored
      The possibility to re-enable a registered patch was useful for immediate
      patches where the livepatch module had to stay until the system reboot.
      The improved consistency model allows to achieve the same result by
      unloading and loading the livepatch module again.
      Also we are going to add a feature called atomic replace. It will allow
      to create a patch that would replace all already registered patches.
      The aim is to handle dependent patches more securely. It will obsolete
      the stack of patches that helped to handle the dependencies so far.
      Then it might be unclear when a cumulative patch re-enabling is safe.
      It would be complicated to support the many modes. Instead we could
      actually make the API and code easier to understand.
      Therefore, remove the two step public API. All the checks and init calls
      are moved from klp_register_patch() to klp_enabled_patch(). Also the patch
      is automatically freed, including the sysfs interface when the transition
      to the disabled state is completed.
      As a result, there is never a disabled patch on the top of the stack.
      Therefore we do not need to check the stack in __klp_enable_patch().
      And we could simplify the check in __klp_disable_patch().
      Also the API and logic is much easier. It is enough to call
      klp_enable_patch() in module_init() call. The patch can be disabled
      by writing '0' into /sys/kernel/livepatch/<patch>/enabled. Then the module
      can be removed once the transition finishes and sysfs interface is freed.
      The only problem is how to free the structures and kobjects safely.
      The operation is triggered from the sysfs interface. We could not put
      the related kobject from there because it would cause lock inversion
      between klp_mutex and kernfs locks, see kn->count lockdep map.
      Therefore, offload the free task to a workqueue. It is perfectly fine:
        + The patch can no longer be used in the livepatch operations.
        + The module could not be removed until the free operation finishes
          and module_put() is called.
        + The operation is asynchronous already when the first
          klp_try_complete_transition() fails and another call
          is queued with a delay.
      Suggested-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  4. 18 Dec, 2018 1 commit
  5. 17 Apr, 2018 2 commits
    • Petr Mladek's avatar
      livepatch: Allow to call a custom callback when freeing shadow variables · 3b2c77d0
      Petr Mladek authored
      We might need to do some actions before the shadow variable is freed.
      For example, we might need to remove it from a list or free some data
      that it points to.
      This is already possible now. The user can get the shadow variable
      by klp_shadow_get(), do the necessary actions, and then call
      This patch allows to do it a more elegant way. The user could implement
      the needed actions in a callback that is passed to klp_shadow_free()
      as a parameter. The callback usually does reverse operations to
      the constructor callback that can be called by klp_shadow_*alloc().
      It is especially useful for klp_shadow_free_all(). There we need to do
      these extra actions for each found shadow variable with the given ID.
      Note that the memory used by the shadow variable itself is still released
      later by rcu callback. It is needed to protect internal structures that
      keep all shadow variables. But the destructor is called immediately.
      The shadow variable must not be access anyway after klp_shadow_free()
      is called. The user is responsible to protect this any suitable way.
      Be aware that the destructor is called under klp_shadow_lock. It is
      the same as for the contructor in klp_shadow_alloc().
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
    • Petr Mladek's avatar
      livepatch: Initialize shadow variables safely by a custom callback · e91c2518
      Petr Mladek authored
      The existing API allows to pass a sample data to initialize the shadow
      data. It works well when the data are position independent. But it fails
      miserably when we need to set a pointer to the shadow structure itself.
      Unfortunately, we might need to initialize the pointer surprisingly
      often because of struct list_head. It is even worse because the list
      might be hidden in other common structures, for example, struct mutex,
      struct wait_queue_head.
      For example, this was needed to fix races in ALSA sequencer. It required
      to add mutex into struct snd_seq_client. See commit b3defb79
      ("ALSA: seq: Make ioctls race-free") and commit d15d662e
      ("ALSA: seq: Fix racy pool initializations")
      This patch makes the API more safe. A custom constructor function and data
      are passed to klp_shadow_*alloc() functions instead of the sample data.
      Note that ctor_data are no longer a template for shadow->data. It might
      point to any data that might be necessary when the constructor is called.
      Also note that the constructor is called under klp_shadow_lock. It is
      an internal spin_lock that synchronizes alloc() vs. get() operations,
      see klp_shadow_get_or_alloc(). On one hand, this adds a risk of ABBA
      deadlocks. On the other hand, it allows to do some operations safely.
      For example, we could add the new structure into an existing list.
      This must be done only once when the structure is allocated.
      Reported-by: default avatarNicolai Stange <nstange@suse.de>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  6. 11 Jan, 2018 1 commit
    • Miroslav Benes's avatar
      livepatch: Remove immediate feature · d0807da7
      Miroslav Benes authored
      Immediate flag has been used to disable per-task consistency and patch
      all tasks immediately. It could be useful if the patch doesn't change any
      function or data semantics.
      However, it causes problems on its own. The consistency problem is
      currently broken with respect to immediate patches.
      func            a
      patches         1i
      When the patch 3 is applied, only 2i function is checked (by stack
      checking facility). There might be a task sleeping in 1i though. Such
      task is migrated to 3, because we do not check 1i in
      klp_check_stack_func() at all.
      Coming atomic replace feature would be easier to implement and more
      reliable without immediate.
      Thus, remove immediate feature completely and save us from the problems.
      Note that force feature has the similar problem. However it is
      considered as a last resort. If used, administrator should not apply any
      new live patches and should plan for reboot into an updated kernel.
      The architectures would now need to provide HAVE_RELIABLE_STACKTRACE to
      fully support livepatch.
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  7. 19 Oct, 2017 1 commit
    • Joe Lawrence's avatar
      livepatch: add (un)patch callbacks · 93862e38
      Joe Lawrence authored
      Provide livepatch modules a klp_object (un)patching notification
      mechanism.  Pre and post-(un)patch callbacks allow livepatch modules to
      setup or synchronize changes that would be difficult to support in only
      patched-or-unpatched code contexts.
      Callbacks can be registered for target module or vmlinux klp_objects,
      but each implementation is klp_object specific.
        - Pre-(un)patch callbacks run before any (un)patching transition
        - Post-(un)patch callbacks run once an object has been (un)patched and
          the klp_patch fully transitioned to its target state.
      Example use cases include modification of global data and registration
      of newly available services/handlers.
      See Documentation/livepatch/callbacks.txt for details and
      samples/livepatch/ for examples.
      Signed-off-by: Joe Lawrence's avatarJoe Lawrence <joe.lawrence@redhat.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  8. 14 Sep, 2017 1 commit
    • Joe Lawrence's avatar
      livepatch: introduce shadow variable API · 439e7271
      Joe Lawrence authored
      Add exported API for livepatch modules:
      that implement "shadow" variables, which allow callers to associate new
      shadow fields to existing data structures.  This is intended to be used
      by livepatch modules seeking to emulate additions to data structure
      See Documentation/livepatch/shadow-vars.txt for a summary of the new
      shadow variable API, including a few common use cases.
      See samples/livepatch/livepatch-shadow-* for example modules that
      demonstrate shadow variables.
      [jkosina@suse.cz: fix __klp_shadow_get_or_alloc() comment as spotted by
      Signed-off-by: Joe Lawrence's avatarJoe Lawrence <joe.lawrence@redhat.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  9. 08 Mar, 2017 2 commits
    • Josh Poimboeuf's avatar
      livepatch: allow removal of a disabled patch · 3ec24776
      Josh Poimboeuf authored
      Currently we do not allow patch module to unload since there is no
      method to determine if a task is still running in the patched code.
      The consistency model gives us the way because when the unpatching
      finishes we know that all tasks were marked as safe to call an original
      function. Thus every new call to the function calls the original code
      and at the same time no task can be somewhere in the patched code,
      because it had to leave that code to be marked as safe.
      We can safely let the patch module go after that.
      Completion is used for synchronization between module removal and sysfs
      infrastructure in a similar way to commit 942e4431 ("module: Fix
      mod->mkobj.kobj potentially freed too early").
      Note that we still do not allow the removal for immediate model, that is
      no consistency model. The module refcount may increase in this case if
      somebody disables and enables the patch several times. This should not
      cause any harm.
      With this change a call to try_module_get() is moved to
      __klp_enable_patch from klp_register_patch to make module reference
      counting symmetric (module_put() is in a patch disable path) and to
      allow to take a new reference to a disabled module when being enabled.
      Finally, we need to be very careful about possible races between
      klp_unregister_patch(), kobject_put() functions and operations
      on the related sysfs files.
      kobject_put(&patch->kobj) must be called without klp_mutex. Otherwise,
      it might be blocked by enabled_store() that needs the mutex as well.
      In addition, enabled_store() must check if the patch was not
      unregisted in the meantime.
      There is no need to do the same for other kobject_put() callsites
      at the moment. Their sysfs operations neither take the lock nor
      they access any data that might be freed in the meantime.
      There was an attempt to use kobjects the right way and prevent these
      races by design. But it made the patch definition more complicated
      and opened another can of worms. See
      [Thanks to Petr Mladek for improving the commit message.]
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
    • Josh Poimboeuf's avatar
      livepatch: change to a per-task consistency model · d83a7cb3
      Josh Poimboeuf authored
      Change livepatch to use a basic per-task consistency model.  This is the
      foundation which will eventually enable us to patch those ~10% of
      security patches which change function or data semantics.  This is the
      biggest remaining piece needed to make livepatch more generally useful.
      This code stems from the design proposal made by Vojtech [1] in November
      2014.  It's a hybrid of kGraft and kpatch: it uses kGraft's per-task
      consistency and syscall barrier switching combined with kpatch's stack
      trace switching.  There are also a number of fallback options which make
      it quite flexible.
      Patches are applied on a per-task basis, when the task is deemed safe to
      switch over.  When a patch is enabled, livepatch enters into a
      transition state where tasks are converging to the patched state.
      Usually this transition state can complete in a few seconds.  The same
      sequence occurs when a patch is disabled, except the tasks converge from
      the patched state to the unpatched state.
      An interrupt handler inherits the patched state of the task it
      interrupts.  The same is true for forked tasks: the child inherits the
      patched state of the parent.
      Livepatch uses several complementary approaches to determine when it's
      safe to patch tasks:
      1. The first and most effective approach is stack checking of sleeping
         tasks.  If no affected functions are on the stack of a given task,
         the task is patched.  In most cases this will patch most or all of
         the tasks on the first try.  Otherwise it'll keep trying
         periodically.  This option is only available if the architecture has
         reliable stacks (HAVE_RELIABLE_STACKTRACE).
      2. The second approach, if needed, is kernel exit switching.  A
         task is switched when it returns to user space from a system call, a
         user space IRQ, or a signal.  It's useful in the following cases:
         a) Patching I/O-bound user tasks which are sleeping on an affected
            function.  In this case you have to send SIGSTOP and SIGCONT to
            force it to exit the kernel and be patched.
         b) Patching CPU-bound user tasks.  If the task is highly CPU-bound
            then it will get patched the next time it gets interrupted by an
         c) In the future it could be useful for applying patches for
            architectures which don't yet have HAVE_RELIABLE_STACKTRACE.  In
            this case you would have to signal most of the tasks on the
            system.  However this isn't supported yet because there's
            currently no way to patch kthreads without
      3. For idle "swapper" tasks, since they don't ever exit the kernel, they
         instead have a klp_update_patch_state() call in the idle loop which
         allows them to be patched before the CPU enters the idle state.
         (Note there's not yet such an approach for kthreads.)
      All the above approaches may be skipped by setting the 'immediate' flag
      in the 'klp_patch' struct, which will disable per-task consistency and
      patch all tasks immediately.  This can be useful if the patch doesn't
      change any function or data semantics.  Note that, even with this flag
      set, it's possible that some tasks may still be running with an old
      version of the function, until that function returns.
      There's also an 'immediate' flag in the 'klp_func' struct which allows
      you to specify that certain functions in the patch can be applied
      without per-task consistency.  This might be useful if you want to patch
      a common function like schedule(), and the function change doesn't need
      consistency but the rest of the patch does.
      For architectures which don't have HAVE_RELIABLE_STACKTRACE, the user
      must set patch->immediate which causes all tasks to be patched
      immediately.  This option should be used with care, only when the patch
      doesn't change any function or data semantics.
      In the future, architectures which don't have HAVE_RELIABLE_STACKTRACE
      may be allowed to use per-task consistency if we can come up with
      another way to patch kthreads.
      The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
      is in transition.  Only a single patch (the topmost patch on the stack)
      can be in transition at a given time.  A patch can remain in transition
      indefinitely, if any of the tasks are stuck in the initial patch state.
      A transition can be reversed and effectively canceled by writing the
      opposite value to the /sys/kernel/livepatch/<patch>/enabled file while
      the transition is in progress.  Then all the tasks will attempt to
      converge back to the original patch state.
      [1] https://lkml.kernel.org/r/20141107140458.GA21774@suse.czSigned-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: Ingo Molnar <mingo@kernel.org>        # for the scheduler changes
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  10. 01 Apr, 2016 1 commit
    • Jessica Yu's avatar
      livepatch: reuse module loader code to write relocations · 425595a7
      Jessica Yu authored
      Reuse module loader code to write relocations, thereby eliminating the need
      for architecture specific relocation code in livepatch. Specifically, reuse
      the apply_relocate_add() function in the module loader to write relocations
      instead of duplicating functionality in livepatch's arch-dependent
      klp_write_module_reloc() function.
      In order to accomplish this, livepatch modules manage their own relocation
      sections (marked with the SHF_RELA_LIVEPATCH section flag) and
      livepatch-specific symbols (marked with SHN_LIVEPATCH symbol section
      index). To apply livepatch relocation sections, livepatch symbols
      referenced by relocs are resolved and then apply_relocate_add() is called
      to apply those relocations.
      In addition, remove x86 livepatch relocation code and the s390
      klp_write_module_reloc() function stub. They are no longer needed since
      relocation work has been offloaded to module loader.
      Lastly, mark the module as a livepatch module so that the module loader
      canappropriately identify and initialize it.
      Signed-off-by: default avatarJessica Yu <jeyu@redhat.com>
      Reviewed-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>   # for s390 changes
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  11. 04 Feb, 2015 1 commit
  12. 23 Dec, 2014 1 commit
  13. 22 Dec, 2014 1 commit