xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Lars Kurth <lars.kurth@citrix.com>
To: Julien Grall <julien.grall@arm.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <liuw@liuw.name>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	George Dunlap <George.Dunlap@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature
Date: Tue, 27 Jun 2017 08:09:02 +0000	[thread overview]
Message-ID: <D577CAF9.389B2%lars.kurth@citrix.com> (raw)
In-Reply-To: <6eb72057-ec8e-b248-f659-f4291e33b981@arm.com>

Hi all,

there was also a discussion on IRC, which Ian said we should formally
summarise in e-mail, just so there is no doubt. So here is my go at it. As
far as I can tell - besides the technical discussion in this thread, there
are several issues which need to be clarified:

* For Xen 4.9 we can declare live patching supported, without spinning
another RC to update the in-tree documentation: in other words, we would
apply the documentation/policy changes + to the 4.9 tree sometimes after
this discussion has been concluded. In effect this means that
docs/features/livepatching.pandoc (or similar) and associated changes to
KCONFIG options would not show up until Xen 4.9.1 is spun, but the
security team would treat live patching as supported for 4.9. In other
words for now, we can update the table in the wiki
(https://wiki.xenproject.org/wiki/Xen_Project_Release_Features) and live
with in-tree artefacts being out-of-sync with the support status for a few
months. We need to fix this anyway in-tree and there is a concrete
proposal which should be discussed at the summit.

* There was a proposal to declare live patching supported for older
releases (aka "back port" docs/features/livepatching.pandoc), but Royger
pointed out that the toolstack in question needs to support buildid. If
so, we should include back-porting requests and d

* Julien pointed out that maybe we shouldn't declare live patching as
supported for ARM32/64. I don't see an issue to declare it supported for
x86/amd64 only for now. But it is obviously up to committers to make that
call.

I think that covers the ghist of the IRC discussion

Regards
Lars

On 27/06/2017, 08:24, "Julien Grall" <julien.grall@arm.com> wrote:

>
>
>On 06/26/2017 10:07 PM, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jun 26, 2017 at 07:29:22PM +0100, Julien Grall wrote:
>>> Hi,
>>>
>>> On 06/26/2017 04:36 PM, Ross Lagerwall wrote:
>>>> Xen Live Patching has been available as tech preview feature since Xen
>>>> 4.7 and has now had a couple of releases to stabilize. Xen Live
>>>>patching
>>>> has been used by multiple vendors to fix several real-world security
>>>> issues without any severe bugs encountered. Additionally, there are
>>>>now
>>>> tests in OSSTest that test live patching to ensure that no regressions
>>>> are introduced.
>>>>
>>>> Based on the amount of testing and usage it has had, we are ready to
>>>> declare live patching as a 'Supported' feature.
>>>
>>> There are only test for x86 and amd64. We likely want to have those
>>>test
>> 
>> The test-cases are also for ARM32.
>> 
>>> enabled for all architectures by default.
>> 
>> And the OSSTest can test all of those.
>
>Can we enable them by default? I know that we limited the number of
>tests for ARM64 due to limited bandwidth. But I don't think we have
>anything preventing it on ARM32.
>
>>>
>>> Also, I am not aware of anyone using in production livepatch on ARM64
>>>and
>>> ARM32. So did anyone give a good kick at the ARM implementaton?
>> 
>> I am not aware of anybody using it on production on ARM32 or ARM64.
>> 
>> The test-cases are there, the code is there, but yes nobody has kicked
>> the tires on ARM32/ARM64 extensively with it. I would be excited to
>> see vendors that use it and their reports but I am not aware of any.
>> 
>>>
>>> If not, then we should  do it before even considering as a supported
>>>feature
>>> for ARM.
>> 
>> OK. Perhaps then only for x86 until ARM operational users pipe up?
>
>That would be my preference. My main concern is to handle security issue
>afterwards because we didn't give any kick at the code.
>
>Cheers,
>
>-- 
>Julien Grall

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

  reply	other threads:[~2017-06-27  8:09 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 15:36 [PATCH for-4.9] livepatch: Declare live patching as a supported feature Ross Lagerwall
2017-06-26 16:39 ` Andrew Cooper
2017-06-26 16:50   ` George Dunlap
2017-06-26 16:53     ` Ian Jackson
2017-06-26 17:18     ` Andrew Cooper
2017-06-27  8:37       ` George Dunlap
2017-06-27 10:47         ` Andrew Cooper
2017-06-27 10:49           ` George Dunlap
2017-06-26 16:50   ` Ross Lagerwall
2017-06-26 17:04     ` Andrew Cooper
2017-06-27  6:04   ` Jan Beulich
2017-06-27  7:19     ` Julien Grall
2017-06-27 11:23       ` Jan Beulich
2017-06-27 11:34     ` George Dunlap
2017-06-26 17:00 ` George Dunlap
2017-06-26 17:30   ` Andrew Cooper
2017-06-27  9:17     ` George Dunlap
2017-06-28 16:18       ` Ross Lagerwall
2017-06-28 16:41         ` Konrad Rzeszutek Wilk
2017-06-30 13:42         ` George Dunlap
2017-07-03 14:53           ` Ross Lagerwall
2017-07-04  8:36             ` Roger Pau Monné
2017-08-03 17:20             ` George Dunlap
2017-08-03 17:21               ` George Dunlap
2017-08-06  0:07                 ` Is:livepatch-build-tools.git declare it supported? Was:Re: " Konrad Rzeszutek Wilk
2017-08-07 10:26                   ` George Dunlap
2017-08-07 15:59                     ` Jan Beulich
2017-08-08 11:16                       ` George Dunlap
2017-08-09  7:36                         ` Jan Beulich
2017-08-21 10:59                           ` George Dunlap
2017-08-21 12:07                             ` Jan Beulich
2017-08-21 15:28                               ` George Dunlap
2017-08-22  6:37                                 ` Jan Beulich
2017-08-22 10:58                                   ` George Dunlap
2017-08-22 11:16                                     ` Roger Pau Monné
2017-08-29 14:44                                 ` Konrad Rzeszutek Wilk
2017-08-29 14:46                                   ` Andrew Cooper
2017-08-29 14:48                                   ` George Dunlap
2017-06-26 18:29 ` Julien Grall
2017-06-26 21:07   ` Konrad Rzeszutek Wilk
2017-06-27  7:24     ` Julien Grall
2017-06-27  8:09       ` Lars Kurth [this message]
2017-06-27 10:49         ` Ian Jackson
2017-06-27 10:59           ` Lars Kurth
2017-06-27 10:46       ` Ian Jackson

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=D577CAF9.389B2%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=julien.grall@arm.com \
    --cc=konrad.wilk@oracle.com \
    --cc=liuw@liuw.name \
    --cc=ross.lagerwall@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xen.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).