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

From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@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 13:27:10 +0100	[thread overview]
Message-ID: <20200506122709.GE8043@willie-the-truck> (raw)
In-Reply-To: <20200506114353.GB5299@sirena.org.uk>

On Wed, May 06, 2020 at 12:43:53PM +0100, Mark Brown wrote:
> On Wed, May 06, 2020 at 11:50:06AM +0100, Will Deacon wrote:
> > On Wed, May 06, 2020 at 11:41:52AM +0100, Mark Brown wrote:
> 
> > > Well, the theory behind the warning is that if the compiler is emitting
> > > code suitable for the features described in the note then it should
> > > always emit the appropriate annotations so the warning is more intended
> > > to be telling the user that the code is trying to link in code that's
> > > not built properly and will most likely fail at runtime.  In the current
> 
> > Hmm, I suppose, although it's a bit belt-and-braces given that we've got
> > the right options in KBUILD_CFLAGS. What about:
> 
> We know we're doing fine but the warning is being emitted by the linker
> rather than something in the kernel tree and it doesn't know what the
> users are or that they invoked their compilers correctly.
> 
> > 	"Your compiler is not emitting '.note.gnu.property' sections: forcing
> > 	 support for BTI in the linker, but check your CFLAGS and consider
> > 	 upgrading your toolchain."
> 
> > I'd usually not be too bothered, but having run into this yesterday and
> > not understood the problem, I'd like to save somebody else from puzzling
> > over this if we can!
> 
> That's a bit C specific - CFLAGS isn't going to apply to other
> languages and binutils could be linking pretty much anything.  TBH I'd
> expect one of the common cases would be assembler given the pain
> involved in generating notes.  Possibly "build configuration and
> toolchain" instead but that's also pretty vague so might not help much
> with people being confused?  Either way any diagnostic change would be a
> binutils change, I've flagged this up to the toolchain people
> internally.

Ah, that's where we're talking past each other: I was only thinking of
printing this from the Makefile after seeing the warning from ld. I
completely agree that the stuff I was suggesting is kernel-specific, and
sorry for not being clear.

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.

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?

> 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.

Will

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