Re: [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
	George Dunlap <george.dunlap@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case
Date: Mon, 8 Aug 2016 17:07:06 +0100	[thread overview]
Message-ID: <cd77706b-d949-0a2a-f680-3fee5f3ee794@citrix.com> (raw)
In-Reply-To: <57A8BE490200007800103E3A@prv-mh.provo.novell.com>

On 08/08/16 16:15, Jan Beulich wrote:
>>>> On 08.08.16 at 16:10, <george.dunlap@citrix.com> wrote:
>> On 08/08/16 15:01, Jan Beulich wrote:
>>>>>> On 08.08.16 at 15:42, <george.dunlap@citrix.com> wrote:
>>>> On 05/08/16 16:35, Jan Beulich wrote:
>>>>>>>> On 04.08.16 at 17:49, <konrad.wilk@oracle.com> wrote:
>>>>>> In general, the hooks provide flexibility when having to deal with
>>>>>> unforeseen cases, but their application should be rarely required (<
>>>>>> 10%)."
>>>>> But the greater flexibility of course comes with increased chances
>>>>> of screwing things up. I'm therefore still not entirely convinced that
>>>>> such XSAs wouldn't then better not be live patched.
>>>> But this functionality is optional, right?  So although I tend to agree
>>>> with you, we can let the person / organization preparing the patch take
>>>> that risk if they want to?
>>> That's a valid point, albeit I think patch producer and patch consumer
>>> might have different views, and the patch consumer may not know
>>> (or even know to care) whether (s)he's got handed a patch with or
>>> without use of hooks.
>> But the patch consumer probably doesn't know for sure if the patch was
>> even tested, or if it even fixes the things it was meant to fix.  The
>> producer / consumer relationship will always have an aspect of trust and
>> some mechanism for feedback.
>>
>> I suppose there is a sort of "prisoner's dilemma" aspect to this though:
>> suppose provider A thinks that hooks are too dangerous, and doesn't
>> provide a hotfix for a certain XSA as a result, but provider B, seeing
>> an opportunity, ignores the risks and provides a hotpatch for their
>> product instead.  If the consumers can't evaluate the danger, provider A
>> will be pressured into providing a patch even though they don't think
>> it's a good idea.
>>
>> So if this really is too dangerous to be used regularly, there is an
>> argument to be made not to accept the functionality.  (I'm not making an
>> argument either way at the moment.)
> Since both Konrad and Ross appear to be desiring hooks, and since
> they're the maintainers, just me having a weak opinion in the other
> direction to me means we ought to allow these. If other general
> maintainers were considering this too dangerous too, the picture
> might change.

I find it funny that we are arguing over the safety of hooks like these
as part of a system expressly designed to overwrite arbitrary bits of
hypervisor code and data.

This is already a "you had better know exactly what you are doing" kind
of area.

There are a number of XSA cases where one-time data modification needs
to happen if live patching were to occur.

+1 introduce the hooks.  The worst that happens is that someone has yet
way to make things go wrong, but the best that happens is that more
issues can be correctly livepatched.

~Andrew

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