From patchwork Thu Sep 26 09:32:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Burton X-Patchwork-Id: 174451 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp1795881ill; Thu, 26 Sep 2019 02:33:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqy92isnY6IpZobe8lFuwl2R8m0Sp3H6/+USgmvwfJYVdjMqvE1x7WVbZ1VehoGAWCy4lzKm X-Received: by 2002:a17:906:2f10:: with SMTP id v16mr2090252eji.247.1569490403310; Thu, 26 Sep 2019 02:33:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569490403; cv=none; d=google.com; s=arc-20160816; b=cUhkpy7u+YhH9DsC1EvS/EHzMz/LZ85wMWfwAf1gNFv1JuBEHbCK1eg4aA/UEyLRIj 7LmR3F/8nHlitLAKKPnLGVRg4p5KQ0BbE3yBPrfG6fbnsWVVT/xoQFGceKK/VVpTT26a BT4aS3iCL/QzxEbG0wQ+EMfpGpY7dHjl15y7Rc604+21Ki6av6+V7MaBkcOSlmAxFo2k NW/qreW6JLC9fHACNoer5yAT6CFOS1O6YOfMBdATlfUr0GMJRlVBsnNTZBtEgAzrdzZD 7Gkl0zyY3XuARj88rOEOGl6fnLjuY1T6IW79DeVs3SoKWMPM7FOP52vI7Mk8veP8PheO M/TA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=uJ85dfscMDqrBZDgXpbqcnqJ8k34cVdqxeeH5KJixiU=; b=dHKMB/UiUgcsBjmxVxQWkpt/kmKeWsISJ1BASNpozpf3qoQa9/QAeB06EGkQV8OZT7 j0z59cWF8ko4DapWd6eYBTO7DOqABvd0+6KC4kIOqXtON1zH9ySINQ5mN+iyVdW06Vt1 ueXr0MvS/x/y83KCTLAe7BOVBBCl+YRW/eaOlcwTo3xeT/CB6YPP7ybngZRx8dJ4uv14 LNBZk3dKWFaLEnaZsGaktx46/kqzsTsnoxpF/EPhxUUHxRBgZh+i17jiutZoJqxgh1qW wL/ht2H+2gpQ53TMxwIGn4PGg3a+uKf6JKI68TOZJIrtDKsby/jHH1BdeuOQIntmBi2l qfvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="ysX/vDA1"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d26si933658edq.91.2019.09.26.02.33.23; Thu, 26 Sep 2019 02:33:23 -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=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="ysX/vDA1"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727499AbfIZJdW (ORCPT + 26 others); Thu, 26 Sep 2019 05:33:22 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:35176 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726548AbfIZJdV (ORCPT ); Thu, 26 Sep 2019 05:33:21 -0400 Received: by mail-wr1-f67.google.com with SMTP id v8so1912149wrt.2 for ; Thu, 26 Sep 2019 02:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=uJ85dfscMDqrBZDgXpbqcnqJ8k34cVdqxeeH5KJixiU=; b=ysX/vDA1lodYeyDQtfZn53DOv9OAv0X8fbb1bprYw5jXG3TSGeYTvdUIAjlLEx3VWP XbeoGxqcUTQuImigCfBWKU9yNkKR+/sbRZ5KFIcTrlicfILlY+AQiQwVCOzADBA93TPn k+M8g73kgMs+qLz8Iqct4dBKkEr4PobMsOdnOc+/eX9xb2VtvZyKyn393yqe92T0o4j3 mptU4DBwlnKdMxxTE10z9TwFKHIOvE2uHQ5vfS2MGEaG46R8+tCFfWIj8rTld4INQTZt Q/ctQ/mtblnRd8EJivE8MykzL6K2vGPhNGzyXrDN2eO2DkeeFsg5YRcYitoWVNBd+CYC QPIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=uJ85dfscMDqrBZDgXpbqcnqJ8k34cVdqxeeH5KJixiU=; b=aM1Gsawm/wqgJIUY9PwwYfZhOQP+VMxrs/qYcHsa110Hr2lkVdBnjjgUDiCfQ1IAeY K1blK9pEN8/XjWdWrteeUBF1d5RZYW1LxDZ9Xv7296lKxybSiECkPzkkdRwkZQIx6Vgp U44Wik5opRazKf08hqsVQhWXaWz2ev0qmyyLTDR6c5ikTh7yrrTM1VPEuBXo7ddk7oZk UDoxzfIGQykz02EaKwpF9sMTJrUbk/59Q36v89yjdqJc1ApustaM75OHgb61bHL3ZdBl gRMhjY6Po/zUTlUxWtn6W1u6pfvddfT0LDF4jw/0qkdw7sDQZDGQmx/7Qljakr/4Ogta hM6g== X-Gm-Message-State: APjAAAU5V6zoWSSaYZkl6OMp6kDJ8+sSXI6Y1LZVjq4YXphqVWi9/Nsh rpsGY9Y95/neaFMgp84U2vnMDMHzrsg= X-Received: by 2002:a05:6000:1281:: with SMTP id f1mr2154922wrx.247.1569490399073; Thu, 26 Sep 2019 02:33:19 -0700 (PDT) Received: from flashheart.burtonini.com (35.106.2.81.in-addr.arpa. [81.2.106.35]) by smtp.gmail.com with ESMTPSA id h9sm1808020wrv.30.2019.09.26.02.33.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2019 02:33:17 -0700 (PDT) From: Ross Burton To: linux-kernel@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, bruce.ashfield@gmail.com, bp@alien8.de Subject: [PATCH v2] arch/x86/boot: use prefix map to avoid embedded paths Date: Thu, 26 Sep 2019 10:32:26 +0100 Message-Id: <20190926093226.8568-1-ross.burton@intel.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Bruce Ashfield It was observed that the kernel embeds the path in the x86 boot artifacts. >From https://bugzilla.yoctoproject.org/show_bug.cgi?id=13458: [ If you turn on the buildpaths QA test, or try a reproducible build, you discover that the kernel image contains build paths. $ strings bzImage-5.0.19-yocto-standard |grep tmp/ out of pgt_buf in /data/poky-tmp/reproducible/tmp/work-shared/qemux86-64/kernel-source/arch/x86/boot/compressed/kaslr_64.c!? But what's this in the top-level Makefile: $ git grep prefix-map Makefile:KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) So the __FILE__ shouldn't be using the full path. However arch/x86/boot/compressed/Makefile has this: KBUILD_CFLAGS := -m$(BITS) -O2 So that clears KBUILD_FLAGS, removing the -fmacro-prefix-map option. ] Other architectures do not clear the flags, but instead prune before adding boot or specific options. There's no obvious reason why x86 isn't doing the same thing (pruning vs clearing) and no build or boot issues have been observed. So we make x86 can do the same thing, and we no longer have embedded paths. Signed-off-by: Bruce Ashfield Signed-off-by: Ross Burton --- arch/x86/boot/Makefile | 1 + arch/x86/boot/compressed/Makefile | 1 + 2 files changed, 2 insertions(+) -- 2.20.1 diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index e2839b5c246c..cd9c56496106 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -66,6 +66,7 @@ clean-files += cpustr.h # --------------------------------------------------------------------------- KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP +KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ GCOV_PROFILE := n UBSAN_SANITIZE := n diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile index 6b84afdd7538..b246f18c5857 100644 --- a/arch/x86/boot/compressed/Makefile +++ b/arch/x86/boot/compressed/Makefile @@ -38,6 +38,7 @@ KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector) KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member) KBUILD_CFLAGS += $(call cc-disable-warning, gnu) KBUILD_CFLAGS += -Wno-pointer-sign +KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ GCOV_PROFILE := n