1. 20 Jun, 2019 2 commits
  2. 05 Jun, 2019 1 commit
  3. 21 May, 2019 1 commit
    • Thomas Gleixner's avatar
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 13 · 1ccea77e
      Thomas Gleixner authored
      
      
      Based on 2 normalized pattern(s):
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details you
        should have received a copy of the gnu general public license along
        with this program if not see http www gnu org licenses
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version this program is distributed in the
        hope that it will be useful but without any warranty without even
        the implied warranty of merchantability or fitness for a particular
        purpose see the gnu general public license for more details [based]
        [from] [clk] [highbank] [c] you should have received a copy of the
        gnu general public license along with this program if not see http
        www gnu org licenses
      
      extracted by the scancode license scanner the SPDX license identifier
      
        GPL-2.0-or-later
      
      has been chosen to replace the boilerplate/reference in 355 file(s).
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarJilayne Lovejoy <opensource@jilayne.com>
      Reviewed-by: default avatarSteve Winslow <swinslow@gmail.com>
      Reviewed-by: default avatarAllison Randal <allison@lohutok.net>
      Cc: linux-spdx@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190519154041.837383322@linutronix.de
      
      
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ccea77e
  4. 29 Apr, 2019 1 commit
    • Thomas Gleixner's avatar
      livepatch: Simplify stack trace retrieval · 25e39e32
      Thomas Gleixner authored
      
      
      Replace the indirection through struct stack_trace by using the storage
      array based interfaces.
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Acked-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: linux-mm@kvack.org
      Cc: David Rientjes <rientjes@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: kasan-dev@googlegroups.com
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Akinobu Mita <akinobu.mita@gmail.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: iommu@lists.linux-foundation.org
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: Marek Szyprowski <m.szyprowski@samsung.com>
      Cc: Johannes Thumshirn <jthumshirn@suse.de>
      Cc: David Sterba <dsterba@suse.com>
      Cc: Chris Mason <clm@fb.com>
      Cc: Josef Bacik <josef@toxicpanda.com>
      Cc: linux-btrfs@vger.kernel.org
      Cc: dm-devel@redhat.com
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: intel-gfx@lists.freedesktop.org
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: dri-devel@lists.freedesktop.org
      Cc: David Airlie <airlied@linux.ie>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
      Cc: linux-arch@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190425094803.437950229@linutronix.de
      25e39e32
  5. 06 Feb, 2019 1 commit
  6. 16 Jan, 2019 2 commits
    • Miroslav Benes's avatar
      livepatch: Remove signal sysfs attribute · 0b3d5279
      Miroslav Benes authored
      
      
      The fake signal is send automatically now. We can rely on it completely
      and remove the sysfs attribute.
      
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      0b3d5279
    • Miroslav Benes's avatar
      livepatch: Send a fake signal periodically · cba82dea
      Miroslav Benes authored
      
      
      An administrator may send a fake signal to all remaining blocking tasks
      of a running transition by writing to
      /sys/kernel/livepatch/<patch>/signal attribute. Let's do it
      automatically after 15 seconds. The timeout is chosen deliberately. It
      gives the tasks enough time to transition themselves.
      
      Theoretically, sending it once should be more than enough. However,
      every task must get outside of a patched function to be successfully
      transitioned. It could prove not to be simple and resending could be
      helpful in that case.
      
      A new workqueue job could be a cleaner solution to achieve it, but it
      could also introduce deadlocks and cause more headaches with
      synchronization and cancelling.
      
      [jkosina@suse.cz: removed added newline]
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      cba82dea
  7. 11 Jan, 2019 5 commits
    • Petr Mladek's avatar
      livepatch: Remove Nop structures when unused · d697bad5
      Petr Mladek authored
      
      
      Replaced patches are removed from the stack when the transition is
      finished. It means that Nop structures will never be needed again
      and can be removed. Why should we care?
      
        + Nop structures give the impression that the function is patched
          even though the ftrace handler has no effect.
      
        + Ftrace handlers do not come for free. They cause slowdown that might
          be visible in some workloads. The ftrace-related slowdown might
          actually be the reason why the function is no longer patched in
          the new cumulative patch. One would expect that cumulative patch
          would help solve these problems as well.
      
        + Cumulative patches are supposed to replace any earlier version of
          the patch. The amount of NOPs depends on which version was replaced.
          This multiplies the amount of scenarios that might happen.
      
          One might say that NOPs are innocent. But there are even optimized
          NOP instructions for different processors, for example, see
          arch/x86/kernel/alternative.c. And klp_ftrace_handler() is much
          more complicated.
      
        + It sounds natural to clean up a mess that is no longer needed.
          It could only be worse if we do not do it.
      
      This patch allows to unpatch and free the dynamic structures independently
      when the transition finishes.
      
      The free part is a bit tricky because kobject free callbacks are called
      asynchronously. We could not wait for them easily. Fortunately, we do
      not have to. Any further access can be avoided by removing them from
      the dynamic lists.
      
      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>
      d697bad5
    • Jason Baron's avatar
      livepatch: Add atomic replace · e1452b60
      Jason Baron authored
      
      
      Sometimes we would like to revert a particular fix. Currently, this
      is not easy because we want to keep all other fixes active and we
      could revert only the last applied patch.
      
      One solution would be to apply new patch that implemented all
      the reverted functions like in the original code. It would work
      as expected but there will be unnecessary redirections. In addition,
      it would also require knowing which functions need to be reverted at
      build time.
      
      Another problem is when there are many patches that touch the same
      functions. There might be dependencies between patches that are
      not enforced on the kernel side. Also it might be pretty hard to
      actually prepare the patch and ensure compatibility with the other
      patches.
      
      Atomic replace && cumulative patches:
      
      A better solution would be to create cumulative patch and say that
      it replaces all older ones.
      
      This patch adds a new "replace" flag to struct klp_patch. When it is
      enabled, a set of 'nop' klp_func will be dynamically created for all
      functions that are already being patched but that will no longer be
      modified by the new patch. They are used as a new target during
      the patch transition.
      
      The idea is to handle Nops' structures like the static ones. When
      the dynamic structures are allocated, we initialize all values that
      are normally statically defined.
      
      The only exception is "new_func" in struct klp_func. It has to point
      to the original function and the address is known only when the object
      (module) is loaded. Note that we really need to set it. The address is
      used, for example, in klp_check_stack_func().
      
      Nevertheless we still need to distinguish the dynamically allocated
      structures in some operations. For this, we add "nop" flag into
      struct klp_func and "dynamic" flag into struct klp_object. They
      need special handling in the following situations:
      
        + The structures are added into the lists of objects and functions
          immediately. In fact, the lists were created for this purpose.
      
        + The address of the original function is known only when the patched
          object (module) is loaded. Therefore it is copied later in
          klp_init_object_loaded().
      
        + The ftrace handler must not set PC to func->new_func. It would cause
          infinite loop because the address points back to the beginning of
          the original function.
      
        + The various free() functions must free the structure itself.
      
      Note that other ways to detect the dynamic structures are not considered
      safe. For example, even the statically defined struct klp_object might
      include empty funcs array. It might be there just to run some callbacks.
      
      Also note that the safe iterator must be used in the free() functions.
      Otherwise already freed structures might get accessed.
      
      Special callbacks handling:
      
      The callbacks from the replaced patches are _not_ called by intention.
      It would be pretty hard to define a reasonable semantic and implement it.
      
      It might even be counter-productive. The new patch is cumulative. It is
      supposed to include most of the changes from older patches. In most cases,
      it will not want to call pre_unpatch() post_unpatch() callbacks from
      the replaced patches. It would disable/break things for no good reasons.
      Also it should be easier to handle various scenarios in a single script
      in the new patch than think about interactions caused by running many
      scripts from older patches. Not to say that the old scripts even would
      not expect to be called in this situation.
      
      Removing replaced patches:
      
      One nice effect of the cumulative patches is that the code from the
      older patches is no longer used. Therefore the replaced patches can
      be removed. It has several advantages:
      
        + Nops' structs will no longer be necessary and might be removed.
          This would save memory, restore performance (no ftrace handler),
          allow clear view on what is really patched.
      
        + Disabling the patch will cause using the original code everywhere.
          Therefore the livepatch callbacks could handle only one scenario.
          Note that the complication is already complex enough when the patch
          gets enabled. It is currently solved by calling callbacks only from
          the new cumulative patch.
      
        + The state is clean in both the sysfs interface and lsmod. The modules
          with the replaced livepatches might even get removed from the system.
      
      Some people actually expected this behavior from the beginning. After all
      a cumulative patch is supposed to "completely" replace an existing one.
      It is like when a new version of an application replaces an older one.
      
      This patch does the first step. It removes the replaced patches from
      the list of patches. It is safe. The consistency model ensures that
      they are no longer used. By other words, each process works only with
      the structures from klp_transition_patch.
      
      The removal is done by a special function. It combines actions done by
      __disable_patch() and klp_complete_transition(). But it is a fast
      track without all the transaction-related stuff.
      
      Signed-off-by: default avatarJason Baron <jbaron@akamai.com>
      [pmladek@suse.com: Split, reuse existing code, simplified]
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Miroslav Benes <mbenes@suse.cz>
      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>
      e1452b60
    • 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>
      958ef1e3
    • Petr Mladek's avatar
      livepatch: Don't block the removal of patches loaded after a forced transition · 68007289
      Petr Mladek authored
      
      
      module_put() is currently never called in klp_complete_transition() when
      klp_force is set. As a result, we might keep the reference count even when
      klp_enable_patch() fails and klp_cancel_transition() is called.
      
      This might give the impression that a module might get blocked in some
      strange init state. Fortunately, it is not the case. The reference count
      is ignored when mod->init fails and erroneous modules are always removed.
      
      Anyway, this might be confusing. Instead, this patch moves
      the global klp_forced flag into struct klp_patch. As a result,
      we block only modules that might still be in use after a forced
      transition. Newly loaded livepatches might be eventually completely
      removed later.
      
      It is not a big deal. But the code is at least consistent with
      the reality.
      
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Acked-by: default avatarJoe Lawrence <joe.lawrence@redhat.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>
      68007289
    • Petr Mladek's avatar
      livepatch: Change unsigned long old_addr -> void *old_func in struct klp_func · 19514910
      Petr Mladek authored
      
      
      The address of the to be patched function and new function is stored
      in struct klp_func as:
      
      	void *new_func;
      	unsigned long old_addr;
      
      The different naming scheme and type are derived from the way
      the addresses are set. @old_addr is assigned at runtime using
      kallsyms-based search. @new_func is statically initialized,
      for example:
      
        static struct klp_func funcs[] = {
      	{
      		.old_name = "cmdline_proc_show",
      		.new_func = livepatch_cmdline_proc_show,
      	}, { }
        };
      
      This patch changes unsigned long old_addr -> void *old_func. It removes
      some confusion when these address are later used in the code. It is
      motivated by a followup patch that adds special NOP struct klp_func
      where we want to assign func->new_func = func->old_addr respectively
      func->new_func = func->old_func.
      
      This patch does not modify the existing behavior.
      
      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 avatarJoe Lawrence <joe.lawrence@redhat.com>
      Acked-by: default avatarAlice Ferrazzi <alice.ferrazzi@gmail.com>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      19514910
  8. 01 Dec, 2018 1 commit
  9. 16 Jul, 2018 1 commit
  10. 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
                      2i
                      3
      
      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>
      d0807da7
  11. 07 Dec, 2017 1 commit
    • Miroslav Benes's avatar
      livepatch: force transition to finish · c99a2be7
      Miroslav Benes authored
      
      
      If a task sleeps in a set of patched functions uninterruptedly, it could
      block the whole transition indefinitely.  Thus it may be useful to clear
      its TIF_PATCH_PENDING to allow the process to finish.
      
      Admin can do that now by writing to force sysfs attribute in livepatch
      sysfs directory. TIF_PATCH_PENDING is then cleared for all tasks and the
      transition can finish successfully.
      
      Important note! Administrator should not use this feature without a
      clearance from a patch distributor. It must be checked that by doing so
      the consistency model guarantees are not violated. Removal (rmmod) of
      patch modules is permanently disabled when the feature is used. It
      cannot be guaranteed there is no task sleeping in such module.
      
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Acked-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      c99a2be7
  12. 04 Dec, 2017 1 commit
    • Miroslav Benes's avatar
      livepatch: send a fake signal to all blocking tasks · 43347d56
      Miroslav Benes authored
      
      
      Live patching consistency model is of LEAVE_PATCHED_SET and
      SWITCH_THREAD. This means that all tasks in the system have to be marked
      one by one as safe to call a new patched function. Safe means when a
      task is not (sleeping) in a set of patched functions. That is, no
      patched function is on the task's stack. Another clearly safe place is
      the boundary between kernel and userspace. The patching waits for all
      tasks to get outside of the patched set or to cross the boundary. The
      transition is completed afterwards.
      
      The problem is that a task can block the transition for quite a long
      time, if not forever. It could sleep in a set of patched functions, for
      example.  Luckily we can force the task to leave the set by sending it a
      fake signal, that is a signal with no data in signal pending structures
      (no handler, no sign of proper signal delivered). Suspend/freezer use
      this to freeze the tasks as well. The task gets TIF_SIGPENDING set and
      is woken up (if it has been sleeping in the kernel before) or kicked by
      rescheduling IPI (if it was running on other CPU). This causes the task
      to go to kernel/userspace boundary where the signal would be handled and
      the task would be marked as safe in terms of live patching.
      
      There are tasks which are not affected by this technique though. The
      fake signal is not sent to kthreads. They should be handled differently.
      They can be woken up so they leave the patched set and their
      TIF_PATCH_PENDING can be cleared thanks to stack checking.
      
      For the sake of completeness, if the task is in TASK_RUNNING state but
      not currently running on some CPU it doesn't get the IPI, but it would
      eventually handle the signal anyway. Second, if the task runs in the
      kernel (in TASK_RUNNING state) it gets the IPI, but the signal is not
      handled on return from the interrupt. It would be handled on return to
      the userspace in the future when the fake signal is sent again. Stack
      checking deals with these cases in a better way.
      
      If the task was sleeping in a syscall it would be woken by our fake
      signal, it would check if TIF_SIGPENDING is set (by calling
      signal_pending() predicate) and return ERESTART* or EINTR. Syscalls with
      ERESTART* return values are restarted in case of the fake signal (see
      do_signal()). EINTR is propagated back to the userspace program. This
      could disturb the program, but...
      
      * each process dealing with signals should react accordingly to EINTR
        return values.
      * syscalls returning EINTR happen to be quite common situation in the
        system even if no fake signal is sent.
      * freezer sends the fake signal and does not deal with EINTR anyhow.
        Thus EINTR values are returned when the system is resumed.
      
      The very safe marking is done in architectures' "entry" on syscall and
      interrupt/exception exit paths, and in a stack checking functions of
      livepatch.  TIF_PATCH_PENDING is cleared and the next
      recalc_sigpending() drops TIF_SIGPENDING. In connection with this, also
      call klp_update_patch_state() before do_signal(), so that
      recalc_sigpending() in dequeue_signal() can clear TIF_PATCH_PENDING
      immediately and thus prevent a double call of do_signal().
      
      Note that the fake signal is not sent to stopped/traced tasks. Such task
      prevents the patching to finish till it continues again (is not traced
      anymore).
      
      Last, sending the fake signal is not automatic. It is done only when
      admin requests it by writing 1 to signal sysfs attribute in livepatch
      sysfs directory.
      
      Signed-off-by: default avatarMiroslav Benes <mbenes@suse.cz>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: x86@kernel.org
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      43347d56
  13. 19 Oct, 2017 3 commits
  14. 20 Jun, 2017 1 commit
    • Petr Mladek's avatar
      livepatch: Fix stacking of patches with respect to RCU · 842c0884
      Petr Mladek authored
      
      
      rcu_read_(un)lock(), list_*_rcu(), and synchronize_rcu() are used for a secure
      access and manipulation of the list of patches that modify the same function.
      In particular, it is the variable func_stack that is accessible from the ftrace
      handler via struct ftrace_ops and klp_ops.
      
      Of course, it synchronizes also some states of the patch on the top of the
      stack, e.g. func->transition in klp_ftrace_handler.
      
      At the same time, this mechanism guards also the manipulation of
      task->patch_state. It is modified according to the state of the transition and
      the state of the process.
      
      Now, all this works well as long as RCU works well. Sadly livepatching might
      get into some corner cases when this is not true. For example, RCU is not
      watching when rcu_read_lock() is taken in idle threads.  It is because they
      might sleep and prevent reaching the grace period for too long.
      
      There are ways how to make RCU watching even in idle threads, see
      rcu_irq_enter(). But there is a small location inside RCU infrastructure when
      even this does not work.
      
      This small problematic location can be detected either before calling
      rcu_irq_enter() by rcu_irq_enter_disabled() or later by rcu_is_watching().
      Sadly, there is no safe way how to handle it.  Once we detect that RCU was not
      watching, we might see inconsistent state of the function stack and the related
      variables in klp_ftrace_handler(). Then we could do a wrong decision, use an
      incompatible implementation of the function and break the consistency of the
      system. We could warn but we could not avoid the damage.
      
      Fortunately, ftrace has similar problems and they seem to be solved well there.
      It uses a heavy weight implementation of some RCU operations. In particular, it
      replaces:
      
        + rcu_read_lock() with preempt_disable_notrace()
        + rcu_read_unlock() with preempt_enable_notrace()
        + synchronize_rcu() with schedule_on_each_cpu(sync_work)
      
      My understanding is that this is RCU implementation from a stone age. It meets
      the core RCU requirements but it is rather ineffective. Especially, it does not
      allow to batch or speed up the synchronize calls.
      
      On the other hand, it is very trivial. It allows to safely trace and/or
      livepatch even the RCU core infrastructure.  And the effectiveness is a not a
      big issue because using ftrace or livepatches on productive systems is a rare
      operation.  The safety is much more important than a negligible extra load.
      
      Note that the alternative implementation follows the RCU principles. Therefore,
           we could and actually must use list_*_rcu() variants when manipulating the
           func_stack.  These functions allow to access the pointers in the right
           order and with the right barriers. But they do not use any other
           information that would be set only by rcu_read_lock().
      
      Also note that there are actually two problems solved in ftrace:
      
      First, it cares about the consistency of RCU read sections.  It is being solved
      the way as described and used in this patch.
      
      Second, ftrace needs to make sure that nobody is inside the dynamic trampoline
      when it is being freed. For this, it also calls synchronize_rcu_tasks() in
      preemptive kernel in ftrace_shutdown().
      
      Livepatch has similar problem but it is solved by ftrace for free.
      klp_ftrace_handler() is a good guy and never sleeps. In addition, it is
      registered with FTRACE_OPS_FL_DYNAMIC. It causes that
      unregister_ftrace_function() calls:
      
      	* schedule_on_each_cpu(ftrace_sync) - always
      	* synchronize_rcu_tasks() - in preemptive kernel
      
      The effect is that nobody is neither inside the dynamic trampoline nor inside
      the ftrace handler after unregister_ftrace_function() returns.
      
      [jkosina@suse.cz: reformat changelog, fix comment]
      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>
      842c0884
  15. 11 Apr, 2017 1 commit
  16. 08 Mar, 2017 3 commits
    • Jiri Kosina's avatar
      livepatch: make klp_mutex proper part of API · 10517429
      Jiri Kosina authored
      
      
      klp_mutex is shared between core.c and transition.c, and as such would
      rather be properly located in a header so that we don't have to play
      'extern' games from .c sources.
      
      This also silences sparse warning (wrongly) suggesting that klp_mutex
      should be defined static.
      
      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>
      10517429
    • 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
      https://lkml.kernel.org/r/1464018848-4303-1-git-send-email-pmladek@suse.com
      
      
      
      [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>
      3ec24776
    • 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
            IRQ.
         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
            HAVE_RELIABLE_STACKTRACE.
      
      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.cz
      
      
      
      Signed-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>
      d83a7cb3