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]

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/