Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754913AbbBTUI4 (ORCPT <rfc822;w@1wt.eu>);
	Fri, 20 Feb 2015 15:08:56 -0500
Received: from mail-we0-f173.google.com ([74.125.82.173]:46070 "EHLO
	mail-we0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752548AbbBTUIy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 20 Feb 2015 15:08:54 -0500
Date: Fri, 20 Feb 2015 21:08:49 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Jiri Kosina <jkosina@suse.cz>, Vojtech Pavlik <vojtech@suse.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Ingo Molnar <mingo@redhat.com>, Seth Jennings <sjenning@redhat.com>,
        linux-kernel@vger.kernel.org,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 1/3] sched: add sched_task_call()
Message-ID: <20150220200849.GC3603@gmail.com>
References: <20150219163359.GA25438@suse.cz>
 <20150219170353.GB15980@treble.redhat.com>
 <20150219171929.GA13178@suse.cz>
 <20150219173255.GC15980@treble.redhat.com>
 <20150219204036.GA16882@suse.com>
 <20150219214229.GD15980@treble.redhat.com>
 <alpine.LNX.2.00.1502200830430.28769@pobox.suse.cz>
 <alpine.LNX.2.00.1502200939230.28769@pobox.suse.cz>
 <20150220095003.GA23506@gmail.com>
 <20150220161219.GF15980@treble.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150220161219.GF15980@treble.redhat.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3456
Lines: 98


* Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> On Fri, Feb 20, 2015 at 10:50:03AM +0100, Ingo Molnar wrote:
> > 
> > * Jiri Kosina <jkosina@suse.cz> wrote:
> > 
> > > Alright, so to sum it up:
> > > 
> > > - current stack dumping (even looking at /proc/<pid>/stack) is not 
> > >   guaranteed to yield "correct" results in case the task is running at the 
> > >   time the stack is being examined
> > 
> > Don't even _think_ about trying to base something as 
> > dangerous as live patching the kernel image on the concept 
> > of:
> > 
> >   'We can make all stack backtraces reliably correct all 
> >    the time, with no false positives, with no false
> >    negatives, 100% of the time, and quickly discover and
> >    fix bugs in that'.
> > 
> > It's not going to happen:
> > 
> >  - The correctness of stacktraces partially depends on
> >    tooling and we don't control those.
> 
> What tooling are you referring to?
> 
> Sure, we rely on the compiler to produce the correct 
> assembly for putting frame pointers on the stack. [...]

We also rely on all assembly code to have valid frames all 
the time - and this is far from a given, we've had many 
bugs in that area.

> [...]  But that's pretty straightforward. The kernel 
> already relies on the compiler to do plenty of things 
> which are much more complex than that.

So this claim scares me because it's such nonsense:

We rely on the compiler to create _functional code_ for us.  
If the compiler messes up then functionality, actual code 
breaks.

'Valid stack frame' is not functional code, it's in essence 
debug info. If a backtrace is wrong in some rare, racy case 
then that won't break the kernel, it just gives slightly 
misleading debug info in most cases.

Now you want to turn 'debug info' to have functional 
relevance, for something as intrusive as patching the 
kernel code.

You really need to accept this distinction!

> >  - More importantly, there's no strong force that ensures
> >    we can rely on stack backtraces: correcting bad 
> >    stack traces depends on people hitting those 
> >    functions and situations that generate them, seeing 
> >    a bad stack trace, noticing that it's weird and 
> >    correcting whatever code or tooling quirk causes the 
> >    stack entry to be incorrect.
> >
> > Essentially unlike other kernel code which breaks stuff 
> > if it's incorrect, there's no _functional_ dependence 
> > on stack traces, so live patching would be the first 
> > (and pretty much only) thing that breaks on bad stack 
> > traces ...
> 
> First, there are several things we do to avoid anomalies:
> 
> - we don't patch asm functions

the problem with asm functions isn't that we might want to 
patch them (although sometimes we might want to: especially 
the more interesting security fixes tend to be in assembly 
code), it's that asm functions can (easily) mess up debug 
info, without that being apparent in any functional way.

> - we only walk the stack of sleeping tasks

sleeping tasks are affected by debug info bugs too.

> Second, currently the stack unwinding code is rather 
> crude and doesn't do much in the way of error handling.

That's a big red flag in my book ...

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/