Livepatch Background

Livepatch Related Work

From KShot¹

Existing live patching focuses on open-source operating systems, mainly Linux.
For example, Ksplice ², kpatch ³, and kGraft ⁴ can effectively patch security vulnerabilities without causing a significant downtime.
Kpatch and Ksplice both stop the running OS and ensure that none of the processes are affected by changes induced by patched functions.
Specifically, kpatch replaces the whole functions with patch ones, and Ksplice patches individual instructions instead of functions.
kGraft patches vulnerabilities at function level, but does not need to stop the running processes.
It maintains the original and patched function simultaneously and decides which one to execute by monitoring the state of processes, potentially inducing incorrect behavior or consuming additional storage.
These methods cannot address changes to data structures.
To address this limitation, KUP ⁵ replaces the whole kernel with a patched version, but uses checkpoint-and-restore to maintain application state consistency.
However, it checkpoints all the user processes, leading to large CPU and memory overhead.
KARMA ⁶ uses a kernel module to replace vulnerable instructions that it identifies from a given patch diff.

In addition, several live updating methods have been integrated into operating systems, like Canonical Livepatch Service ⁷ in Ubuntu, and Proteos ⁸ on MINIX 3, which can update new components if the patch is small. However, these methods still rely on the trustworthy operation of the target OS, so potential kernel-level attacks may tamper with the live patching operation, leading to system failure. KSHOT addresses this by leveraging a TEE to reliably patch the target kernel with a smaller TCB and low total overhead.

Preliminary

Hot Patch history ⁹

 DDJ: And when you had to hot-patch in flight?

GR: That's standard procedure. You always build in the ability to change it.

DDJ: Just in case.

GR: Just in case, but JPL and a bunch of decent-sized companies have had the problem where you can't get all the software done in time for launch. You always make sure you build the capability to change things.

I. kprobe

A kernel probe is a set of handlers placed on a certain instruction address. There are two types of probes in the kernel as of now, called “KProbes” and “JProbes.”

KProbes is a debugging mechanism for the Linux kernel which can also be used for monitoring events inside a production system.
A KProbe is defined by a pre-handler and a post-handler. When a KProbe is installed at a particular instruction and that instruction is executed, the pre-handler is executed just before the execution of the probed instruction. Similarly, the post-handler is executed just after the execution of the probed instruction.
Users can insert their own probe inside a running kernel by writing a kernel module which implements the pre-handler and the post-handler for the probe. In case a fault occurs while executing a probe handler function, the user can handle the fault by defining a fault-handler and passing its address in struct kprobe.
KProbes heavily depends on processor architecture specific features and uses slightly different mechanisms depending on the architecture on which it’s being executed.
KProbes is available on the following architectures however: ppc64, x86_64, sparc64 and i386.

JProbes are used to get access to a kernel function’s arguments at runtime. A JProbe is defined by a JProbe handler with the same prototype as that of the function whose arguments are to be accessed. When the probed function is executed the control is first transferred to the user-defined JProbe handler, followed by the transfer of execution to the original function.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ns3IuvGf-1620477632848)(https://static.lwn.net/images/ns/kernel/KProbesArchitecture.png)]
The figure above describes the architecture of KProbes. On the x86, KProbes makes use of the exception handling mechanisms and modifies the standard breakpoint, debug and a few other exception handlers for its own purpose. Most of the handling of the probes is done in the context of the breakpoint and the debug exception handlers which make up the KProbes architecture dependent layer. The KProbes architecture independent layer is the KProbes manager which is used to register and unregister probes. Users provide probe handlers in kernel modules which register probes through the KProbes manager.

Interface

• Data Structure

/*<linux/kprobes.h>*/
struct kprobe {
   
    struct hlist_node hlist;                    /* Internal */
    kprobe_opcode_t addr;                       /* Address of probe */
    kprobe_pre_handler_t pre_handler;           /* Address of pre-handler */
    kprobe_post_handler_t post_handler;         /* Address of post-handler */
    kprobe_fault_handler_t fault_handler;       /* Address of fault handler */
    kprobe_break_handler_t break_handler;       /* Internal */
    kprobe_opcode_t opcode;                     /* Internal */        
    kprobe_opcode_t insn[MAX_INSN_SIZE];        /* Internal */
};

struct jprobe {
   
    struct kprobe kp;
    kprobe_opcode_t *entry; 	/* user-defined JProbe handler address */
};

• Register Method

typedef int (*kprobe_pre_handler_t)(struct kprobe*, struct pt_regs*)