Re: [PATCH v3 00/11] arm64: BTI kernel and vDSO support

Will Deacon
2020-05-07T16:37:09Z

On Thu, May 07, 2020 at 05:30:45PM +0100, Mark Brown wrote:
> On Thu, May 07, 2020 at 04:55:24PM +0100, Will Deacon wrote:
> > On Thu, May 07, 2020 at 04:48:54PM +0100, Mark Brown wrote:
>
> > > Right, I'm seeing it here now - it's when CONFIG_GCOV_KERNEL is enabled
> > > and happens for clang-10 as well but not a GCC 10 prerelease build.
>
> > Interesting. Is that because GCC doesn't emit out-of-line GCOV functions,
> > or does it emit PAC/BTI instructions for them instead? (you can disassemble
> > one of the problematic opjects to have a look).
>
> GCC does emit some helper functions wrapping GCOV stuff but they have
> appropriate annotations, eg:
>
> 00000000000000ac <_sub_D_00100_1>:
> ac: d503245f bti c
> b0: a9bf7bfd stp x29, x30, [sp, #-16]!
> b4: 910003fd mov x29, sp
> b8: 94000000 bl 0 <__gcov_exit>
> bc: a8c17bfd ldp x29, x30, [sp], #16
> c0: d65f03c0 ret

Hmm, where have the PAC/AUT instructions gone?

> I can also reproduce this for clang with a trivial standalone source
> file and -fprofile-arcs -mbranch-protection=bti so it's nothing funky
> the kernel is doing as far as I can see.

Good.

> > I can't immediately see how to fix it, so your hack above might be the best
> > bet for now. I'm just a little wary that it might not be limited to GCOV,
> > but rather anything where the compiler provides a form of runtime.
>
> Indeed. I guess the nice thing with BTI is that if something goes wrong
> it will do so rather visibly so unless there are situations where the
> toolchain emits rarely called functions the problems will tend to be
> very obvious, and it seems that clang is detecting the problem itself
> and complaining loudly which makes it even more likely that if something
> else is affected it'll be noticed and we can at least add similar
> bodges.
>
> It does seem it's a straight compiler issue, if the compiler is emitting
> runtime then the compiler ought to be ensuring that it agrees with the
> build options the compiler was given and I can't think how this would be
> fixable or avoidable outside of the compiler other than "don't do that"
> which is what my Kconfig bodge did. I'm talking to the toolchain people
> internally about this.

Thanks. I'll apply your 'depends on ...' line locally and push that out
if I don't run into any more issues.

Will