Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp147208imm; Mon, 4 Jun 2018 14:45:15 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ6pzvfzuHh3SauR53CqZ+MgmVelyKVDacxnhWlrgb0qAzkVjCbXB/uz8LFxTqD2L9C/YER X-Received: by 2002:a63:b008:: with SMTP id h8-v6mr17201281pgf.137.1528148715709; Mon, 04 Jun 2018 14:45:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528148715; cv=none; d=google.com; s=arc-20160816; b=hOScXuvSJhVkG0K7nAxOJKZgF37Md26KhXjmSOMiwOBUE1MVwUmNYsUC/YWVWEPtKY CyYLWrxJplkVT2Sul9r+HL1k++eHoPoTFlYRlhJ1rfbWjCXvBEUU9w9XDkeXZU+I+K5C dhY2F784loj429kU59pqqjTEvD9gIx4Pv/PPtYsOKWjD/4Guajll51iwBeXJNoO8meLr oAjt+speeEcvz65TiuRcwSTbUI7KlD44eSr5Ta6CWUG7rq9dBLswgeVVcllDshu9Ma1Y mKXS7RAapeJifclHga5XQ4Lej1j7RRznJ8Tp8V8mL55vM6IXJ0F3Ex4CStv+M23J9Po2 5gng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=OGu+5AltuUHJYNxg/ybywVIcdS7bevrX7CXEgi63bes=; b=nKuo/QOQ3AmRE1fVuGGLH/4AyHRJo34UadQ1cAs7NO4GtKs/WxyF0dsq1Ho6gSatdN HN39+mT4Qwit2IPfxa1Fz+G85apAqpmxZRKOhu6dv1w8pHlmRkvEGFTRs6O+uqXhI474 erOktFHyK1Vlc7evNuE7otRrqlR0tMCK1nHr+vU6M9ncnq6rP9kxLRwIwDPtRjnq1WzU c6EThRLW44KzBVsjU448huI6qQbUe+fyWpJIA0QNM4wdWVPIG72vBaVSaW4CAU2gajZD 2yacyTUcHuyePcVarvGyS97jpDy9CN9rXRUYe+Gfi2L9+UBPpH4E8epMrKyOVGReteJs uvtg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l68-v6si7917822pgl.84.2018.06.04.14.44.58; Mon, 04 Jun 2018 14:45:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751479AbeFDVof (ORCPT + 99 others); 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 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A764D2083F; Mon, 4 Jun 2018 21:44:32 +0000 (UTC) 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 Precedence: bulk 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