linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tip-bot for Chuck Ebbert <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@kernel.org,
	cebbert.lkml@gmail.com, james.hogan@imgtec.com,
	atomlin@redhat.com, tglx@linutronix.de
Subject: [tip:sched/urgent] sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK_GROWSUP
Date: Fri, 19 Sep 2014 23:42:37 -0700	[thread overview]
Message-ID: <tip-a3215fb47c7ecb814dc16815245db4f375841268@git.kernel.org> (raw)
In-Reply-To: <20140919093505.62681e43@as>

Commit-ID:  a3215fb47c7ecb814dc16815245db4f375841268
Gitweb:     http://git.kernel.org/tip/a3215fb47c7ecb814dc16815245db4f375841268
Author:     Chuck Ebbert <cebbert.lkml@gmail.com>
AuthorDate: Fri, 19 Sep 2014 09:35:05 -0500
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Sat, 20 Sep 2014 08:38:16 +0200

sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK_GROWSUP

Aaron Tomlin recently posted patches to enable checking the
stack canary on every task switch:

  http://lkml.org/lkml/2014/9/12/293

Looking at the canary code, I realized that every arch
(except ia64, which adds some space for register spill
above the stack) shares a definition of end_of_stack()
that makes it the first long after the threadinfo.

For stacks that grow down, this low address is correct
because the stack starts at the end of the thread area
and grows toward lower addresses. However, for stacks
that grow up, toward higher addresses, this is wrong.
(The stack actually grows away from the canary.)

On these archs end_of_stack() should return the address
of the last long, at the highest possible address for
the stack.

Signed-off-by: Chuck Ebbert <cebbert.lkml@gmail.com>
Tested-by: James Hogan <james.hogan@imgtec.com> [metag]
Acked-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Aaron Tomlin <atomlin@redhat.com>
Link: http://lkml.kernel.org/r/20140919093505.62681e43@as
[ Added comments to end_of_stack(). ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 include/linux/sched.h | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..0e20a24 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2608,9 +2608,22 @@ static inline void setup_thread_stack(struct task_struct *p, struct task_struct
 	task_thread_info(p)->task = p;
 }
 
+/*
+ * Return the address of the first long before (or after,
+ * depending on the architecture's default stack growth
+ * direction) * a task's task_info structure, which is the
+ * kernel stack's last usable spot.
+ *
+ * This is the point of no return, if the stack grows
+ * beyond that position, we corrupt the task's state.
+ */
 static inline unsigned long *end_of_stack(struct task_struct *p)
 {
+#ifdef CONFIG_STACK_GROWSUP
+	return (unsigned long *)((unsigned long)task_thread_info(p) + THREAD_SIZE) - 1;
+#else
 	return (unsigned long *)(task_thread_info(p) + 1);
+#endif
 }
 
 #endif

  reply	other threads:[~2014-09-20  6:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-19 14:35 [PATCH V2] Fix end_of_stack() and location of stack canary for archs using STACK_GROWSUP Chuck Ebbert
2014-09-20  6:42 ` tip-bot for Chuck Ebbert [this message]
2014-09-20 11:58   ` [tip:sched/urgent] sched: Fix end_of_stack() and location of stack canary for architectures using CONFIG_STACK_GROWSUP Chuck Ebbert
2014-09-20 14:28     ` Ingo Molnar
2014-09-20 15:17       ` [PATCH v3] " Chuck Ebbert
2014-09-20 17:45         ` [tip:sched/urgent] " tip-bot for Chuck Ebbert

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=tip-a3215fb47c7ecb814dc16815245db4f375841268@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=atomlin@redhat.com \
    --cc=cebbert.lkml@gmail.com \
    --cc=hpa@zytor.com \
    --cc=james.hogan@imgtec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /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 NNTP newsgroup(s).