linux-kernel - RE: [PATCH v3 0/3] sched: Always check the integrity of the canary

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17490889@AcuExch.aculab.com>
Date:	Fri, 12 Sep 2014 08:43:45 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Chuck Ebbert' <cebbert.lkml@...il.com>
CC:	'Aaron Tomlin' <atomlin@...hat.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"dzickus@...hat.com" <dzickus@...hat.com>,
	"jcastillo@...hat.com" <jcastillo@...hat.com>,
	"riel@...hat.com" <riel@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"minchan@...nel.org" <minchan@...nel.org>,
	"mingo@...nel.com" <mingo@...nel.com>,
	"bmr@...hat.com" <bmr@...hat.com>,
	"prarit@...hat.com" <prarit@...hat.com>,
	"oleg@...hat.com" <oleg@...hat.com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"aneesh.kumar@...ux.vnet.ibm.com" <aneesh.kumar@...ux.vnet.ibm.com>,
	"akpm@...gle.com" <akpm@...gle.com>,
	"jgh@...hat.com" <jgh@...hat.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"pzijlstr@...hat.com" <pzijlstr@...hat.com>
Subject: RE: [PATCH v3 0/3] sched: Always check the integrity of the canary

From: Chuck Ebbert 
> David Laight <David.Laight@...LAB.COM> 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'.
> >
> > The canary will only work if the stack is densely written.
> > In practise the stack alignment rules create gaps, and the
> > most likely reason for overflow is a large on-stack buffer
> > that isn't actually written to.
> >
> > The only real way to detect kernel stack overflow is to arrange
> > for an unmapped page beyond the stack.
> > That costs KVA, but not much else.
> >
> 
> That doesn't work either, because the threadinfo sits between the end of the
> stack and the beginning of the next page, making it possible to corrupt critical
> data without running off the page.

Then flip the order of the allocations so that the threadinfo is at the other end.
I'm not sure how many per-lwp structures the linux kernel has, but
I know that on netbsd the main thing the kernel stack hits is the fpu
save area - the end of that is the avx area which won't be needed when
the stack usage is large.
Everything else could be moved from the stack pages to the lwp struct itself.

	David



--
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/