From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751487AbeFDVof (ORCPT ); Mon, 4 Jun 2018 17:44:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:57090 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbeFDVoe (ORCPT ); Mon, 4 Jun 2018 17:44:34 -0400 Date: Mon, 4 Jun 2018 17:44:31 -0400 From: Steven Rostedt To: Thomas Garnier Cc: Kernel Hardening , Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" , "the arch/x86 maintainers" , Francis Deslauriers , Greg KH , Andrew Morton , Peter Zijlstra , Guenter Roeck , nixiaoming , James Hogan , LKML Subject: Re: [PATCH v4 21/27] x86/ftrace: Adapt function tracing for PIE support Message-ID: <20180604174431.4aabfbf1@gandalf.local.home> In-Reply-To: References: <20180529221625.33541-1-thgarnie@google.com> <20180529221625.33541-22-thgarnie@google.com> <20180604161612.6d48d8d2@gandalf.local.home> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 4 Jun 2018 14:06:03 -0700 Thomas Garnier wrote: > On Mon, Jun 4, 2018 at 1:16 PM Steven Rostedt wrote: > > > > On Tue, 29 May 2018 15:15:22 -0700 > > Thomas Garnier wrote: > > > > > When using -fPIE/PIC with function tracing, the compiler generates a > > > call through the GOT (call *__fentry__@GOTPCREL). 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