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

Will Deacon
2020-05-06T15:48:11Z

On Wed, May 06, 2020 at 04:25:52PM +0100, Mark Brown wrote:
> On Wed, May 06, 2020 at 03:45:44PM +0100, Will Deacon wrote:
> > On Wed, May 06, 2020 at 02:40:21PM +0100, Dave Martin wrote:
>
> > > I really don't think we should fudge this: if the linker doesn't think
> > > the inputs are BTI-enabled then the compiler or linker is broken, or
> > > there's a bug in the kernel source tree.
>
> > > The checking done by the toolchain is important -- if we want to
> > > suppress it, we should have an override option than depends on BROKEN
> > > (because yes, you're explicitly risking a broken kernel if you do this).
>
> > > The fact that all gcc and clang both screwed this up in various ways at
> > > some point is not our fault, or our problem, providing that fixes are
> > > available...
>
> > > Am I being too paranoid?
>
> That's my position too, we want the warning - I think if we're going to
> do any handling it should either be to prevent use of kernel BTI
> entirely or to do what Will was originally suggesting and print some
> explanatory text somewhere. My inclination is that the former is safer
> and fits more with the general architecture approach to this sort of
> thing.
>
> > I don't think so, but I'm just looking for an answer to "What do we do if
> > people start running into this warning?". As it stands, it sounds like it's
> > unlikely that they will, but if they do then we're going to have to hack
> > something to make it go away.
>
> It's possible that this e-mail thread showing up in searches might well
> answer people's questions anyway (it is going to be one of the few hits
> for the warning ATM). How about we deal with this when we get to it, or
> at least as a followup?

Yes, I don't think it's worth writing patches for this now, just wanted
to get a vague idea of our options if people start complaining.

Cheers,

Will