Re: [PATCH v2 02/10] arm64: asm: Override SYM_FUNC_START when building the kernel with BTI

From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
	Kees Cook <keescook@chromium.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 02/10] arm64: asm: Override SYM_FUNC_START when building the kernel with BTI
Date: Wed, 6 May 2020 14:03:34 +0100	[thread overview]
Message-ID: <20200506130334.GD5299@sirena.org.uk> (raw)
In-Reply-To: <20200506122709.GE8043@willie-the-truck>

[-- Attachment #1.1: Type: text/plain, Size: 2560 bytes --]

On Wed, May 06, 2020 at 01:27:10PM +0100, Will Deacon wrote:

> That said, without a way for the linker to force bti *without* generating
> the warning, I'm not sure how we could implement this sensibly. The warning
> also seems only to be generated if some objects have the BTI property and
> others don't; if all objects are missing it then it's quiet.

Oh, that's annoying - I'd expected the warning to be generated if any of
the inputs miss the BTI annotation.  Part of my goal with turning it on 
was to provide some defensiveness against future breakage which could
potentially include messing something up with enabling BTI for the
inputs.  I'll tell the toolchain people about that too :/

> Maybe we could detect that the compiler doesn't generate the property
> section, and then avoid generating them in our assembly files? i.e.
> wrap '.macro emit_aarch64_feature_1_and' in a #ifdef CC_HAS_GNU_PROPERTY
> ... #endif block?

If we're going to do this detection it might be better to just disable
kernel BTI support entirely if the toolchain doesn't emit the notes,
treating the missing notes as a most likely overcautious warning flag
that there might be code generation bugs as well.  Either way it does
feel like a lot of work.

> > I do think that this will be a lot easier going forwards - hopefully the
> > problem with the toolchain not generating notes is not going to be an
> > issue by the time people are actively deploying BTI (people using GCC
> > are going to need a shiny new version anyway and I don't know how
> > widespread the clang versions that have issues are), and if people do
> > start running into it then it'll be possible to usefully search for the
> > error message online which should help a lot.

> I think we'll get reports of people running into this (I hit it with a
> defconfig build), so just looking for an idea of what we might do if/when
> that happens.

Bear in mind that to use BTI kernel support you need to be using either
clang or version 10 or later of GCC (which hasn't yet been released,
it's almost there) so it's not going to be triggering in the common case
where people are using released GCC versions.  The change in clang that
you're missing is:

   https://reviews.llvm.org/rGd53e61863d48a07ce285d5b0a36abc67583023bd

which is from December last year so rather recent meaning I do think
it's a valid concern for clang, I'm just not sure how widespread clang
usage is with people who don't also update their toolchains with a
fairly high frequency.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel