[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |