Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Jun 2018 17:44:31 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Thomas Garnier <thgarnie@...gle.com>
Cc: Kernel Hardening <kernel-hardening@...ts.openwall.com>, Ingo Molnar
 <mingo@...hat.com>, Thomas Gleixner <tglx@...utronix.de>, "H . Peter Anvin"
 <hpa@...or.com>, "the arch/x86 maintainers" <x86@...nel.org>, Francis
 Deslauriers <francis.deslauriers@...icios.com>, Greg KH
 <gregkh@...uxfoundation.org>, Andrew Morton <akpm@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>, Guenter Roeck <linux@...ck-us.net>,
 nixiaoming <nixiaoming@...wei.com>, James Hogan <jhogan@...nel.org>, LKML
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 21/27] x86/ftrace: Adapt function tracing for PIE
 support

On Mon, 4 Jun 2018 14:06:03 -0700
Thomas Garnier <thgarnie@...gle.com> wrote:

> On Mon, Jun 4, 2018 at 1:16 PM Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > On Tue, 29 May 2018 15:15:22 -0700
> > Thomas Garnier <thgarnie@...gle.com> wrote:
> >  
> > > When using -fPIE/PIC with function tracing, the compiler generates a
> > > call through the GOT (call *__fentry__@...PCREL). This instruction
> > > takes 6 bytes instead of 5 on the usual relative call.
> > >
> > > If PIE is enabled, replace the 6th byte of the GOT call by a 1-byte nop
> > > so ftrace can handle the previous 5-bytes as before.
> > >
> > > Position Independent Executable (PIE) support will allow to extend the
> > > KASLR randomization range 0xffffffff80000000.  
> >
> > I thought you were going to write a update to recordmcount.c to handle
> > this at compile time?  
> 
> I can correctly calculate the start of the call instruction with
> recordmcount (no need for addr-1) but I still need to handle the
> different size of the instructions. I don't think I can completely
> replace the GOT call with a relative call. Maybe I am missing
> something on the way recordmcount is used? Should it replace all
> mcount locations with a nop slide? Why is it done at runtime too then?

Because we need to figure out the "ideal nop" thus we need to change it
regardless.

We could have recordmcount.c replace everything with the default nop
(I've thought of that before), and then we could update with the ideal
nop at run time, if that helps with this.

-- Steve

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.