> On Wed, Mar 29, 2023 at 02:05:43PM +0200, Miroslav Benes wrote: >> Hi, >> >> we would like to organize Live Patching Microconference at Linux Plumbers >> 2023. The conference will take place in Richmond, VA, USA. 13-15 November. >> https://lpc.events/. The call for proposals has been opened so it is time >> to start the preparation on our side. >> >> You can find the proposal below. Comments are welcome. The list of topics >> is open, so feel free to add more. I tried to add key people to discuss >> the topics, but the list is not exhaustive. I would like to submit the >> proposal soonish even though the deadline is on 1 June. I assume that we >> can update the topics later. My plan is to also organize a proper Call for >> Topics after the submission and advertise it also on LKML. >> >> Last but not least it would be nice to have a co-runner of the show. Josh, >> Joe, any volunteer? :) >> >> Thank you >> Miroslav >> >> >> Proposal >> -------- >> The Live Patching microconference at Linux Plumbers 2023 aims to gather >> stakeholders and interested parties to discuss proposed features and >> outstanding issues in live patching. >> >> Live patching is a critical tool for maintaining system uptime and >> security by enabling fixes to be applied to running systems without the >> need for a reboot. The development of the infrastructure is an ongoing >> effort and while many problems have been resolved and features >> implemented, there are still open questions, some with already submitted >> patch sets, which need to be discussed. >> >> Live Patching microconferences at the previous Linux Plumbers >> conferences proved to be useful in this regard and helped us to find >> final solutions or at least promising directions to push the development >> forward. It includes for example a support for several architectures >> (ppc64le and s390x were added after x86_64), a late module patching and >> module dependencies and user space live patching. >> >> Currently proposed topics follow. The list is open though and more will >> be added during the regular Call for Topics. >> >> - klp-convert (as means to fix CET IBT limitations) and its >> upstreamability >> - shadow variables, global state transition >> - kselftests and the future direction of development >> - arm64 live patching > > I'm happy to talk about the kernel-side of arm64 live patching; it'd be good to > get in contact with anyone looking at the arm64 userspace side (e.g. > klp-convert). > > I have some topics which overlap between live-patching and general toolchain > bits and pieces, and I'm not sure if they'd be best suited here or in a > toolchain track, e.g. > > * How to avoid/minimize the need to reverse-engineer control flow for things > like ORC generation. > > On the arm64 side we're pretty averse to doing this to generate metadata for > unwinding (and we might not need to), but there are things objtool does today > that requires awareness of control-flow (e.g. forward-edge checks for noinstr > safety). > > Hopefully without a flamewar about DWARF... > > * Better compiler support for noinstr and similar properties. > > For example, noinstr functions are currently all noinline, and we can't > inline a noinstr function into a noinstr function, leading to a painful mix > of noinstr and __always_inline. Having a mechanism to allow noinstr code to > be inlined into other noinstr code would be nice. > > Likewise, whether we could somehow get compile-time warnings about unintended > calls from instrumentable code from noinstr code. > > * How is this going to work with rust? > > It's not clear to me whether/how things like ftrace, RELIABLE_STACKTRACE, and > live-patching are going to work with rust. We probably need to start looking > soon. > > I've Cc'd Nick, Jose, and Miguel, in case they have thoughts. We have indeed submitted a proposal for a Toolchains MC for Plumbers. I think the two first topics mentioned above (CFG in ELF and handling of noinstr functions) would definitely fit well in the Toolchains MC. As for Rust... we have the Rust GCC support and that would fit in the MC as well. We can surely invite some of the hackers working in the front-end. But maybe it would be better to have that discussion in a Rust MC, if there is gonna be one (Miguel?). For starters, I would make sure that the involved MCs (Live Patching, Toolchains, and an eventual Rust MC) do not overlap in the schedule. Then we could have these discussions in either microconferences. >> >> Key people >> >> - Josh Poimboeuf <jpoimboe@xxxxxxxxxx> >> - Jiri Kosina <jikos@xxxxxxxxxx> >> - Miroslav Benes <mbenes@xxxxxxx> >> - Petr Mladek <pmladek@xxxxxxxx> >> - Joe Lawrence <joe.lawrence@xxxxxxxxxx> >> - Nicolai Stange <nstange@xxxxxxx> >> - Marcos Paulo de Souza <mpdesouza@xxxxxxx> >> - Mark Rutland <mark.rutland@xxxxxxx> >> - Mark Brown <broonie@xxxxxxxxxx> >> >> We encourage all attendees to actively participate in the >> microconference by sharing their ideas, experiences, and insights. >>
