Skip to content
Snippets Groups Projects
  • Nathan Chancellor's avatar
    fab0610d
    powerpc: Fix stack protector Kconfig test for clang · fab0610d
    Nathan Chancellor authored
    commit 46e1879deea22eed31e9425d58635895fc0e8040 upstream.
    
    Clang's in-progress per-task stack protector support [1] does not work
    with the current Kconfig checks because '-mstack-protector-guard-offset'
    is not provided, unlike all other architecture Kconfig checks.
    
      $ fd Kconfig -x rg -l mstack-protector-guard-offset
      ./arch/arm/Kconfig
      ./arch/riscv/Kconfig
      ./arch/arm64/Kconfig
    
    This produces an error from clang, which is interpreted as the flags not
    being supported at all when they really are.
    
      $ clang --target=powerpc64-linux-gnu \
              -mstack-protector-guard=tls \
              -mstack-protector-guard-reg=r13 \
              -c -o /dev/null -x c /dev/null
      clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default
    
    This argument will always be provided by the build system, so mirror
    other architectures and use '-mstack-protector-guard-offset=0' for
    testing support, which fixes the issue for clang and does not regress
    support with GCC.
    
    Even with the first problem addressed, the 32-bit test continues to fail
    because Kbuild uses the powerpc64le-linux-gnu target for clang and
    nothing flips the target to 32-bit, resulting in an error about an
    invalid register valid:
    
      $ clang --target=powerpc64le-linux-gnu \
              -mstack-protector-guard=tls
              -mstack-protector-guard-reg=r2 \
              -mstack-protector-guard-offset=0 \
              -x c -c -o /dev/null /dev/null
      clang: error: invalid value 'r2' in 'mstack-protector-guard-reg=', expected one of: r13
    
    While GCC allows arbitrary registers, the implementation of
    '-mstack-protector-guard=tls' in LLVM shares the same code path as the
    user space thread local storage implementation, which uses a fixed
    register (2 for 32-bit and 13 for 62-bit), so the command line parsing
    enforces this limitation.
    
    Use the Kconfig macro '$(m32-flag)', which expands to '-m32' when
    supported, in the stack protector support cc-option call to properly
    switch the target to a 32-bit one, which matches what happens in Kbuild.
    While the 64-bit macro does not strictly need it, add the equivalent
    64-bit option for symmetry.
    
    Cc: stable@vger.kernel.org # 6.1+
    Link: https://github.com/llvm/llvm-project/pull/110928
    
     [1]
    Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
    Tested-by: default avatarKeith Packard <keithp@keithp.com>
    Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
    Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-1-12fb86b31857@kernel.org
    
    
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    fab0610d
    History
    powerpc: Fix stack protector Kconfig test for clang
    Nathan Chancellor authored
    commit 46e1879deea22eed31e9425d58635895fc0e8040 upstream.
    
    Clang's in-progress per-task stack protector support [1] does not work
    with the current Kconfig checks because '-mstack-protector-guard-offset'
    is not provided, unlike all other architecture Kconfig checks.
    
      $ fd Kconfig -x rg -l mstack-protector-guard-offset
      ./arch/arm/Kconfig
      ./arch/riscv/Kconfig
      ./arch/arm64/Kconfig
    
    This produces an error from clang, which is interpreted as the flags not
    being supported at all when they really are.
    
      $ clang --target=powerpc64-linux-gnu \
              -mstack-protector-guard=tls \
              -mstack-protector-guard-reg=r13 \
              -c -o /dev/null -x c /dev/null
      clang: error: '-mstack-protector-guard=tls' is used without '-mstack-protector-guard-offset', and there is no default
    
    This argument will always be provided by the build system, so mirror
    other architectures and use '-mstack-protector-guard-offset=0' for
    testing support, which fixes the issue for clang and does not regress
    support with GCC.
    
    Even with the first problem addressed, the 32-bit test continues to fail
    because Kbuild uses the powerpc64le-linux-gnu target for clang and
    nothing flips the target to 32-bit, resulting in an error about an
    invalid register valid:
    
      $ clang --target=powerpc64le-linux-gnu \
              -mstack-protector-guard=tls
              -mstack-protector-guard-reg=r2 \
              -mstack-protector-guard-offset=0 \
              -x c -c -o /dev/null /dev/null
      clang: error: invalid value 'r2' in 'mstack-protector-guard-reg=', expected one of: r13
    
    While GCC allows arbitrary registers, the implementation of
    '-mstack-protector-guard=tls' in LLVM shares the same code path as the
    user space thread local storage implementation, which uses a fixed
    register (2 for 32-bit and 13 for 62-bit), so the command line parsing
    enforces this limitation.
    
    Use the Kconfig macro '$(m32-flag)', which expands to '-m32' when
    supported, in the stack protector support cc-option call to properly
    switch the target to a 32-bit one, which matches what happens in Kbuild.
    While the 64-bit macro does not strictly need it, add the equivalent
    64-bit option for symmetry.
    
    Cc: stable@vger.kernel.org # 6.1+
    Link: https://github.com/llvm/llvm-project/pull/110928
    
     [1]
    Reviewed-by: default avatarKeith Packard <keithp@keithp.com>
    Tested-by: default avatarKeith Packard <keithp@keithp.com>
    Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
    Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20241009-powerpc-fix-stackprotector-test-clang-v2-1-12fb86b31857@kernel.org
    
    
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>