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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ