All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:46:25 +0100	[thread overview]
Message-ID: <20200513144624.GR21779@arm.com> (raw)
In-Reply-To: <20200512110502.GC5110@sirena.org.uk>

On Tue, May 12, 2020 at 12:05:02PM +0100, Mark Brown wrote:
> On Tue, May 12, 2020 at 11:39:09AM +0100, Will Deacon wrote:
> 
> > Might be worth a comment here in case somebody tries to "clean this up"
> > later on!
> 
> > > +#ifdef CONFIG_ARM64_BTI_KERNEL
> > >  #define PTE_MAYBE_GP		(system_supports_bti() ? PTE_GP : 0)
> > > +#else
> > > +#define PTE_MAYBE_GP		0
> > > +#endif
> 
> Sure.
> 
> > I also notice we have a funny check in the vdso code:
> 
> >   if (IS_ENABLED(CONFIG_ARM64_BTI_KERNEL) && system_supports_bti())
> 
> > but why do we care about CONFIG_ARM64_BTI_KERNEL for the vdso pages?
> 
> 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.

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 :/

Cheers
---Dave

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

  parent reply	other threads:[~2020-05-13 15:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12  9:21 [PATCH] arm64: bti: Fix support for userspace only BTI Mark Brown
2020-05-12 10:39 ` Will Deacon
2020-05-12 11:05   ` Mark Brown
2020-05-12 11:42     ` Will Deacon
2020-05-13 14:46     ` Dave Martin [this message]
2020-05-13 15:08       ` Mark Brown
2020-05-13 16:49         ` Dave Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200513144624.GR21779@arm.com \
    --to=dave.martin@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.