Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1158355imm; Tue, 5 Jun 2018 09:57:08 -0700 (PDT) X-Google-Smtp-Source: ADUXVKI0z7uprl8mUK0sQkXomtTzX0k5JyyP6wJfdVZMle3Hg8ZJbnhVbauK9kJmoRFW3mLi5yHQ X-Received: by 2002:a65:42c2:: with SMTP id l2-v6mr21408721pgp.237.1528217827787; Tue, 05 Jun 2018 09:57:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528217827; cv=none; d=google.com; s=arc-20160816; b=o8JR2CZ0DpvtRwDKYAS4W0Wz4GmBpBtUJ8wEDjQcNfSlMPWeVrPVTv/+bKOXnhvHGi YFZ1A4/my6fC79Ed5Fd0c3FAUS7K5qkl9xDEAFK5VxLHStAWC4gn1nmALXtq3fh6p+ag dD8EGxYJEdT3FW9mZvOwSPFr/6AvG6AQcOA+c0gMGVlR50EsfKky+Pp19J0h35S4/+Zh MB1HYjCdm7YFsaCI8fJPYNsqJ5/ZgmANiZPnbJC8d2uGnpGZJxiJKgq/zIqdkgSReW4T YRaSsMgxdV6/JdlchzQ48ghmE4X81dNC5vOI6FrXtaEVIr+D+RZLGE3hWlZj8AIloB5N sz7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=fn3mu9sqzAG/UzgmLkX2+m0mnr3wRfEe4vCOmb/WWD4=; b=DiWVArM9cwcMuj7PZJjXp+cCaK7rb09hojVEMW2CQcwPhKVeqKkIVbfWlyOVCIga0+ VHkLPOltgXknUtQBI9mQXOxIk050Ld9wceqTaQg97x8MaisjIDjr8DZXvjCevwQJ93Pf bLNzPho6TymQnniwqhw6Gd0XG2Y8/pup0IV5f0d9fvgfEJB7rvhAQGHhLSvxR2MQQd/R /PcabTGGCiddTWAxFa8LlUIz40sHOF/V7QGx72vU8yYooGo8jHR9jnDjN5svhPNcRxZJ zUK8+Kc4WeGagDIrBq4wpivFuG0V0aHNG1TWGemQ83S8dP0JDp4zDwMKHgS9N3POoatU dqwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Fx03EHsu; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y7-v6si5679724pfn.16.2018.06.05.09.56.52; Tue, 05 Jun 2018 09:57:07 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=Fx03EHsu; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751853AbeFEQ41 (ORCPT + 99 others); Tue, 5 Jun 2018 12:56:27 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:38888 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbeFEQ4Z (ORCPT ); Tue, 5 Jun 2018 12:56:25 -0400 Received: by mail-io0-f193.google.com with SMTP id l19-v6so4199609ioj.5 for ; Tue, 05 Jun 2018 09:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fn3mu9sqzAG/UzgmLkX2+m0mnr3wRfEe4vCOmb/WWD4=; b=Fx03EHsutbus0SoNwOSfCnVpgDfYLcO41m+RkVzY3s+rGjhcpfwYPqs4RAaKGeWtAa /A2kNcjRVL5ltdORk94cjZRLElYiMR0alSQcjPfH1okzCYRui3qp0pTlaZXw5lVqmZRt fxevrUGqJ6lPNQEtbv5GQ2Ih1QizwZQkY7ATp6YyQAzMtse/e2plrTDwa4gvh9b3IMxc l+4u7j5wRaalRhmx1MJTZxPNXVSkXQzWuGgNFY49/nSeJI3IgeMQV4iVEvZwv5Cw+oJc sDc/c1SQEv02QcOokV/PtjweABGgMwloPKVLrmOYdukRCnApCvmcjxjbWX/0Y73TGiX7 g7Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fn3mu9sqzAG/UzgmLkX2+m0mnr3wRfEe4vCOmb/WWD4=; b=KlL7dICViReg3lSDc5imNvqPvKQ48O/yG72doXzRjcJ2Le/vAgSEhSkJ1CHOQhn9Wi 2HSISoTSqPGMrnnLpLcCya5w7XBim2H2Z2RU267w+pDtwctActWOi5njCmRnMMvo8OJ2 WjVOCk40KqCv8QY6/ys1FcIj7j3lTO5smTibFP2h8rOlAWUSrM6U2HLd7dgBrI1XuEsb 5XoLdKL8u6UkrOyECyFHv+Q7piX/GNV0eBkoI6dPoVcYXHy5Gu+EStwWsSTdniv7W58d 9KFwVpjo45qusI4D4Ss2GosHTATwElJ7lpM91Ia86m7Ie3KzRoQHgC9n3gzsk2YphJv0 UpGw== X-Gm-Message-State: APt69E3bWTFD3uCt4J2bgGxqQFZul2sWbUkApUE12qCSynXZdnAfWRSJ /uxwBruymelw2fFRMvuJHvIrOgeImCLJs9SwFZ03Zg== X-Received: by 2002:a6b:407:: with SMTP id 7-v6mr16384932ioe.140.1528217784865; Tue, 05 Jun 2018 09:56:24 -0700 (PDT) MIME-Version: 1.0 References: <20180529221625.33541-1-thgarnie@google.com> <20180529221625.33541-22-thgarnie@google.com> <20180604161612.6d48d8d2@gandalf.local.home> <20180604174431.4aabfbf1@gandalf.local.home> In-Reply-To: <20180604174431.4aabfbf1@gandalf.local.home> From: Thomas Garnier Date: Tue, 5 Jun 2018 09:56:14 -0700 Message-ID: Subject: Re: [PATCH v4 21/27] x86/ftrace: Adapt function tracing for PIE support To: Steven Rostedt 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 4, 2018 at 2:44 PM Steven Rostedt wrote: > > 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. I see what you mean looking at the different ideal_nops based on configurations. > > 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. I don't think that's necessary. In proposed implementation of PIE, kernel modules would not use a GOT call. In the current implementation the __fentry__ call is always GOT based (6-bytes). I will simplify the runtime implementation in the next patch set to just swap the expected size and ideal_nop when PIE is enabled. > > -- Steve -- Thomas