[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a1tSKYeDDmAK3o6thazjbua-KmxRNQPX9448qjgp8iV=g@mail.gmail.com>
Date: Wed, 27 May 2020 21:01:45 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Fangrui Song <maskray@...gle.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
Kees Cook <keescook@...omium.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
Tom Stellard <tstellar@...hat.com>
Subject: Re: [PATCH] arm64: disable -fsanitize=shadow-call-stack for big-endian
On Wed, May 27, 2020 at 8:35 PM 'Fangrui Song' via Clang Built Linux
<clang-built-linux@...glegroups.com> wrote:
> On 2020-05-27, Arnd Bergmann wrote:
> >On Wed, May 27, 2020 at 7:28 PM 'Nick Desaulniers' via Clang Built
> >Linux <clang-built-linux@...glegroups.com> wrote:
> >>
> >> On Wed, May 27, 2020 at 8:24 AM Mark Rutland <mark.rutland@....com> 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 <arnd@...db.de>
> >> >
> >> > 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
Powered by blists - more mailing lists