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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 08/08/16 15:01, Jan Beulich wrote:
>>>> On 08.08.16 at 15:42, <george.dunlap@xxxxxxxxxx> wrote:
>> On 05/08/16 16:35, Jan Beulich wrote:
>>>>>> On 04.08.16 at 17:49, <konrad.wilk@xxxxxxxxxx> 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.)

 -George

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