All of lore.kernel.org
 help / color / mirror / Atom feed
From: ramana.radhakrishnan@arm.com (Ramana Radhakrishnan)
To: linux-arm-kernel@lists.infradead.org
Subject: per-task stack canaries for arm64
Date: Thu, 18 Jan 2018 10:26:02 +0000	[thread overview]
Message-ID: <f80404f3-985f-9e3b-2ad3-f2b0fc2a8b28@arm.com> (raw)
In-Reply-To: <CAGXu5j+PO=Ben0J-xnOztrAdsku2SUKFiz6w7cqTEfHTveFFSg@mail.gmail.com>

On 1/17/18 8:45 PM, Kees Cook wrote:
> On Wed, Jan 17, 2018 at 12:32 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
>> On 17 January 2018 at 19:10, Kees Cook <keescook@chromium.org> wrote:
>>> On Wed, Jan 17, 2018 at 10:24 AM, Ard Biesheuvel
>>> <ard.biesheuvel@linaro.org> wrote:
>> [...]
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81708
>>> which was done for x86 only, and provides both:
>>>   -mstack-protector-guard-symbol=...
>>>   -mstack-protector-guard-reg=...
>>>
>>> If this could be extended to arm64, I think we'd be in good shape (and
>>> it could be trivially detected at build time).
>>>
>>
>> I'm not entirely sure what the point is of specifying the name of the
>> symbol on the command line. It is ultimately up to the GCC developers
>> to decide how much point there is to maintaining parity with x86 here.
>>
>> [...]
>>>> Ramana indicated at the time that he would be up for adding, e.g.,
>>>> -fstack-protector-linux-kernel as a command line option, and add the
>>>> contents of tpidr_el1 to every reference of __stack_chk_guard when
>>>> set.

Wow, that was a hall-way conversation eons ago. It took me a while to
page that in.


>>>
>>> I think we want to reuse the command-line names from the x86 options
>>> above, unless there's a good reason not to?
>>
>> I'm perfectly happy to settle for whatever the GCC developers manage
>> to agree on, as long as it gives us the ability to use tpidr_el1 as
>> the offset.
> 
> Ramana, Uro?, what's the best next step? Should we open a GCC bug
> specifically for arm64 here?

The next best step is someone opening a GCC feature request with some
more details - CC'ing me on ramana at gcc.gnu.org should work. What I would
like to see is a feature request on GCC bugzilla along with some
comments / buyin from the AArch64 kernel maintainers whether they would
like to see such a feature and what the behaviour should be and get some
feedback from the AArch64 GCC maintainers upstream before starting the
work.

I think the following (unoptimized) or some derivative of this should work.

        adrp    x19, __stack_chk_guard
        add     x19, x19, :lo12:__stack_chk_guard
	mrs 	x2, tpidr_el1
	add	x2, x2, x19
	ldr 	x2, [x2]


It's also not likely that this will be done in time for GCC 8 as we are
now in stage 4 and we're probably looking at GCC 9 for this assuming
this goes ahead.

Hope this helps.

regards
Ramana

> 
> -Kees
> 

  reply	other threads:[~2018-01-18 10:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17 18:24 per-task stack canaries for arm64 Ard Biesheuvel
2018-01-17 19:10 ` Kees Cook
2018-01-17 20:32   ` Ard Biesheuvel
2018-01-17 20:45     ` Kees Cook
2018-01-18 10:26       ` Ramana Radhakrishnan [this message]
2018-01-18 13:19         ` Ard Biesheuvel
2018-01-22 10:59           ` Ard Biesheuvel
2018-01-22 12:26             ` Kees Cook
2018-01-22 12:42               ` Ard Biesheuvel
2018-01-22 16:28                 ` Ard Biesheuvel

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=f80404f3-985f-9e3b-2ad3-f2b0fc2a8b28@arm.com \
    --to=ramana.radhakrishnan@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.