public inbox for
 help / color / mirror / Atom feed
From: Will Newton <>
Subject: ARM per-thread stack protector
Date: Fri, 19 Jul 2013 16:34:00 -0000	[thread overview]
Message-ID: <> (raw)

Hi all,

I've been looking into implementing pre-thread stack protector
canaries for ARM and I would be interested in people's opinions on
whether I have understood it correctly.

At the moment the global canary value is stored in __stack_chk_guard
which is exported by glibc and accesses to this variable are emitted
by gcc if it detects a capable glibc version at configure time.

glibc with per-thread stack canary values does not export
__stack_chk_guard but adds an element to the TCB to contain the
per-thread value and gcc emits TP-relative accesses to load this

Implementing the per-thread scheme would therefore seem to me to break
ABI compatibility and cause problems when mixing gcc and glibc

Old gcc, old glibc: OK
Old gcc, new glibc: __stack_chk_guard is missing, link time failure.
New gcc, old glibc: stack canary value is loaded from uninitialized
TCB area, security issue.
New gcc, new glibc: OK.

It should be possible to add support for both schemes at the same time
in glibc, exporting __stack_chk_guard at the same time as supporting
per-thread canary values, which would fix the "old gcc, new glibc"

I am not sure if there is a good fix for "new gcc, old glibc",
although gcc configure could be taught about glibc versions and do the
right thing for each.

Or is there a simpler way to handle this? Has any other architecture
implemented per-thread stack protector after already supporting the
simpler scheme?


Will Newton
Toolchain Working Group, Linaro

             reply	other threads:[~2013-07-19 16:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-19 16:34 Will Newton [this message]
2013-07-19 21:41 ` Roland McGrath
2013-07-22  9:15   ` Will Newton
2013-07-22 22:01     ` Roland McGrath

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \

* 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).