Session: It’s 2021. Why are we -still- rebooting for patches? A look at Live Patching.
IT Teams know the drill. New security bulletins, new issues, new patches to deploy. Schedule another maintenance operation and prepare for system downtime.
There is a better way to do things. Live patching has been around in the Linux Kernel for some time now, but adoption has not been ideal so far – either because of a lack of trust in the technology or just lack of awareness – or sysadmins just enjoy interrupting their workloads or users.
Live patching consists of two aspects. First, there has to be a mechanism for function redirection in the kernel. As in many things, the kernel actually provides three different subset of tools that provide this functionality – kprobes, fprobes and Livepatching. Secondly, Live Patching relies on a set of tools to generate the actual patches to deploy, replacing the old code with new one. This is arguably the most involved part: you need to fit your new code in the proper space, you can’t overwrite other unrelated code and you need to maintain compatibility with other functions. If you change your parameter list, for example, its game over – something will break in the worst possible way.
In this talk we’ll go over issues like Consistency model, patch generation, deployment mechanisms and identify situations that are ideal candidates for live patching instead of traditional patching operations.
