From: Nathan Chancellor <nathan@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] ARM: cfi: Fix compilation corner case
Date: Fri, 8 Nov 2024 21:31:38 -0700 [thread overview]
Message-ID: <20241109043138.GA1649953@thelio-3990X> (raw)
In-Reply-To: <20241108-fix-kcfi-bug-v1-1-f8497c4bccae@linaro.org>
On Fri, Nov 08, 2024 at 08:37:36AM +0100, Linus Walleij wrote:
> When enabling expert mode CONFIG_EXPERT and using that power
> user mode to disable the branch prediction hardening
> !CONFIG_HARDEN_BRANCH_PREDICTOR, the picky assembly linker
> in CLANG notices that some assembly in proc-v7.S does
> not have corresponding C call sites, i.e. the prototypes
> in proc-v7-bugs.c are enclosed in ifdef
> CONFIG_HARDEN_BRANCH_PREDICTOR so this assembly:
>
> SYM_TYPED_FUNC_START(cpu_v7_smc_switch_mm)
> SYM_TYPED_FUNC_START(cpu_v7_hvc_switch_mm)
>
> Results in:
>
> ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_smc_switch_mm
> >>> referenced by proc-v7.S:94 (.../arch/arm/mm/proc-v7.S:94)
> >>> arch/arm/mm/proc-v7.o:(.text+0x108) in archive vmlinux.a
>
> ld.lld: error: undefined symbol: __kcfi_typeid_cpu_v7_hvc_switch_mm
> >>> referenced by proc-v7.S:105 (.../arch/arm/mm/proc-v7.S:105)
> >>> arch/arm/mm/proc-v7.o:(.text+0x124) in archive vmlinux.a
>
> Fix this by adding an additional requirement that
> CONFIG_HARDEN_BRANCH_PREDICTOR has to be enabled to compile
> these assembly calls.
>
> I suppose it wasn't a problem before because the linker is not
> so picky that other assembly symbols are actually being
> used.
I think this has been a problem since the original CFI change, so I
think it is worth dropping this block; it is more likely that
CONFIG_HARDEN_BRANCH_PREDICTOR is not often disabled outside of
randconfig, so it is hard to hit this issue in practice. As far as I can
tell, this is totally expected with the given configuration.
SYM_TYPED_FUNC_START makes use of __kcfi_typeid_<func>, which the
compiler generates for address-taken function declarations, but in this
configuration, cpu_v7_smc_switch_mm() and cpu_v7_hvc_switch_mm() have no
actual uses aside from their definition, so the compiler does not
generate these symbols, resulting in the link time error above. Perhaps
some of this could be encorporated into the beginning of the commit
message to make the issue a little more clear and less like the compiler
is at fault here ("the picky assembly linker" stands out a bit to me
there).
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202411041456.ZsoEiD7T-lkp@intel.com/
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Regardless of the commit message nits, this seems like the right thing
to do.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/arm/mm/proc-v7.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index 5fb9a6aecb00..2cd933342679 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -94,7 +94,7 @@ SYM_TYPED_FUNC_START(cpu_v7_dcache_clean_area)
> ret lr
> SYM_FUNC_END(cpu_v7_dcache_clean_area)
>
> -#ifdef CONFIG_ARM_PSCI
> +#if defined(CONFIG_ARM_PSCI) && defined(CONFIG_HARDEN_BRANCH_PREDICTOR)
> .arch_extension sec
> SYM_TYPED_FUNC_START(cpu_v7_smc_switch_mm)
> stmfd sp!, {r0 - r3}
>
> ---
> base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc
> change-id: 20241107-fix-kcfi-bug-ae3b08cbc167
>
> Best regards,
> --
> Linus Walleij <linus.walleij@linaro.org>
>
next prev parent reply other threads:[~2024-11-09 4:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 7:37 [PATCH] ARM: cfi: Fix compilation corner case Linus Walleij
2024-11-09 4:31 ` Nathan Chancellor [this message]
2024-11-10 23:17 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241109043138.GA1649953@thelio-3990X \
--to=nathan@kernel.org \
--cc=justinstitt@google.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=ndesaulniers@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox