Re: [RFC] Kernel livepatching support in GCC

[David Brown <david dot brown at hesbynett dot no>]

On 28/05/15 10:39, Maxim Kuvyrkov wrote:
> Hi,
> 
> 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
> [1].
> 
> 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.
> 
> Comments?
> 

Rather than just a sequence of NOP's, should the first NOP be a
unconditional branch to the beginning of the real function?  I don't
know if this applies to AArch64 cpus, but I believe some cpus can handle
such branches already in the decode unit, thus avoiding any extra cycles
for skipping the NOPs.

David