linux-kernel - Re: [PATCHv4 0/3] Kernel Live 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:	Tue, 25 Nov 2014 16:10:46 -0600
From:	Seth Jennings <sjenning@...hat.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Josh Poimboeuf <jpoimboe@...hat.com>,
	Vojtech Pavlik <vojtech@...e.cz>,
	Steven Rostedt <rostedt@...dmis.org>,
	Petr Mladek <pmladek@...e.cz>, Miroslav Benes <mbenes@...e.cz>,
	Christoph Hellwig <hch@...radead.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	live-patching@...r.kernel.org, x86@...nel.org, kpatch@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 0/3] Kernel Live Patching

On Tue, Nov 25, 2014 at 08:26:22PM +0100, Jiri Kosina wrote:
> On Tue, 25 Nov 2014, Seth Jennings wrote:
> 
> > Masami's IPMODIFY patch is heading for -next via your tree.  Once it arrives,
> > I'll rebase and make the change to set IPMODIFY.  Do not pull this for -next
> > yet.  This version (v4) is for review and gathering acks.
> 
> Thanks for sending out v4 and incorporating the feedback, I really 
> appreciate your responsiveness!
> 
> Anyway, I don't think targetting 3.19 is realistic, given we're currently 
> already past 3.18-rc6 ... even if we rush it into -next in the coming 
> days, it will get close to zero exposure in there before the merge window 
> opens.

Agreed. Sorry if I gave the impression that I was trying to rush this
into 3.19.  I just wanted to make sure that Steve was aware of the
dependency.

> 
> I'd like to do quite some more testing and still finish some pending 
> portions of code reviews on our side (especially to make sure that this 
> can be easily extended to support any consistency model in the future).

Without knowing how that consistency code will look, how can we "make
sure" that this code can be easily extended to support it?  I don't
think we should hold up this first step based on what we think the
consistency code might look like. The code is not that complex right
now. That was the point :)  We can always adapt things.

> 
> Once we start collecting Reviewed-by's / Acked-by's on this patchset, I 
> can establish a tree on git.kernel.org that we can use to collect any 
> followup patches during 3.20 development cycle and send a pull request to 
> Linus during 3.20 merge window .. if everybody agrees with this course of 
> action, obviously.

I was hoping this first step would go into next via Steve's tree and go
upstream for 3.20 (hopefully) from there.  I would be against anything
that tries to expand the feature set before this base functionality gets
upstream.  However, if we want to have a tree to gather fixes before
3.20, which I think is what you are suggesting, that works for me.  We
would need to agree explicitly that, in this tree, patches would need
both a RH and SUSE ack to be accepted.

Thanks,
Seth

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