[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a3-L-AQomvTcBv-KH1cVVu6uYNT_-2Ofir3UgwzGjcSug@mail.gmail.com>
Date: Wed, 27 May 2020 20:28:07 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Mark Rutland <mark.rutland@....com>,
Fangrui Song <maskray@...gle.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>
Subject: Re: [PATCH] arm64: disable -fsanitize=shadow-call-stack for big-endian
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?
Arnd
Powered by blists - more mailing lists