From: Aaron Tomlin <atomlin@redhat.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "peterz@infradead.org" <peterz@infradead.org>,
"dzickus@redhat.com" <dzickus@redhat.com>,
"jcastillo@redhat.com" <jcastillo@redhat.com>,
"riel@redhat.com" <riel@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"minchan@kernel.org" <minchan@kernel.org>,
"mingo@kernel.com" <mingo@kernel.com>,
"bmr@redhat.com" <bmr@redhat.com>,
"prarit@redhat.com" <prarit@redhat.com>,
"oleg@redhat.com" <oleg@redhat.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"aneesh.kumar@linux.vnet.ibm.com"
<aneesh.kumar@linux.vnet.ibm.com>,
"akpm@google.com" <akpm@google.com>,
"jgh@redhat.com" <jgh@redhat.com>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"pzijlstr@redhat.com" <pzijlstr@redhat.com>
Subject: Re: [PATCH v3 0/3] sched: Always check the integrity of the canary
Date: Thu, 11 Sep 2014 18:44:09 +0100 [thread overview]
Message-ID: <20140911174408.GA1873@atomlin.usersys.redhat.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D17490245@AcuExch.aculab.com>
On Thu, Sep 11, 2014 at 04:02:45PM +0000, David Laight wrote:
> From: Aaron Tomlin
> > Currently in the event of a stack overrun a call to schedule()
> > does not check for this type of corruption. This corruption is
> > often silent and can go unnoticed. However once the corrupted
> > region is examined at a later stage, the outcome is undefined
> > and often results in a sporadic page fault which cannot be
> > handled.
> >
> > The first patch adds a canary to init_task's end of stack.
> > While the second patch provides a helper to determine the
> > integrity of the canary. The third checks for a stack
> > overrun and takes appropriate action since the damage
> > is already done, there is no point in continuing.
>
> Clearly you've just been 'bitten' by a kernel stack overflow.
> But a simple 'canary' isn't going to find most of the overflows
> and will give an incorrect 'sense of security'.
Please note that this is not suppose to be a 'perfect' solution.
Rather a worth while check in this particular code path.
Let's assume that the canary is damaged. In this situation it is
rather likely that the thread_info object has been compromised too.
--
Aaron Tomlin
prev parent reply other threads:[~2014-09-11 17:47 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-04 14:50 [PATCH 0/2] sched: Always check the integrity of the canary Aaron Tomlin
2014-09-04 14:50 ` [PATCH 1/2] sched: Add helper for task stack page overrun checking Aaron Tomlin
2014-09-04 15:02 ` Oleg Nesterov
2014-09-04 15:52 ` Aaron Tomlin
2014-09-04 15:30 ` Peter Zijlstra
2014-09-04 14:50 ` [PATCH 2/2] sched: BUG when stack end location is over written Aaron Tomlin
2014-09-04 15:32 ` Peter Zijlstra
2014-09-04 16:11 ` Aaron Tomlin
2014-09-08 19:23 ` [PATCH v2 0/3] sched: Always check the integrity of the canary Aaron Tomlin
2014-09-08 19:23 ` [PATCH 1/3] init/main.c: Give init_task a canary Aaron Tomlin
2014-09-08 19:23 ` [PATCH 2/3] sched: Add helper for task stack page overrun checking Aaron Tomlin
2014-09-08 19:23 ` [PATCH 3/3] sched: BUG when stack end location is over written Aaron Tomlin
2014-09-09 9:42 ` [PATCH v2 0/3] sched: Always check the integrity of the canary Aaron Tomlin
2014-09-09 9:42 ` [PATCH v2 1/3] init/main.c: Give init_task a canary Aaron Tomlin
2014-09-10 7:26 ` Chuck Ebbert
2014-09-10 13:29 ` Aaron Tomlin
2014-09-11 12:23 ` Chuck Ebbert
2014-09-11 14:47 ` Aaron Tomlin
2014-09-09 9:42 ` [PATCH v2 2/3] sched: Add helper for task stack page overrun checking Aaron Tomlin
2014-09-09 9:42 ` [PATCH v2 3/3] sched: BUG when stack end location is over written Aaron Tomlin
2014-09-11 15:41 ` [PATCH v3 0/3] sched: Always check the integrity of the canary Aaron Tomlin
2014-09-11 15:41 ` [PATCH v3 1/3] init/main.c: Give init_task a canary Aaron Tomlin
2014-09-12 7:28 ` Michael Ellerman
2014-09-11 15:41 ` [PATCH v3 2/3] sched: Add helper for task stack page overrun checking Aaron Tomlin
2014-09-11 15:41 ` [PATCH v3 3/3] sched: BUG when stack end location is over written Aaron Tomlin
2014-09-12 4:06 ` Michael Ellerman
2014-09-12 9:44 ` Aaron Tomlin
2014-09-12 10:58 ` Mike Galbraith
2014-09-15 2:39 ` Michael Ellerman
2014-09-12 6:04 ` Michael Ellerman
2014-09-12 9:50 ` Aaron Tomlin
2014-09-11 15:53 ` [PATCH v3 0/3] sched: Always check the integrity of the canary Peter Zijlstra
2014-09-11 15:59 ` Aaron Tomlin
2014-09-11 16:02 ` David Laight
2014-09-11 17:26 ` Chuck Ebbert
2014-09-12 8:43 ` David Laight
2014-09-11 17:44 ` Aaron Tomlin [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=20140911174408.GA1873@atomlin.usersys.redhat.com \
--to=atomlin@redhat.com \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@google.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=bmr@redhat.com \
--cc=dzickus@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=jcastillo@redhat.com \
--cc=jgh@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=minchan@kernel.org \
--cc=mingo@kernel.com \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=prarit@redhat.com \
--cc=pzijlstr@redhat.com \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 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).