xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Lars Kurth <lars.kurth@citrix.com>
To: Ian Jackson <Ian.Jackson@citrix.com>,
	George Dunlap <George.Dunlap@citrix.com>
Cc: James Bulpin <James.Bulpin@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <liuw@liuw.name>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Andrew Halley <andrew.halley@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Livepatching and Xen Security
Date: Thu, 18 May 2017 17:24:08 +0000	[thread overview]
Message-ID: <D543929A.3754E%lars.kurth@citrix.com> (raw)
In-Reply-To: <22813.53640.281771.390120@mariner.uk.xensource.com>



On 18/05/2017 17:53, "Ian Jackson" <ian.jackson@eu.citrix.com> wrote:

>George Dunlap writes ("Livepatching and Xen Security"):
>> # Executive summary
>
>I am completely in agreement with your analysis and your conclusions.

Me too. I am not sure though whether we need a vote or lazy consensus.

For Credit2 (see 
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg00171.html)
 we used a code patch removing Experimental from KCONFIG, which implicitly
led to active confirmation by project leadership members via Acked-by
tags. In other words, we executed the equivalent of a vote.

From a process perspective
https://xenproject.org/governance.html#lazyconsensus should be sufficient
because we are applying a process, not changing one. In addition lazy
consensus decisions can only be overturned if the project leadership
agrees collectively to do so, because the decision is too important for
lazy consensus. As every leadership member is on the list, there would be
ample opportunity to raise objections.

My gut feeling though is that Leadership Team members and Security Team
members should probably actively agree/disagree to proposals related to
whether a feature is supported and thus security supported to avoid any
future issues. George already expressed an implicit +1 (by making the
proposal) and Ian an explicit +1.

Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-05-18 17:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 16:40 Livepatching and Xen Security George Dunlap
2017-05-18 16:53 ` Ian Jackson
2017-05-18 17:24   ` Lars Kurth [this message]
2017-05-18 19:07 ` Andrew Cooper
2017-05-19 14:32   ` Wei Liu
2017-05-19 14:38     ` Andrew Cooper
2017-05-19 14:44       ` Ian Jackson
2017-05-22 16:05   ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D543929A.3754E%lars.kurth@citrix.com \
    --to=lars.kurth@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=James.Bulpin@citrix.com \
    --cc=andrew.halley@citrix.com \
    --cc=liuw@liuw.name \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).