Re: Live patching on ARM64

On 1/15/21 6:33 AM, Mark Rutland wrote:

quoted

It looks like the most recent work in this area has been from the
following folks:

Mark Brown and Mark Rutland:
	Kernel changes to providing reliable stack traces.

Julien Thierry:
	Providing ARM64 support in objtool.

Torsten Duwe:
	Ftrace with regs.

IIRC that's about right. I'm also trying to make arm64 patch-safe (more
on that below), and there's a long tail of work there for anyone
interested.

OK.

quoted

I apologize if I have missed anyone else who is working on Live Patching
for ARM64. Do let me know.

Is there any work I can help with? Any areas that need investigation, any code
that needs to be written, any work that needs to be reviewed, any testing that
needs to done? You folks are probably super busy and would not mind an extra
hand.

One general thing that I believe we'll need to do is to rework code to
be patch-safe (which implies being noinstr-safe too). For example, we'll
need to rework the instruction patching code such that this cannot end
up patching itself (or anything that has instrumented it) in an unsafe
way.

OK.

Once we have objtool it should be possible to identify those cases
automatically. Currently I'm aware that we'll need to do something in at
least the following places:

* The entry code -- I'm currently chipping away at this.

OK.

* The insn framework (which is used by some patching code), since the
  bulk of it lives in arch/arm64/kernel/insn.c and isn't marked noinstr.
  
  We can probably shift the bulk of the aarch64_insn_gen_*() and
  aarch64_get_*() helpers into a header as __always_inline functions,
  which would allow them to be used in noinstr code. As those are
  typically invoked with a number of constant arguments that the
  compiler can fold, this /might/ work out as an optimization if the
  compiler can elide the error paths.

* The alternatives code, since we call instrumentable and patchable
  functions between updating instructions and performing all the
  necessary maintenance. There are a number of cases within
  __apply_alternatives(), e.g.

  - test_bit()
  - cpus_have_cap()
  - pr_info_once()
  - lm_alias()
  - alt_cb, if the callback is not marked as noinstr, or if it calls
    instrumentable code (e.g. from the insn framework).
  - clean_dcache_range_nopatch(), as read_sanitised_ftr_reg() and
    related code can be instrumented.

  This might need some underlying rework elsewhere (e.g. in the
  cpufeature code, or atomics framework).

OK.

So on the kernel side, maybe a first step would be to try to headerize
the insn generation code as __always_inline, and see whether that looks
ok? With that out of the way it'd be a bit easier to rework patching
code depending on the insn framework.

OK.

I have an understanding of some of the above already. I will come up to
speed on the others. I will email you any questions I might have.

I'm not sure about the objtool side, so I'll leave that to Julien and co
to answer.

Thanks for the information.

Madhavan