linux-kernel - Re: perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind

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]

Date:   Tue, 29 Nov 2016 12:32:59 -0800
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Petr Mladek <pmladek@...e.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Vince Weaver <vincent.weaver@...ne.edu>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        "dvyukov@...gle.com" <dvyukov@...gle.com>
Subject: Re: perf: fuzzer BUG: KASAN: stack-out-of-bounds in __unwind_start

On Tue, Nov 29, 2016 at 12:07:11PM -0800, Paul E. McKenney wrote:
> On Tue, Nov 29, 2016 at 08:52:04PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 29, 2016 at 11:39:35AM -0800, Paul E. McKenney wrote:
> > > On Tue, Nov 29, 2016 at 06:10:38PM +0100, Peter Zijlstra wrote:
> > 
> > > > It mostly works, most of the time, and that seems to be what Linus
> > > > wants, since its really the best we can have given the constraints. But
> > > > for debugging, when you have a UART, it totally blows.
> > > 
> > > UART???  They still make those things???  ;-)
> > 
> > Yes, most computer like devices actually have them, trouble is, most
> > consumer devices don't have the pins exposed. Luckily most server class
> > hardware still does.
> > 
> > And they're absolutely _awesome_ for debugging; getting data out is a
> > matter of trivial MMIO poll loops. Rock solid stuff.
> 
> They very clearly need to bring the baud rate into the current millenium,
> many tens of Mbaud at the -very- least.

On a more practical note...

Currently, cond_resched_rcu_qs() is not permitted to be invoked until
after the scheduler has started.  However, it appears that there is some
kernel code that can loop for quite some time at runtime, but which also
executes during early boot.  So it would be good to make it so that
cond_resched_rcu_qs() could be called at boot.

One approach would be to check rcu_scheduler_active, but this isn't
defined in normal Tiny RCU builds.  I can expand Tiny RCU, or I can
kludge the non-CONFIG_DEBUG_LOCK_ALLOC value of rcu_scheduler_active
to false (with this latter being the current state).  But it occurred
to me that I could also condition on !is_idle_task(), given that idle
tasks shouldn't ever be invoking the scheduler anyway.

So is the following a sensible approach, or should I look elsewhere?

	#define cond_resched_rcu_qs() \
	do { \
		if (!is_idle_task(current) && !cond_resched()) \
			rcu_note_voluntary_context_switch(current); \
	} while (0)

							Thanx, Paul