[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Live patching of Debian Kernel



Hey!

After the presentation of Ben about the new features of Linux, I have
looked a bit at how the live patching could be used. I am just
presenting what I have discovered, it is likely that I drop the ball
just here.

I have tried kpatch only.

 1. We need to enable both CONFIG_KALLSYMS_ALL and CONFIG_LIVEPATCH (the
    first is needed by the second but is also needed for itself). This
    was already asked in #660288 but wasn't done due to the context.

To avoid reocmpiling the whole official Debian kernel repeatedly on my
laptop, I have then switched to a vanilla 4.1 kernel with far less
options.

 2. Despite the documentation, it is possible to compile the kpatch
    module without running the kernel to be patched. Just "make
    KPATCH_BUILD=/path/to/kernel/source". This also builds the tools to
    build the patch and to load the patch.

 3. Building the patch can also be done without running the kernel to
    patch: "kpatch-build" also accepts the path to the kernel
    source. Just "./kpatch-build/kpatch-build -s /path/to/kernel/source
    patch-to-apply.patch".

 4. Currently, kpatch wants to use set_memory_rw/ro. Those have been
    unexported in 4.1. The appropriate patch could just be reverted:

       http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6bbb614ec478961c7443086bdf7fd6784479c14a
       https://github.com/dynup/kpatch/issues/496

After this step, we have two .ko files (one for kpatch and one for the
patch we want). The "kpatch" utils just loads the module. We can keep it
or just load the appropriate modules ourselves (in postinst, after a
debconf question, "this kernel fixes some vulnerabilities and provides
patches for your current kernel, would you like to apply them?").

For testing, I have tried the patch fixing CVE-2015-5156. It loads
correctly but unfortunately, it doesn't seem to have any effect. But, it
modifies virtnet_probe(), so it is expected that nothing happens if the
module is loaded and maybe the patch is lost if the module is unloaded
then loaded. In all cases, no change in
/sys/class/net/eth0/device/features.

So, I have tried the provided example which trivially modifies the
output of /proc/meminfo. Unfortunately, the kernel panics on load. I
have reported the bug upstream:

 https://github.com/dynup/kpatch/issues/497

That's all. I didn't check kgraft. I didn't check if others have
provided "tested" patches for various CVE that would lessen the work.
-- 
Program defensively.
            - The Elements of Programming Style (Kernighan & Plauger)


Reply to: