From patchwork Thu Sep 26 09:11:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ross Burton X-Patchwork-Id: 174450 Delivered-To: patch@linaro.org Received: by 2002:a92:7e96:0:0:0:0:0 with SMTP id q22csp1775149ill; Thu, 26 Sep 2019 02:11:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqwU9O38EBEDGdgSjyAca5UdK8UmzCUhhz4fL1/acoZKpPyOqkckF1aC2JoBPMV+SBiJ2C9Q X-Received: by 2002:a50:9625:: with SMTP id y34mr2368119eda.72.1569489077973; Thu, 26 Sep 2019 02:11:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569489077; cv=none; d=google.com; s=arc-20160816; b=S/H8rhBzJkMoN74G/4YsicL4X1n1XV4ZhsWDCMwMDkxozsdAFZHLeAoF7btAt/zkP5 WoGMCwARk6a8a5578+nkytxuVApXYuO0Njk8JuX7hUOuhQtFztCSzcRVawjmhnzMp+68 iUhgbJlC1PTuceMwguCPbSwdKc+9uJsOtcghkB6ocZT/TxKXaumk8CE5fZHXaWKJh8oW NS3Kw31I9BlsfYyfAwOC0TneXqX9P3QmEIJauMpuj/IPxDGk7w/l/Gt9hlZ0DfdnenVd /7pis1FN2CdnjtCe+TG9HgW4kgouh3sp8Igshu/PgKW0bahBfai2ompHMwRkK6HmxVOv 3AZg== 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=NvlClry7u7XrfGIVsfJ+TjM0+OzUnx/9VnLu9RuXPxE=; b=buTXnQ73LOEwp0ud07RmdSbX9fHPrK6f6l6mY3GI5mpH0xYt2V5tZcr6MiJX4vfIPB T3b3HGQDV1sFFfd1SESLeUokfTReaD1rr5UUyW3RM+Rkh+Z9/d70G1+IruFISTvFcNlD 1KqW4Y3lrWvR/x4QQuawLn1QvM0KRkWk8i/RwPwOFSwali8Gc//2QD2ZWag/8wfLU2YG HfxfDDYN14odCT/YPryexMlQ+36o/eyfcq+11pSz7NkeRqA6QXW8SPzRC6Nzbms8hHc3 ez3gASBa2W9IliQ2PhEj7eeqRImyPtljB5EL2WpvXM1/zZOLRjF2wAU776t0LAQ5Ax9Q g30Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=HDnWCsyW; 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 f21si976791edb.379.2019.09.26.02.11.17; Thu, 26 Sep 2019 02:11:17 -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=HDnWCsyW; 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 S1730146AbfIZJLQ (ORCPT + 26 others); Thu, 26 Sep 2019 05:11:16 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:50283 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725890AbfIZJLQ (ORCPT ); Thu, 26 Sep 2019 05:11:16 -0400 Received: by mail-wm1-f66.google.com with SMTP id 5so1818545wmg.0 for ; Thu, 26 Sep 2019 02:11:14 -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=NvlClry7u7XrfGIVsfJ+TjM0+OzUnx/9VnLu9RuXPxE=; b=HDnWCsyWuMRI0mLG/7gMEhhik8MvA1Tz46EzqLquUWfr7VTeW5joimm4bIwU9cZf7x L2VDgW4g/sueve9OFN9PyHt3W64X5i3q1Nq5T49n5uCkqcdM4Ra20F5v7YHJvmmqlwCZ op5sXml/au4o6Wb0aNR6PrBohasuofJRqa6a0Y1cIAVQx330TxKpDkc9N2c7b0+WdvGf bOZRD4jxBlUNm0NZB5J14U04KQDbJ7BF78dXLJuUsDitR8Z6Nvatkse9ar8ufN031aB6 4YfePqfcxlCQIptELuPS0j/J85XKiszJWJDbBKdiMpMi6SceOS2hjcj5Ym2D/3wE7aIW jpWw== 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=NvlClry7u7XrfGIVsfJ+TjM0+OzUnx/9VnLu9RuXPxE=; b=NCwT5+VBsm87G0JbJp4Gr05dy0IGudnLwzpGcvuVJOaIjAsvCW9bxuK21V7jxduagb fBTo4xSPqRJbV4ihRKPHJTovkfh0dP1lWQdyL1cdgoWfRhOcRC9fHjseKgf8o5sPB/X9 SAAnzgMmjykxGRuvY4zN+1q/xwlqjFBEasUBZXU7wpPgoqEXMhvnDXeXiyLHjsbgWaKf ucZeyfF+insSNfvUpZuMK91u4TC1g+JuGGpGibGjnO+lv5ouQ3y6G3R4YKk/1OefLcd7 ZIkOm/9AVERvBlvKMH+ulW84/KyCMoequHrPAcgcJeeQVojv1XZixfjIGZZajux69XwX p6Kw== X-Gm-Message-State: APjAAAWVl3YyO4ikhSC3psj3jRZcyDSlfXjk/739ElOP0Wr8MpjNQpIf eplTsaFacrAqX7TV8hEUNdF/6PAsBFc= X-Received: by 2002:a1c:4d0d:: with SMTP id o13mr2144290wmh.19.1569489073735; Thu, 26 Sep 2019 02:11:13 -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 a10sm1886935wrm.52.2019.09.26.02.11.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2019 02:11:12 -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 Subject: [PATCH] arch/x86/boot: use prefix map to avoid embedded paths Date: Thu, 26 Sep 2019 10:11:04 +0100 Message-Id: <20190926091104.3762-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/compressed/Makefile | 1 + 1 file changed, 1 insertion(+) -- 2.20.1 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