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

From: Mark Brown <broonie@kernel.org>
To: Dave Martin <Dave.Martin@arm.com>
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 16:08:22 +0100	[thread overview]
Message-ID: <20200513150822.GK4803@sirena.org.uk> (raw)
In-Reply-To: <20200513144624.GR21779@arm.com>

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

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.

> 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.

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

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

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