From: Will Deacon <will@kernel.org>
To: Amit Kachhap <amit.kachhap@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>,
James Morse <james.morse@arm.com>,
Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
linux-arm-kernel@lists.infradead.org,
Daniel Kiss <daniel.kiss@arm.com>
Subject: Re: [PATCH v2] arm64: Optimize ptrauth by enabling it for non-leaf functions
Date: Thu, 30 Apr 2020 12:05:47 +0100 [thread overview]
Message-ID: <20200430110547.GJ19932@willie-the-truck> (raw)
In-Reply-To: <ee659a51-4719-ff17-6d3d-4fc42504111e@arm.com>
On Thu, Apr 30, 2020 at 04:30:57PM +0530, Amit Kachhap wrote:
> On 4/29/20 3:48 PM, Mark Rutland wrote:
> > On Wed, Apr 29, 2020 at 02:06:10PM +0530, Amit Daniel Kachhap wrote:
> > > Compilers are optimized to not create the frame record for the leaf
> > > function and hence lr is not signed and stored in the stack. Thus the leaf
> > > functions cannot be used for ROP gadget attack.
> >
> > IIUC Will's point on the last posting was that leaf functions can be
> > used as a restricted ROP gadget, where the LR isn't controlled via the
> > stack.
> >
> > e.g. you might have a gadget that does something like:
> >
> > <gadget>:
> > LDP x0, x1, [SP], #16
> > STR x0, [x1]
> > RET // LR == <gadget>
> >
> > ... and if the LR had previously been set up to point to gadget, it
> > would return recursively, performing a sequence of arbitrary stores.
> > With an AUT, it would fail after the first store.
> >
> > That does rely on already subverting control flow (probably via a
> > forward-edge BR where we don't have BTI), and so maybe we've already
> > lost in practical terms, but there is at least some possibility of a
> > gadget that AUT would catch here. There's some nuance to capture in the
> > commit message for that.
>
> I had some offline discussion with Daniel Kiss about this patch. I am
> stopping this patch work now as there are some use case of ptrauth
> instructions in leaf functions. This may be re-visited later with precise
> runtime data if needed.
Ok, thanks for letting us know.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2020-04-30 11:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 8:36 [PATCH v2] arm64: Optimize ptrauth by enabling it for non-leaf functions Amit Daniel Kachhap
2020-04-29 10:18 ` Mark Rutland
2020-04-29 16:01 ` Amit Kachhap
2020-04-30 11:00 ` Amit Kachhap
2020-04-30 11:05 ` Will Deacon [this message]
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=20200430110547.GJ19932@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 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.