Description
The main purpose of the Linux Plumbers 2019 Live Patching microconference is to involve all stakeholders in open discussion about remaining issues that need to be solved in order to make live patching of the Linux kernel and the Linux userspace live patching feature complete.
The intention is to mainly focus on the features that have been proposed (some even with a preliminary implementation), but not yet finished, with the ultimate goal of sorting out the remaining issues.
This proposal follows up on the history of past LPC live patching microconferences that have been very useful and pushed the development forward a lot.
Currently proposed discussion/presentation topic proposals (we've not gone through "internal selection process yet") with tentatively confirmed attendance:
5 min Intro - What happened in kernel live patching over the last year
API for state changes made by callbacks [1][2]
source-based livepatch creation tooling [3][4]
klp-convert [5][6]
livepatch developers guide
userspace live patching
If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.
MC leads
Jiri Kosina jkosina@suse.cz and Josh Poimboeuf jpoimboe@redhat.com
-
Miroslav Beneš11/09/2019, 15:00
A short summary of a development in kernel live patching over the last year. There have been many improvements since LPC in Vancouver, but there are still some outstanding issues. Not all attendees might closely follow live-patching mailing list and therefore the talk should be a good starting point for the microconference.
Go to contribution page -
Miroslav Beneš11/09/2019, 15:10
Current livepatch implementation supports late patching of modules when they are loaded (and unpatching when unloaded). It has caused headaches and LPC microconference is a good opportunity to discuss the future of the feature. There were attempt to deny the module removal. Introduction of patch module dependencies could also simplify the code and issue a lot. On the other hand, such solutions...
Go to contribution page -
Nicolai Stange (SUSE)11/09/2019, 15:40
At last year's Live Patching MC, an approach to automating source based live patch creation had been proposed. The implementation made good progress since then, in particular an initial release of the "klp-ccp" utility has been published (https://github.com/SUSE/klp-ccp) recently. Its purpose is to handle the transformation of patched kernel parts into self-contained live patch source code...
Go to contribution page -
Mr Kamalesh Babulal11/09/2019, 16:10
A quick update on the objtool port on Power, what is the current state and
Go to contribution page
what more needs to be done. Also, discuss how do we integrate it upstream. -
Joe Lawrence (Red Hat)11/09/2019, 16:20
Over the past few years, kernel engineers have been busy implementing livepatch support features (the consistency model, atomic replace, shadow variables, etc.) to increase potential livepatch patch coverage. At the same time, more and more vendors have adopted livepatching to solve continuous uptime/update problems.
As the livepatch feature set grows and matures and demand for livepatch...
Go to contribution page -
Petr Mládek11/09/2019, 17:00
The discussion should focus on an API for handling state of changes made by callbacks. It was already discussed as a global state handling at the last LPC in Vancouver. New ideas have occurred since then. The discussion should also include patch versioning, stickiness and transition reversal.
Patches submitted upstream so...
Go to contribution page -
Joe Lawrence (Red Hat)11/09/2019, 17:30
The kernel already supports special livepatch relocation types enable several interesting livepatch modules use cases:
- Access to symbols outside of normal C scoping rules
- Deferred access to yet-to-be loaded kernel module symbols
- Support for architecture-specific special sections like altinstructions and paravirt instructions
Although the kernel supports loading livepatch modules...
Go to contribution page -
Mr Kamalesh Babulal11/09/2019, 18:00
Currently testing/stressing of livepatching infrastructure is limited to the creation of livepatching module for the reported CVE/Security issues. Continuous testing of the infrastructure is required, it can be achieved by randomly selecting the patch(s) posted over kernel mailing list to improve and fix the bugs seen in the infrastructure. I would like to discuss the in house framework used...
Go to contribution page -
Alice Ferrazzi11/09/2019, 18:15
Discussion about current live patch services and how we can make it more open and flexible.
Go to contribution page
How we can make more open source distributions use or make their own live patch services.
What we are still missing? and what we can share?
