Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp730878pxu; Thu, 3 Dec 2020 11:08:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJwGSUEPrKrBdNvv56AuOzq7uiUN0lZK5fu9OXraCLYDJHMKLWtHYh0Rq/VrSoGoU0qA9z5I X-Received: by 2002:a17:906:9345:: with SMTP id p5mr3823906ejw.40.1607022503544; Thu, 03 Dec 2020 11:08:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607022503; cv=none; d=google.com; s=arc-20160816; b=v6m0gyN4x/TTNmoNiar6PL4EGtqt1aXw+etY5lZrQ8zh/9pjN66qHxT6VuRc2dp3ow tEE0abdlU0Bkx2pbEY8q2JnYiLTAiKy5R7I5gdW2p8LBJ+Z8AzJVdo5ZIuFQAqhwTxj/ Op2rLDeNwUAnWzrCJB4ia9Fq6LZ62PIpstv/U/3IZ2QoHYELyFxS200YoLfwgVfCY9HE tJPJQVrxi9q6ocKBCG4XnPir1bTbdxyJjVbiuZ5VyPSV3W3tdQrzJa4mnytGeW9o6eHI WXtNdGIwTXNExn/FX9eD8CAbtQ/T85rDJEa9NOtMkCOPPGmwyrJKVKF2TJHpIjyRn8o1 HFfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=MGVJZBDXNN6LdEStSCVvQ7DYrKz46JI0zY/CXjUt84Y=; b=h0jWZzHeSvv5ej7R3LFk09F1uwoHA92r1wEItnZY4Bci+afbUNwOzcd+wlwplaFlbN JYCE0ga1+jYtgpdMLGWH8En7wHghq2K2EGLISnacB/VOCJybgPWILS3KTE6CNwgyyUJn Q3LPfbs2H8jMGbCIad9faerC1Kcq4+yZ8fZsoOljscZihfm2XtNTNoq9njcDpFKxSzgg xmeJOXw5lATntGxH9hVThTVScqleujGiW2ufV4/xSKJO680e+G/lnvp4cV5jVjJsMt4j t+US7CHhqajQhoUh3edQ5Zlad1UjEj0sxFecYjH6YXQnpLiJKE+p/uZwv2MMUmYAAqeT GWhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Xpngdm+d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id g2si1496939edn.508.2020.12.03.11.08.00; Thu, 03 Dec 2020 11:08:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Xpngdm+d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S2387708AbgLCTFc (ORCPT + 99 others); Thu, 3 Dec 2020 14:05:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726042AbgLCTFb (ORCPT ); Thu, 3 Dec 2020 14:05:31 -0500 Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F8DDC061A4F for ; Thu, 3 Dec 2020 11:04:51 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id w6so1936199pfu.1 for ; Thu, 03 Dec 2020 11:04:51 -0800 (PST) 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=MGVJZBDXNN6LdEStSCVvQ7DYrKz46JI0zY/CXjUt84Y=; b=Xpngdm+dVlFRitn2i9O7Ckeyv9yY5k8xWK55Ab3b6x7eM5kQJiJc/IgV7V86j4qg2H amLk/0khYfIAjNlik2isDsQqYyz/ilBOzlQEBFZ6DMpPi+cGaj2elvUtLpjhXqYOb5AQ G8O3zDWWSiyFmCjEcIyMyecmxlJYoXBN3ba0ejgO7NgjloiouWAheLWWDP6mQUpPft7Q TPaUsJh85PI/1XvIG5kAonobzDqw9iwKWWP9UhM+EPX9ckPS/f0zd3Uz30kVeLTa1gyS 3EMIdCE3a12qF/S3m/RfefmgYZg6Asg+OeFN+wPWNzMo63obakJbrKvpbdNA1dD5NNhd 7Xeg== 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=MGVJZBDXNN6LdEStSCVvQ7DYrKz46JI0zY/CXjUt84Y=; b=JXWwX1zzBTyGrMO0sP0cJUXJnQGNc8+AN5B/suiumjWyphFJhJWfK7QsPoTx9pfw+Y Yq9Sfdu7ELTILU5Xj9exwFkZf7rXEYyV+OlB0Xn+EPEMieRB9sNl3E7NO7RoOx3Yb1sO XuO9CB7K0jYWTOFCBeTomCTayJHPmWbDvPrYtqp6lwEOwKA8t2HPzbRvm7zc0PAf1B7s rhVeEG7Q5ZnBRLwcRzAe+lK5wKLQHA3A7n6oQeBsHIu1sUgk3lABRK/0K17843CWn+DL 4KOidQ//2fnpRC3fnKSIsCItI4Lu5j/p4b7YiQgt3czcZ5cUhy1TWg2vtIB20TGuYJlE Phfg== X-Gm-Message-State: AOAM533dfQnmwosPXVOe1VAyITXZvx0Epw/orXvEgsRYRu2X4yVbgN3O SRlxItmwEBOYpwnraf7/+C7faFs8/lpLvBSigfutgQ== X-Received: by 2002:a62:1896:0:b029:197:491c:be38 with SMTP id 144-20020a6218960000b0290197491cbe38mr374126pfy.15.1607022290861; Thu, 03 Dec 2020 11:04:50 -0800 (PST) MIME-Version: 1.0 References: <20201203170529.1029105-1-maskray@google.com> In-Reply-To: <20201203170529.1029105-1-maskray@google.com> From: Nick Desaulniers Date: Thu, 3 Dec 2020 11:04:39 -0800 Message-ID: Subject: Re: [PATCH] firmware_loader: Align .builtin_fw to 8 To: Fangrui Song Cc: Arnd Bergmann , linux-arch , LKML , clang-built-linux , Nathan Chancellor , kernel test robot , dwmw@amazon.co.uk, Peter Zijlstra , Kees Cook Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 3, 2020 at 9:05 AM Fangrui Song wrote: > > arm64 references the start address of .builtin_fw (__start_builtin_fw) > with a pair of R_AARCH64_ADR_PREL_PG_HI21/R_AARCH64_LDST64_ABS_LO12_NC > relocations. The compiler is allowed to emit the > R_AARCH64_LDST64_ABS_LO12_NC relocation because struct builtin_fw in > include/linux/firmware.h is 8-byte aligned. > > The R_AARCH64_LDST64_ABS_LO12_NC relocation requires the address to be a > multiple of 8, which may not be the case if .builtin_fw is empty. > Unconditionally align .builtin_fw to fix the linker error. > > Fixes: 5658c76 ("firmware: allow firmware files to be built into kernel image") > Link: https://github.com/ClangBuiltLinux/linux/issues/1204 > Reported-by: kernel test robot > Signed-off-by: Fangrui Song > --- > include/asm-generic/vmlinux.lds.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > index b2b3d81b1535..3cd4bd1193ab 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -459,6 +459,7 @@ > } \ > \ > /* Built-in firmware blobs */ \ > + ALIGN_FUNCTION(); \ Thanks for the patch! I'm going to repeat my question from the above link (https://github.com/ClangBuiltLinux/linux/issues/1204#issuecomment-737610582) just in case it's not naive: ALIGN_FUNCTION() C preprocessor macro seems to be used to realign code, while STRUCT_ALIGN() seems to be used to realign data. It looks to me like only data is put into .builtin_fw. If these relocations require an alignment of 8, than multiples of 8 should also be fine (STRUCT_ALIGN in 32 for all toolchain version, except gcc 4.9 which is 64; both are multiples of 8 though). It looks like only structs are placed in .builtin_fw; ie. data. In that case, I worry that using ALIGN_FUNCTION/8 might actually be under-aligning data in this section. Though, in https://github.com/ClangBuiltLinux/linux/issues/1204#issuecomment-737625134 you're comment: >> In GNU ld, the empty .builtin_fw is removed So that's a difference in behavior between ld.bfd and ld.lld, which is fine, but it makes me wonder whether we should instead or additionally be discarding this section explicitly via linker script when CONFIG_FW_LOADER is not set? > .builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \ > __start_builtin_fw = .; \ > KEEP(*(.builtin_fw)) \ > -- > 2.29.2.576.ga3fc446d84-goog > -- Thanks, ~Nick Desaulniers