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

From: Will Deacon <will@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Amit Kachhap <amit.kachhap@arm.com>,
	Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 00/11] arm64: BTI kernel and vDSO support
Date: Thu, 7 May 2020 17:36:58 +0100	[thread overview]
Message-ID: <20200507163658.GC2648@willie-the-truck> (raw)
In-Reply-To: <20200507163045.GD6183@sirena.org.uk>

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

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