Linux Virtualization - Oct 2017 - [RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at goodmis.org>
wrote:
> On Wed,  4 Oct 2017 14:19:56 -0700
> Thomas Garnier <thgarnie at google.com> wrote:
>
>> When using -fPIE/PIC with function tracing, the compiler generates a
>> call through the GOT (call *__fentry__ at GOTPCREL). This instruction
>> takes 6 bytes instead of 5 on the usual relative call.
>>
>> With this change, function tracing supports 6 bytes on traceable
>> function and can still replace relative calls on the ftrace assembly
>> functions.
>>
>> Position Independent Executable (PIE) support will allow to extended
the
>> KASLR randomization range below the -2G memory limit.
>
> Question: This 6 bytes is only the initial call that gcc creates. When
> function tracing is enabled, the calls are back to the normal call to
> the ftrace trampoline?
That is correct.
>
> -- Steve
>


-- 
Thomas

On Thu, 5 Oct 2017 09:01:14 -0700
Thomas Garnier <thgarnie at google.com> wrote:
> On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at
goodmis.org> wrote:
> > On Wed,  4 Oct 2017 14:19:56 -0700
> > Thomas Garnier <thgarnie at google.com> wrote:
> >  
> >> When using -fPIE/PIC with function tracing, the compiler generates
a
> >> call through the GOT (call *__fentry__ at GOTPCREL). This
instruction
> >> takes 6 bytes instead of 5 on the usual relative call.
> >>
> >> With this change, function tracing supports 6 bytes on traceable
> >> function and can still replace relative calls on the ftrace
assembly
> >> functions.
> >>
> >> Position Independent Executable (PIE) support will allow to
extended the
> >> KASLR randomization range below the -2G memory limit.  
> >
> > Question: This 6 bytes is only the initial call that gcc creates. When
> > function tracing is enabled, the calls are back to the normal call to
> > the ftrace trampoline?  
> 
> That is correct.
> 
Then I think a better idea is to simply nop them out at compile time,
and have the code that updates them to nops to know about it.

See scripts/recordmcount.c

Could we simply add a 5 byte nop followed by a 1 byte nop, and treat it
the same as if it didn't exist? This code can be a little complex, and
can cause really nasty side effects if things go wrong. I would like to
keep from adding more variables to the changes here.

-- Steve

On Thu, Oct 5, 2017 at 9:11 AM, Steven Rostedt <rostedt at goodmis.org>
wrote:
> On Thu, 5 Oct 2017 09:01:14 -0700
> Thomas Garnier <thgarnie at google.com> wrote:
>
>> On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt <rostedt at
goodmis.org> wrote:
>> > On Wed,  4 Oct 2017 14:19:56 -0700
>> > Thomas Garnier <thgarnie at google.com> wrote:
>> >
>> >> When using -fPIE/PIC with function tracing, the compiler
generates a
>> >> call through the GOT (call *__fentry__ at GOTPCREL). This
instruction
>> >> takes 6 bytes instead of 5 on the usual relative call.
>> >>
>> >> With this change, function tracing supports 6 bytes on
traceable
>> >> function and can still replace relative calls on the ftrace
assembly
>> >> functions.
>> >>
>> >> Position Independent Executable (PIE) support will allow to
extended the
>> >> KASLR randomization range below the -2G memory limit.
>> >
>> > Question: This 6 bytes is only the initial call that gcc creates.
When
>> > function tracing is enabled, the calls are back to the normal call
to
>> > the ftrace trampoline?
>>
>> That is correct.
>>
>
> Then I think a better idea is to simply nop them out at compile time,
> and have the code that updates them to nops to know about it.
>
> See scripts/recordmcount.c
>
> Could we simply add a 5 byte nop followed by a 1 byte nop, and treat it
> the same as if it didn't exist? This code can be a little complex, and
> can cause really nasty side effects if things go wrong. I would like to
> keep from adding more variables to the changes here.
Sure, I will simplify it for the next iteration.

Thanks for the feedback.
>
> -- Steve


-- 
Thomas