[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1410204197-31204-1-git-send-email-atomlin@redhat.com>
Date: Mon, 8 Sep 2014 20:23:14 +0100
From: Aaron Tomlin <atomlin@...hat.com>
To: peterz@...radead.org
Cc: mingo@...hat.com, dzickus@...hat.com, bmr@...hat.com,
jcastillo@...hat.com, atomlin@...hat.com, oleg@...hat.com,
pzijlstr@...hat.com, riel@...hat.com, linux-kernel@...r.kernel.org,
tglx@...utronix.de, x86@...nel.org, rostedt@...dmis.org,
hannes@...xchg.org, aneesh.kumar@...ux.vnet.ibm.com,
akpm@...ux-foundation.org, akpm@...gle.com,
linuxppc-dev@...ts.ozlabs.org, minchan@...nel.org
Subject: [PATCH v2 0/3] sched: Always check the integrity of the canary
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.
Changes since v1:
* Rebased against v3.17-rc4
* Add a canary to init_task - Oleg Nesterov
* Fix various code formatting issues - Peter Zijlstra
* Introduce Kconfig option - Peter Zijlstra
Aaron Tomlin (3):
init/main.c: Give init_task a canary
sched: Add helper for task stack page overrun checking
sched: BUG when stack end location is over written
arch/powerpc/mm/fault.c | 5 +----
arch/x86/mm/fault.c | 5 +----
include/linux/sched.h | 4 ++++
init/main.c | 1 +
kernel/fork.c | 12 +++++++++---
kernel/sched/core.c | 4 ++++
kernel/trace/trace_stack.c | 4 +---
lib/Kconfig.debug | 12 ++++++++++++
8 files changed, 33 insertions(+), 14 deletions(-)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists