From: Dave Martin <Dave.Martin@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: maz@kernel.org, Jean-Philippe Brucker <jean-philippe@linaro.org>,
will@kernel.org, linux-arm-kernel@lists.infradead.org,
catalin.marinas@arm.com
Subject: Re: [PATCH] arm64: Don't insert a BTI instruction at inner labels
Date: Wed, 24 Jun 2020 14:44:25 +0100 [thread overview]
Message-ID: <20200624134424.GE25945@arm.com> (raw)
In-Reply-To: <20200624132114.GB5472@sirena.org.uk>
On Wed, Jun 24, 2020 at 02:21:14PM +0100, Mark Brown wrote:
> On Wed, Jun 24, 2020 at 01:22:54PM +0200, Jean-Philippe Brucker wrote:
>
> > It turns out we don't currently need the BTI landing pads inserted by
> > SYM_INNER_LABEL:
>
> > * ftrace_call and ftrace_graph_call are only used for runtime patching
> > of the active tracer. The patched code is not reached from a branch.
> > * install_el2_stub is reached from a CBZ instruction, which doesn't
> > change PSTATE.BTYPE.
> > * __guest_exit is reached from B instructions in the hyp-entry vectors,
> > which aren't subject to BTI checks either.
>
> > Remove the BTI annotation from SYM_INNER_LABEL.
>
> This fixes things for now but it feels like it's going to be fragile in
> the long run since inner labels are a bit of a wild west in terms of how
> they're going to be referenced - I can't think of a better solution at
> this level though :(
>
> Reviewed-by: Mark Brown <broonie@kernel.org>
Since inner labels requiring landing pads are going to be the exception
rather than the rule, perhaps we can introduce a different macro for
this. It feels arch-specific to me (indeed, inner labels are kind of
arch-specific, since they're inevitably in the middle of some asm that
is unlikely to be handled by core code).
Do we know of any code that requires landing pads on inner labels?
The uaccess fault stuff probably doesn't, because the error path is
reached via ERET. I wondered about the suspend/resume code in sleep.S,
but I don't see any inner labels in there.
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-24 13:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-24 11:22 [PATCH] arm64: Don't insert a BTI instruction at inner labels Jean-Philippe Brucker
2020-06-24 13:21 ` Mark Brown
2020-06-24 13:44 ` Dave Martin [this message]
2020-06-24 14:15 ` Mark Brown
2020-06-24 13:54 ` Will Deacon
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=20200624134424.GE25945@arm.com \
--to=dave.martin@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jean-philippe@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).