linux-kernel - Re: [PATCH v4 21/27] x86/ftrace: Adapt function tracing for PIE support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180604174431.4aabfbf1@gandalf.local.home>
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