From: "Singh, Balbir" <firstname.lastname@example.org>
To: Mark Rutland <email@example.com>,
"Madhavan T. Venkataraman" <firstname.lastname@example.org>
Mark Brown <email@example.com>,
Julien Thierry <firstname.lastname@example.org>,
Subject: Re: Live patching on ARM64
Date: Fri, 19 Mar 2021 09:38:20 +1100 [thread overview]
Message-ID: <email@example.com> (raw)
On 15/1/21 11:33 pm, Mark Rutland wrote:
> On Thu, Jan 14, 2021 at 04:07:55PM -0600, Madhavan T. Venkataraman wrote:
>> Hi all,
>> My name is Madhavan Venkataraman.
> Hi Madhavan,
>> Microsoft is very interested in Live Patching support for ARM64.
>> On behalf of Microsoft, I would like to contribute.
>> I would like to get in touch with the people who are currently working
>> in this area, find out what exactly they are working on and see if they
>> could use an extra pair of eyes/hands with what they are working on.
>> 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
>> I apologize if I have missed anyone else who is working on Live Patching
>> for ARM64. Do let me know.
I am quite interested as well, I did some of the work for ppc64le
>> 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
> 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
Do we know how this differs across architectures? Usually kprobe and ftrace
unsafe functions are annotated as such, is there more to it?
> 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.
Could you please explain, whats bits of the entry code? I suspect we never
patch anything in assembly
> * 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.
noinstr is largely kcsan and kasan related, right?
> 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).
> 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.
> I'm not sure about the objtool side, so I'll leave that to Julien and co
> to answer.
Thanks, it would be good to see what the expectations from objtool are,
I thought only x86 needed it due to variable size instructions and -fomit-
prev parent reply other threads:[~2021-03-18 22:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <firstname.lastname@example.org>
2021-01-14 23:58 ` Live patching on ARM64 Josh Poimboeuf
2021-01-15 12:33 ` Mark Rutland
2021-01-15 13:44 ` Mark Brown
2021-01-17 17:25 ` Madhavan T. Venkataraman
2021-01-19 7:57 ` Julien Thierry
2021-01-19 15:19 ` Madhavan T. Venkataraman
2021-01-20 18:11 ` Julien Thierry
2021-01-26 18:03 ` Madhavan T. Venkataraman
2021-03-18 22:38 ` Singh, Balbir [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).