[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 08.08.16 at 16:10, <george.dunlap@xxxxxxxxxx> wrote:
> 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.)

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.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.