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

Mark Brown
2020-05-06T15:26:31Z

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

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?

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

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