| 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
| ||
|
Message-ID: <alpine.LNX.2.00.1501192046130.10817@pobox.suse.cz> Date: Mon, 19 Jan 2015 20:48:42 +0100 (CET) From: Jiri Kosina <jkosina@...e.cz> To: Josh Poimboeuf <jpoimboe@...hat.com> 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 Mon, 19 Jan 2015, Josh Poimboeuf wrote: > > 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). Yup, I think that makes the most sense (especially in this "first step"). Relaxing the revert rules to cover only patches which are really dependent on each other (and we'd have to be careful about defining the meaning this, especially with repsect to various consistency models coming in the future) is something tha can always be done later on top. Thanks, -- Jiri Kosina SUSE Labs -- 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