linux-kernel - Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

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:	Thu, 1 May 2014 16:39:29 -0500
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Seth Jennings <sjenning@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, Jiri Slaby <jslaby@...e.cz>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

On Thu, May 01, 2014 at 04:27:46PM -0500, Josh Poimboeuf wrote:
> On Thu, May 01, 2014 at 11:06:01PM +0200, Andi Kleen wrote:
> > > When bar returns, would it skip foo and go straight back to foo's
> > > caller?  If so, then it should be safe to patch foo after it jumps to
> > > bar.
> > 
> > foo is no problem, you see it in the backtrace.
> > But you don't see bar.
> 
> Sorry, I missed your point the first time.  Good question.
> 
> stop_machine schedules a high priority thread on each CPU, which means
> every other task will be waiting in a schedule() call (assuming a
> non-preemptible kernel).  In my local kernel, a quick grep of the
> disassembly doesn't show any jumps to schedule:
> 
>   $ egrep 'j.*<.*>' vmlinux.asm |grep -v '\+' |grep schedule
>   ffffffff816b89b5:	e9 e2 fe ff ff       	jmpq   ffffffff816b889c <retint_with_reschedule>
>   ffffffff816b8cec:	75 1e                	jne    ffffffff816b8d0c <paranoid_schedule>
> 
> But yes, that would be a problem if any tail call jumps to schedule()
> ever showed up.  We may need to detect that case in our patch generation
> tooling and fail to create the patch module binary if the patch affects
> a function which does this.

Thinking more about this... Even if it jumps to schedule(), I think
there's no problem, since the function is basically done, and we already
know not to patch schedule().

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