clang-11 and earlier do not support -fsanitize=shadow-call-stack
in combination with -mbig-endian, but the Kconfig check does not
pass the endianess flag, so building a big-endian kernel with
this fails at build time:
clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
Change the Kconfig check to let Kconfig figure this out earlier
and prevent the broken configuration. I assume this is a bug
in clang that needs to be fixed, but we also have to work
around existing releases.
Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
Link: https://bugs.llvm.org/show_bug.cgi?id=46076
Signed-off-by: Arnd Bergmann <[email protected]>
---
arch/arm64/Kconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a82441d6dc36..692e1575a6c8 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1031,7 +1031,9 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK
# Supported by clang >= 7.0
config CC_HAVE_SHADOW_CALL_STACK
- def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
+ bool
+ default $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18 -mbig-endian) if CPU_BIG_ENDIAN
+ default $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18 -mlittle-endian) if !CPU_BIG_ENDIAN
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
--
2.26.2
On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
> clang-11 and earlier do not support -fsanitize=shadow-call-stack
> in combination with -mbig-endian, but the Kconfig check does not
> pass the endianess flag, so building a big-endian kernel with
> this fails at build time:
>
> clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
>
> Change the Kconfig check to let Kconfig figure this out earlier
> and prevent the broken configuration. I assume this is a bug
> in clang that needs to be fixed, but we also have to work
> around existing releases.
>
> Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
> Link: https://bugs.llvm.org/show_bug.cgi?id=46076
> Signed-off-by: Arnd Bergmann <[email protected]>
I suspect this is similar to the patchable-function-entry issue, and
this is an oversight that we'd rather fix toolchain side.
Nick, Fangrui, thoughts?
Mark.
> ---
> arch/arm64/Kconfig | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index a82441d6dc36..692e1575a6c8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1031,7 +1031,9 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK
>
> # Supported by clang >= 7.0
> config CC_HAVE_SHADOW_CALL_STACK
> - def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18)
> + bool
> + default $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18 -mbig-endian) if CPU_BIG_ENDIAN
> + default $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18 -mlittle-endian) if !CPU_BIG_ENDIAN
>
> config SECCOMP
> bool "Enable seccomp to safely compute untrusted bytecode"
> --
> 2.26.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, May 27, 2020 at 8:24 AM Mark Rutland <[email protected]> wrote:
>
> On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
> > clang-11 and earlier do not support -fsanitize=shadow-call-stack
> > in combination with -mbig-endian, but the Kconfig check does not
> > pass the endianess flag, so building a big-endian kernel with
> > this fails at build time:
> >
> > clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
> >
> > Change the Kconfig check to let Kconfig figure this out earlier
> > and prevent the broken configuration. I assume this is a bug
> > in clang that needs to be fixed, but we also have to work
> > around existing releases.
> >
> > Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
> > Link: https://bugs.llvm.org/show_bug.cgi?id=46076
> > Signed-off-by: Arnd Bergmann <[email protected]>
>
> I suspect this is similar to the patchable-function-entry issue, and
> this is an oversight that we'd rather fix toolchain side.
>
> Nick, Fangrui, thoughts?
Exactly, Fangrui already has a fix: https://reviews.llvm.org/D80647.
Thanks Fangrui!
It seems it's easy in the codebase to check the specific ABI, which
isn't explicitly LE, rather than use a method that checks the ISA
regardless of endianness.
--
Thanks,
~Nick Desaulniers
On 2020-05-27, Arnd Bergmann wrote:
>On Wed, May 27, 2020 at 7:28 PM 'Nick Desaulniers' via Clang Built
>Linux <[email protected]> wrote:
>>
>> On Wed, May 27, 2020 at 8:24 AM Mark Rutland <[email protected]> wrote:
>> >
>> > On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
>> > > clang-11 and earlier do not support -fsanitize=shadow-call-stack
>> > > in combination with -mbig-endian, but the Kconfig check does not
>> > > pass the endianess flag, so building a big-endian kernel with
>> > > this fails at build time:
>> > >
>> > > clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
>> > >
>> > > Change the Kconfig check to let Kconfig figure this out earlier
>> > > and prevent the broken configuration. I assume this is a bug
>> > > in clang that needs to be fixed, but we also have to work
>> > > around existing releases.
>> > >
>> > > Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
>> > > Link: https://bugs.llvm.org/show_bug.cgi?id=46076
>> > > Signed-off-by: Arnd Bergmann <[email protected]>
>> >
>> > I suspect this is similar to the patchable-function-entry issue, and
>> > this is an oversight that we'd rather fix toolchain side.
>> >
>> > Nick, Fangrui, thoughts?
>>
>> Exactly, Fangrui already has a fix: https://reviews.llvm.org/D80647.
>> Thanks Fangrui!
>
>Ok, great! I had opened the bug first so I could reference it in the
>commit changelog, it seems the fix came fast than I managed to
>send out the kernel workaround.
>
>Do we still want the kernel workaround anyway to make it work
>with older clang versions, or do we expect to fall back to not
>use the integrated assembler for the moment?
>
> Arnd
We can condition it on `CLANG_VERSION >= 100001` (assuming Tom (CCed)
is happy (and there is still time) cherrying pick the two commits https://bugs.llvm.org/show_bug.cgi?id=46076 to clang 10.0.1)
On Wed, May 27, 2020 at 7:28 PM 'Nick Desaulniers' via Clang Built
Linux <[email protected]> wrote:
>
> On Wed, May 27, 2020 at 8:24 AM Mark Rutland <[email protected]> wrote:
> >
> > On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
> > > clang-11 and earlier do not support -fsanitize=shadow-call-stack
> > > in combination with -mbig-endian, but the Kconfig check does not
> > > pass the endianess flag, so building a big-endian kernel with
> > > this fails at build time:
> > >
> > > clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
> > >
> > > Change the Kconfig check to let Kconfig figure this out earlier
> > > and prevent the broken configuration. I assume this is a bug
> > > in clang that needs to be fixed, but we also have to work
> > > around existing releases.
> > >
> > > Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
> > > Link: https://bugs.llvm.org/show_bug.cgi?id=46076
> > > Signed-off-by: Arnd Bergmann <[email protected]>
> >
> > I suspect this is similar to the patchable-function-entry issue, and
> > this is an oversight that we'd rather fix toolchain side.
> >
> > Nick, Fangrui, thoughts?
>
> Exactly, Fangrui already has a fix: https://reviews.llvm.org/D80647.
> Thanks Fangrui!
Ok, great! I had opened the bug first so I could reference it in the
commit changelog, it seems the fix came fast than I managed to
send out the kernel workaround.
Do we still want the kernel workaround anyway to make it work
with older clang versions, or do we expect to fall back to not
use the integrated assembler for the moment?
Arnd
On Wed, May 27, 2020 at 8:35 PM 'Fangrui Song' via Clang Built Linux
<[email protected]> wrote:
> On 2020-05-27, Arnd Bergmann wrote:
> >On Wed, May 27, 2020 at 7:28 PM 'Nick Desaulniers' via Clang Built
> >Linux <[email protected]> wrote:
> >>
> >> On Wed, May 27, 2020 at 8:24 AM Mark Rutland <[email protected]> wrote:
> >> >
> >> > On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
> >> > > clang-11 and earlier do not support -fsanitize=shadow-call-stack
> >> > > in combination with -mbig-endian, but the Kconfig check does not
> >> > > pass the endianess flag, so building a big-endian kernel with
> >> > > this fails at build time:
> >> > >
> >> > > clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
> >> > >
> >> > > Change the Kconfig check to let Kconfig figure this out earlier
> >> > > and prevent the broken configuration. I assume this is a bug
> >> > > in clang that needs to be fixed, but we also have to work
> >> > > around existing releases.
> >> > >
> >> > > Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
> >> > > Link: https://bugs.llvm.org/show_bug.cgi?id=46076
> >> > > Signed-off-by: Arnd Bergmann <[email protected]>
> >> >
> >> > I suspect this is similar to the patchable-function-entry issue, and
> >> > this is an oversight that we'd rather fix toolchain side.
> >> >
> >> > Nick, Fangrui, thoughts?
> >>
> >> Exactly, Fangrui already has a fix: https://reviews.llvm.org/D80647.
> >> Thanks Fangrui!
> >
> >Ok, great! I had opened the bug first so I could reference it in the
> >commit changelog, it seems the fix came fast than I managed to
> >send out the kernel workaround.
> >
> >Do we still want the kernel workaround anyway to make it work
> >with older clang versions, or do we expect to fall back to not
> >use the integrated assembler for the moment?
>
> We can condition it on `CLANG_VERSION >= 100001` (assuming Tom (CCed)
> is happy (and there is still time) cherrying pick the two commits https://bugs.llvm.org/show_bug.cgi?id=46076 to clang 10.0.1)
Good idea. I assume we will keep requiring fairly recent clang versions
for a while now, so chances are that 10.1 or 11.0 becomes the minimum
supported version not too far in the future and then the workaround can
be dropped again.
Arnd