From: Will Deacon <will@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>,
James Morse <james.morse@arm.com>,
Amit Daniel Kachhap <amit.kachhap@arm.com>,
Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
linux-arm-kernel@lists.infradead.org,
Daniel Kiss <daniel.kiss@arm.com>
Subject: Re: [PATCH] arm64: Optimize ptrauth by enabling it for non-leaf functions
Date: Tue, 14 Apr 2020 14:10:06 +0100 [thread overview]
Message-ID: <20200414131005.GA28750@willie-the-truck> (raw)
In-Reply-To: <20200414110922.GC2486@C02TD0UTHF1T.local>
On Tue, Apr 14, 2020 at 12:09:22PM +0100, Mark Rutland wrote:
> On Tue, Apr 14, 2020 at 12:00:56PM +0100, Will Deacon wrote:
> > On Tue, Apr 14, 2020 at 11:16:49AM +0100, Mark Rutland wrote:
> > > I believe this is because leaf functions don't store the LR to the stack
> > > (as they don't create a frame record), so it cannot be modified by a
> > > stray memory write.
> >
> > That makes some sense, but doesn't it also mean you can jump into the middle
> > of a leaf function and it will happily return to whatever sits in LR?
>
> If you can do that, you've already subverted control flow, and can
> probably do the same for a regular function, since for:
>
> | AUTIASP
> | RET
>
> ... you can just jump to the RET instead.
Perhaps, but it's not at all clear to me that being able to jump over the
AUT instruction is just as easy or useful as being able to jump into the
middle of a leaf function, which might act as a form of gadget. The commit
message is quite bold in saying "[this] is not useful from security point
of view".
How would this interact with BTI? Would we need to have different landing
pads for leaf functions?
> > Perhaps it would make sense to relax to the 'non-leaf' version only if
> > stack protector is enabled?
>
> I'm not sure I follow the rationale for that? What does stack protector
> help with for leaf functions?
Yeah, course it doesn't help because we're not pushing a frame. Ignore me.
Will
_______________________________________________
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-04-14 13:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 9:32 [PATCH] arm64: Optimize ptrauth by enabling it for non-leaf functions Amit Daniel Kachhap
2020-04-14 10:00 ` Will Deacon
2020-04-14 10:16 ` Mark Rutland
2020-04-14 10:58 ` Amit Kachhap
2020-04-14 11:11 ` Mark Rutland
2020-04-14 11:00 ` Will Deacon
2020-04-14 11:09 ` Mark Rutland
2020-04-14 13:10 ` Will Deacon [this message]
2020-04-14 14:07 ` Mark Rutland
2020-04-29 8:38 ` Amit Kachhap
2020-04-14 10:49 ` Amit Kachhap
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=20200414131005.GA28750@willie-the-truck \
--to=will@kernel.org \
--cc=Vincenzo.Frascino@arm.com \
--cc=amit.kachhap@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=daniel.kiss@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
/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