From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>
Cc: James.Greenhalgh@arm.com,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
Marcus Shawcroft <Marcus.Shawcroft@arm.com>,
gcc-patches@gcc.gnu.org, Will Deacon <Will.Deacon@arm.com>,
Mark Rutland <Mark.Rutland@arm.com>, nd <nd@arm.com>
Subject: Re: [RFC][AArch64] Add support for system register based stack protector canary access
Date: Mon, 03 Dec 2018 16:40:00 -0000 [thread overview]
Message-ID: <CAKv+Gu_BFGeBGigvyV8uaQ-GOeY_AY=PoFm53nY8ye37ZTDtsw@mail.gmail.com> (raw)
In-Reply-To: <7a5a57fa-629d-d2ff-6292-e0893647ec8a@arm.com>
On Mon, 3 Dec 2018 at 10:55, Ramana Radhakrishnan
<Ramana.Radhakrishnan@arm.com> wrote:
>
> For quite sometime the kernel guys, (more specifically Ard) have been
> talking about using a system register (sp_el0) and an offset from that
> for a canary based access. This patchset adds support for a new set of
> command line options similar to how powerpc has done this.
>
> I don't intend to change the defaults in userland, we've discussed this
> for user-land in the past and as far as glibc and userland is concerned
> we stick to the options as currently existing. The system register
> option is really for the kernel to use along with an offset as they
> control their ABI and this is a decision for them to make.
>
> I did consider sticking this all under a mcmodel=kernel-small option but
> thought that would be a bit too aggressive. There is very little error
> checking I can do in terms of the system register being used and really
> the assembler would barf quite quickly in case things go wrong. I've
> managed to rebuild Ard's kernel tree with an additional patch that
> I will send to him. I haven't managed to boot this kernel.
>
> There was an additional question asked about the performance
> characteristics of this but it's a security feature and the kernel
> doesn't have the luxury of a hidden symbol. Further since the kernel
> uses sp_el0 for access everywhere and if they choose to use the same
> register I don't think the performance characteristics would be too bad,
> but that's a decision for the kernel folks to make when taking in the
> feature into the kernel.
>
> I still need to add some tests and documentation in invoke.texi but
> this is at the stage where it would be nice for some other folks
> to look at this.
>
> The difference in code generated is as below.
>
> extern void bar (char *);
> int foo (void)
> {
> char a[100];
> bar (&a);
> }
>
> $GCC -O2 -fstack-protector-strong vs
> -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard=sysreg
> -mstack-protector-guard-offset=1024 -fstack-protector-strong
>
>
> --- tst.s 2018-12-03 09:46:21.174167443 +0000
> +++ tst.s.1 2018-12-03 09:46:03.546257203 +0000
> @@ -15,15 +15,14 @@
> mov x29, sp
> str x19, [sp, 16]
> .cfi_offset 19, -128
> - adrp x19, __stack_chk_guard
> - add x19, x19, :lo12:__stack_chk_guard
> - ldr x0, [x19]
> - str x0, [sp, 136]
> - mov x0,0
> + mrs x19, sp_el0
> add x0, sp, 32
> + ldr x1, [x19, 1024]
> + str x1, [sp, 136]
> + mov x1,0
> bl bar
> ldr x0, [sp, 136]
> - ldr x1, [x19]
> + ldr x1, [x19, 1024]
> eor x1, x0, x1
> cbnz x1, .L5
>
>
>
>
> I will be afk tomorrow and day after but this is to elicit some comments
> and for Ard to try this out with his kernel patches.
>
Thanks Ramana. I managed to build and run a complete kernel (including
modules) on a bare metal system, and everything works as expected.
The only thing I'd like to confirm with you is the logic wrt the
command line arguments, more specifically, if/when all 3 arguments
have to appear, and whether they are permitted to appear if
-fstack-protector is not set.
This is relevant given that we invoke the compiler in 3 different ways:
- at the configure stage, we invoke the compiler with some/all of
these options to decide whether the feature is supported, but the
actual offset is not known, but also irrelevant
- we invoke the compiler to build the header file that actually gives
us the offset to pass to later invocations
- finally, all kernel objects are built with all 3 arguments passed on
the command line
It looks like your code permits -mstack-protector-guard-reg at any
time, but only permits -mstack-protector-guard-offset if
-mstack-protector-guard is set to sysreg (and thus set explicitly,
since the default is global). Is that intentional? Can we expect this
to remain like that?
next prev parent reply other threads:[~2018-12-03 16:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 9:55 Ramana Radhakrishnan
2018-12-03 9:59 ` Jakub Jelinek
2018-12-03 10:03 ` Ramana Radhakrishnan
2018-12-03 15:31 ` Florian Weimer
2018-12-03 16:40 ` Ard Biesheuvel [this message]
2019-01-10 16:53 ` Ramana Radhakrishnan
2019-01-10 10:53 ` Ramana Radhakrishnan
2019-01-10 11:05 ` Jakub Jelinek
2019-01-10 12:51 ` Ramana Radhakrishnan
2019-01-10 15:49 ` James Greenhalgh
2019-01-10 15:55 ` Will Deacon
2019-01-10 16:49 ` Ramana Radhakrishnan
2019-01-19 17:30 ` Jakub Jelinek
2018-12-04 3:51 Wilco Dijkstra
2018-12-04 12:58 ` Florian Weimer
2018-12-07 14:51 ` Ramana Radhakrishnan
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='CAKv+Gu_BFGeBGigvyV8uaQ-GOeY_AY=PoFm53nY8ye37ZTDtsw@mail.gmail.com' \
--to=ard.biesheuvel@linaro.org \
--cc=James.Greenhalgh@arm.com \
--cc=Marcus.Shawcroft@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Ramana.Radhakrishnan@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=Will.Deacon@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=nd@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).