This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] Kernel livepatching support in GCC
- From: libin <huawei dot libin at huawei dot com>
- To: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Cc: Andi Kleen <ak at linux dot intel dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>, Geoff Levand <Geoff dot Levand at huawei dot com>, <Andrew dot Wafaa at arm dot com>, Seth Jennings <sjenning at redhat dot com>, <jpoimboe at redhat dot com>, <jkosina at suse dot cz>, <huxinwei at huawei dot com>, Hanjun Guo <guohanjun at huawei dot com>, Xie XiuQi <xiexiuqi at huawei dot com>, <felix dot yang at huawei dot com>, <jiangjiji at huawei dot com>
- Date: Thu, 22 Oct 2015 17:07:04 +0800
- Subject: Re: [RFC] Kernel livepatching support in GCC
- Authentication-results: sourceware.org; auth=none
- References: <844CBBAF-DA0E-4164-9E35-34075A26F665 at linaro dot org>
å 2015/5/28 16:39, Maxim Kuvyrkov åé:
Akashi-san and I have been discussing required GCC changes to make kernel's livepatching work for AArch64 and other architectures. At the moment livepatching is supported for x86[_64] using the following options: "-pg -mfentry -mrecord-mcount -mnop-mcount" which is geek-speak for "please add several NOPs at the very beginning of each function, and make a section with addresses of all those NOP pads".
The above long-ish list of options is a historical artifact of how livepatching support evolved for x86. The end result is that for livepatching (or ftrace, or possible future kernel features) to work compiler needs to generate a little bit of empty code space at the beginning of each function. Kernel can later use that space to insert call sequences for various hooks.
Our proposal is that instead of adding -mfentry/-mnop-count/-mrecord-mcount options to other architectures, we should implement a target-independent option -fprolog-pad=N, which will generate a pad of N nops at the beginning of each function and add a section entry describing the pad similar to -mrecord-mcount .
Since adding NOPs is much less architecture-specific then outputting call instruction sequences, this option can be handled in a target-independent way at least for some/most architectures.
As I found out today, the team from Huawei has implemented , which follows x86 example of -mfentry option generating a hard-coded call sequence. I hope that this proposal can be easily incorporated into their work since most of the livepatching changes are in the kernel.
Thanks very much for your effort for this, and the arch-independed implementation
is very good to me, but only have one question that how to enture the atomic
replacement of multi instructions in kernel side?
And before this arch-independed option, can we consider the arch-depended -mfentry
implemention for arm64 like arch x86 firstly? I will post it soon.
livepatch for arm64 based on this arm64 -mfentry feature on github:
discussions on this topic:
 Technically, generating a NOP pad and adding a section entry in .__mcount_loc are two separate actions, so we may want to have a -fprolog-pad-record option. My instinct is to stick with a single option for now, since we can always add more later.