From: Mark Rutland <mark.rutland@arm.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: jpoimboe@kernel.org, jikos@kernel.org, pmladek@suse.com,
joe.lawrence@redhat.com, nstange@suse.de, mpdesouza@suse.de,
broonie@kernel.org, live-patching@vger.kernel.org,
Nick Desaulniers <ndesaulniers@google.com>,
"Jose E. Marchesi" <jose.marchesi@oracle.com>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Subject: Re: Live Patching Microconference at Linux Plumbers
Date: Fri, 14 Apr 2023 10:53:03 +0100 [thread overview]
Message-ID: <ZDkif0cu/jh/KKC+@FVFF77S0Q05N> (raw)
In-Reply-To: <alpine.LSU.2.21.2303291339090.21599@pobox.suse.cz>
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.
Mark.
>
> Key people
>
> - Josh Poimboeuf <jpoimboe@kernel.org>
> - Jiri Kosina <jikos@kernel.org>
> - Miroslav Benes <mbenes@suse.cz>
> - Petr Mladek <pmladek@suse.com>
> - Joe Lawrence <joe.lawrence@redhat.com>
> - Nicolai Stange <nstange@suse.de>
> - Marcos Paulo de Souza <mpdesouza@suse.de>
> - Mark Rutland <mark.rutland@arm.com>
> - Mark Brown <broonie@kernel.org>
>
> We encourage all attendees to actively participate in the
> microconference by sharing their ideas, experiences, and insights.
>
next prev parent reply other threads:[~2023-04-14 9:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-29 12:05 Live Patching Microconference at Linux Plumbers Miroslav Benes
2023-03-29 16:28 ` Joe Lawrence
2023-04-14 9:11 ` Miroslav Benes
2023-04-14 9:53 ` Mark Rutland [this message]
2023-04-14 12:54 ` Jose E. Marchesi
2023-04-14 13:51 ` Miguel Ojeda
2023-04-14 14:34 ` Jose E. Marchesi
2023-04-14 14:14 ` Miroslav Benes
2023-04-14 17:12 ` Josh Poimboeuf
2023-04-14 19:04 ` Miguel Ojeda
2023-04-14 20:22 ` Arnaldo Carvalho de Melo
2023-04-14 20:29 ` Miguel Ojeda
2023-04-14 21:10 ` Josh Poimboeuf
2023-04-14 19:30 ` Peter Zijlstra
2023-04-15 4:39 ` Josh Poimboeuf
2023-04-17 7:48 ` Peter Zijlstra
2023-04-17 8:58 ` Mark Rutland
2023-04-18 3:53 ` James Morris
2023-05-03 20:05 ` Joe Lawrence
2023-05-03 20:33 ` Steven Rostedt
2023-05-22 18:41 ` Joe Lawrence
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZDkif0cu/jh/KKC+@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=broonie@kernel.org \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jose.marchesi@oracle.com \
--cc=jpoimboe@kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mpdesouza@suse.de \
--cc=ndesaulniers@google.com \
--cc=nstange@suse.de \
--cc=pmladek@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox