linux-kernel - Re: [PATCH] livepatch: support for repatching a function

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: <20150119145431.GC1737@treble.redhat.com>
Date:	Mon, 19 Jan 2015 08:54:31 -0600
From:	Josh Poimboeuf <jpoimboe@...hat.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Seth Jennings <sjenning@...hat.com>,
	Vojtech Pavlik <vojtech@...e.cz>,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] livepatch: support for repatching a function

On Fri, Jan 16, 2015 at 05:51:11PM +0100, Jiri Kosina wrote:
> One thing that makes me worried here is we basically apply patches in a 
> 'stackable' manner, but then this allows them to be removed (disabled) in 
> an arbitrary order. Is this really the semantics we want?
> 
> The scenario I am concerned about, in a nutshell:
> 
> foo_unpatched()
> 	foo_patch1()
> 		foo_patch2()
> 			foo_patch3()
> 		disable(foo_patch2)
> 		disable(foo_patch3)
> 	foo_patch1()
> 
> I.e. basically due to reverting of foo_patch2() while it wasn't in use, we 
> turn subsequent revert of foo_patch3() into foo_patch1() state, although 
> the function foo_patch3() was originally patching was foo_patch2().
> 
> If this is implemented really in a fully stackable manner (i.e. you 
> basically would be able to disable only the function that is currently 
> "active", i.e. on top of the stack), woudln't that provide more 
> predictable semantics?

Yes, I agree.  Thanks for the comment.

Would you want to enforce stacking even if there are no dependencies
between the patches?  I think that would be easiest (and cleanest).

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