| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 17 Nov 2014 08:54:50 -0600 From: Seth Jennings <sjenning@...hat.com> To: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Jiri Kosina <jkosina@...e.cz>, Vojtech Pavlik <vojtech@...e.cz>, Steven Rostedt <rostedt@...dmis.org>, Petr Mladek <pmladek@...e.cz>, Miroslav Benes <mbenes@...e.cz>, Christoph Hellwig <hch@...radead.org>, Greg KH <gregkh@...uxfoundation.org>, Andy Lutomirski <luto@...capital.net>, live-patching@...r.kernel.org, x86@...nel.org, kpatch@...hat.com, linux-kernel@...r.kernel.org Subject: Re: [PATCHv2 0/3] Kernel Live Patching On Mon, Nov 17, 2014 at 02:33:02PM +0900, Masami Hiramatsu wrote: > Hi Seth, > > (2014/11/17 10:29), Seth Jennings wrote: > > Changelog: > > > > Thanks for all the feedback! > > > > changes in v2: > > - rebase to next-20141113 > > - add copyright/license block to livepatch.h > > - add _LINUX prefix to header defines > > - replace semaphore with mutex > > - add LPC_ prefix to state enum > > - convert BUGs to WARNs and handle properly > > - change Kconfig default to n > > - remove [old|new] attrs from function sysfs dir (KASLR leak, no use) > > - disregard user provided old_addr if kernel uses KASLR > > - s/out/err for error path labels > > - s/unregister/disable for uniform terminology > > - s/lp/lpc for module notifier elements > > Hmm, btw, "LP" and "LPC" remind me line-printer and LPC bus :( > Can we use LKP (Live Kernel Patching) or KLP (Kernel Live Patching) instead ? Jiri S also mentioned this so I guess it is a common sentiment :) He suggested "lip" but I think I like "klp" better? Jiri S sound good? > > > - replace module ref'ing with unload notifier + mutex protection > > - adjust notifier priority to run before ftrace > > - make LIVE_PATCHING boolean (about to depend on arch stuff) > > For better handling x86-32, we'd better introduce ARCH_HAVE_LIVE_PATCHING and > avoid enabling LIVE_PATCHING on x86_32, then we can simplify arch/x86/kernel/livepatch.c. Will do. Thanks for the review! Seth > > Thank you, > > > - move x86-specific reloc code to arch/x86 > > - s/dynrela/reloc/ > > - add live patching sysfs documentation > > - add API function kernel-doc > > - TODO: kernel-doc for API structs once agreed upon > > > > Summary: > > > > This patchset implements an ftrace-based mechanism and kernel interface for > > doing live patching of kernel and kernel module functions. It represents the > > greatest common functionality set between kpatch [1] and kGraft [2] and can > > accept patches built using either method. This solution was discussed in the > > Live Patching Mini-conference at LPC 2014 [3]. > > > > The model consists of a live patching "core" that provides an interface for > > other "patch" kernel modules to register patches with the core. > > > > Patch modules contain the new function code and create an lp_patch structure > > containing the required data about what functions to patch, where the new code > > for each patched function resides, and in which kernel object (vmlinux or > > module) the function to be patch resides. The patch module then invokes the > > lp_register_patch() function to register with the core, then lp_enable_patch() > > to have the core redirect the execution paths using ftrace. > > > > An example patch module can be found here: > > https://github.com/spartacus06/livepatch/blob/master/patch/patch.c > > > > The live patching core creates a sysfs hierarchy for user-level access to live > > patching information. The hierarchy is structured like this: > > > > /sys/kernel/livepatch > > /sys/kernel/livepatch/<patch> > > /sys/kernel/livepatch/<patch>/enabled > > /sys/kernel/livepatch/<patch>/<object> > > /sys/kernel/livepatch/<patch>/<object>/<func> > > > > The old function is located using one of two methods: it is either provided by > > the patch module (only possible for a function in vmlinux) or kallsyms lookup. > > Symbol ambiguity results in a failure. > > > > The core takes a reference on the patch module itself to keep it from > > unloading. This is because, without a mechanism to ensure that no thread is > > currently executing in the patched function, we can not determine whether it is > > safe to unload the patch module. For this reason, unloading patch modules is > > currently not allowed. > > > > Disabling patches can be done using the "enabled" attribute of the patch: > > > > echo 0 > /sys/kernel/livepatch/<patch>/enabled > > > > If a patch module contains a patch for a module that is not currently loaded, > > there is nothing to patch so the core does nothing for that patch object. > > However, the core registers a module notifier that looks for COMING events so > > that if the module is ever loaded, it is immediately patched. If a module with > > patch code is removed, the notifier looks for GOING events and disables any > > patched functions for that object before it unloads. The notifier has a higher > > priority than that of the ftrace notifier so that it runs before the ftrace > > notifier for GOING events and we can cleanly unregister from ftrace. > > > > kpatch and kGraft each have their own mechanisms for ensuring system > > consistency during the patching process. This first version does not implement > > any consistency mechanism that ensures that old and new code do not run > > together. In practice, ~90% of CVEs are safe to apply in this way, since they > > simply add a conditional check. However, any function change that can not > > execute safely with the old version of the function can _not_ be safely applied > > for now. > > > > [1] https://github.com/dynup/kpatch > > [2] https://git.kernel.org/cgit/linux/kernel/git/jirislaby/kgraft.git/ > > [3] https://etherpad.fr/p/LPC2014_LivePatching > > > > Seth Jennings (3): > > kernel: add TAINT_LIVEPATCH > > kernel: add support for live patching > > kernel: add sysfs documentation for live patching > > > > Documentation/ABI/testing/sysfs-kernel-livepatch | 44 + > > Documentation/oops-tracing.txt | 2 + > > Documentation/sysctl/kernel.txt | 1 + > > MAINTAINERS | 13 + > > arch/x86/Kconfig | 2 + > > arch/x86/include/asm/livepatch.h | 38 + > > arch/x86/kernel/Makefile | 1 + > > arch/x86/kernel/livepatch.c | 83 ++ > > include/linux/kernel.h | 1 + > > include/linux/livepatch.h | 68 ++ > > kernel/Makefile | 1 + > > kernel/livepatch/Kconfig | 9 + > > kernel/livepatch/Makefile | 3 + > > kernel/livepatch/core.c | 999 +++++++++++++++++++++++ > > kernel/panic.c | 2 + > > 15 files changed, 1267 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-livepatch > > create mode 100644 arch/x86/include/asm/livepatch.h > > create mode 100644 arch/x86/kernel/livepatch.c > > create mode 100644 include/linux/livepatch.h > > create mode 100644 kernel/livepatch/Kconfig > > create mode 100644 kernel/livepatch/Makefile > > create mode 100644 kernel/livepatch/core.c > > > > > -- > Masami HIRAMATSU > Software Platform Research Dept. Linux Technology Research Center > Hitachi, Ltd., Yokohama Research Laboratory > E-mail: masami.hiramatsu.pt@...achi.com > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists