Re: [PATCH] arm64: bti: Fix support for userspace only BTI

From: Dave Martin <Dave.Martin@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: bti: Fix support for userspace only BTI
Date: Wed, 13 May 2020 17:49:38 +0100	[thread overview]
Message-ID: <20200513164937.GW21779@arm.com> (raw)
In-Reply-To: <20200513150822.GK4803@sirena.org.uk>

On Wed, May 13, 2020 at 04:08:22PM +0100, Mark Brown wrote:
> On Wed, May 13, 2020 at 03:46:25PM +0100, Dave Martin wrote:
> > On Tue, May 12, 2020 at 12:05:02PM +0100, Mark Brown wrote:
> 
> > > To enable BTI for the vDSO we need the vDSO to be built with BTI
> > > annotations.  Currently the CFLAGS are the same for the vDSO and the
> > > kernel, we could arrange to allow them to differ but since the most
> > > likely reason why the user has userspace but not kernel BTI is that
> > > their compiler isn't suitable it seemed like disproportionate effort
> > > for a most likely small audience.
> 
> > The situation where the user is stuck on a binary vendor kernel built
> > using obsolete or wrongly configured tools doesn't sound that unlikely
> > to me.
> 
> They'd need to be stuck on a binary vendor kernel which is sufficiently
> new to have BTI support but using toolchains that are sufficiently old
> to be unable to BTI the kernel (if their vendor went out of their way to
> disable BTI then that's another issue).  My guess is that people will
> tend to update major versions of these at relatively similar times, and
> hopefully if people are going to the trouble of backporting BTI they'll
> also grab the toolchain bits since it's substantially more useful if you
> can compile userspace.

Yeah, just playing devil's advocate.

> > When the vdso was all asm, we could easily have solved this by manually
> > annotating it ... I guess that's the price of progress, unless anyone
> > has a bright idea :/
> 
> Which is the other bit - if we don't trust the toolchain to build the
> kernel then we probably ought to have concerns about the C bits of the
> vDSO as well.  Even if they're fine now some future vDSO change could
> cause this to explode.

Exactly.  So I guess you're right: no kernel BTI, no vDSO BTI.  It's
a bit annoying, but there it is.

I can't argue that the best fix for broken tools isn't to fix the
tools ;)

Cheers
---Dave

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