Re: Live Patching Microconference at Linux Plumbers

[Josh Poimboeuf <jpoimboe@kernel.org>]

On Fri, Apr 14, 2023 at 10:53:03AM +0100, Mark Rutland wrote:
> > 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).

klp-convert is still considered experimental.  FYI here's a pull request
which adds arm64 support to kpatch-build:

  https://github.com/dynup/kpatch/pull/1302

> 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...

If objtool is going to be doing control-flow anyway then it could just
validate DWARF/SFrame.  Then everybody's happy?

> * 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.

Can you elaborate?  Why can't noinstr inline noinstr?  (that's a
mouthful)

Is it because of potential cloning caused by IPA optimizations?

>   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.

Not to mention how objtool will react to compiled rust code (has it
already been tried?)

-- 
Josh