From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-28.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED3B2C0007A for ; Thu, 3 Dec 2020 19:05:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A363820C56 for ; Thu, 3 Dec 2020 19:05:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387806AbgLCTFc (ORCPT ); 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-Google-Smtp-Source: ABdhPJygUP1cIJwRL7tVCs5S0BP8zl26VHCEvSZgnDfJ1ubHqNbQexJfBHlekI9nVH0KVp4PeLXnxJUT/QE7eXpWKqU= 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