Re: [Xen-devel] Is:livepatch-build-tools.git declare it supported? Was:Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.08.17 at 12:59, <george.dunlap@xxxxxxxxxx> wrote:
> On Wed, Aug 9, 2017 at 8:36 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 08.08.17 at 13:16, <george.dunlap@xxxxxxxxxx> wrote:
>>> On 08/07/2017 04:59 PM, Jan Beulich wrote:
>>>>>>> George Dunlap <george.dunlap@xxxxxxxxxx> 08/07/17 12:27 PM >>>
>>>>> So it seems that people are still not quite clear about what I'm 
>>>>> proposing.
>>>>
>>>> And indeed your examples helped me understand better what you mean
>>>> (or at least I hope they did).
>>>>
>>>>> Suppose someone builds a livepatch with the correct compiler, with a
>>>>> correct patch (that would fix the bug if rebooted into a new
>>>>> hypervisor), with correct fix-up code.  Suppose that the bug passes all
>>>>> reasonable testing; but that, *due to a bug in the tools*, the patch
>>>>> also gives PV guests access to hypervisor memory.  Is this a security
>>>>> issue?  Yes -- the human told it to do safe thing X ("build a livepatch
>>>>> based on correct inputs to fix this bug") and it did unsafe thing Y
>>>>> ("build a livepatch that opens up a new security hole").
>>>>
>>>> There's one more factor here: The livepatch tools may behave properly
>>>> with one version of the compiler, and improperly with another.
>>>
>>> I don't really understand the reasoning here.  Is this your argument:
>>> "One can imagine a security-critical livepatch bug that only affects
>>> say, gcc 6.x and not gcc 5.x or 7.x.  Therefore, we should never issue
>>> XSAs for any security-critical livepatch bugs."
>>>
>>> If we found that livepatching tools make an incorrect patch only when
>>> using gcc 5.x, and we have reason to believe that some people may be
>>> using gcc 5.x, then I think we should issue an XSA and say that it only
>>> affects people compiling xen with gcc 5.x.
>>>
>>> It probably would make sense to specify some range of compiler versions
>>> for which we will issue XSAs for the livepatch tools.  A good baseline
>>> would be what versions of gcc Xen uses, and then we can restrict it
>>> further if we need to (for instance, if some versions of gcc are missing
>>> requisite features, or if they are just known to be buggy).
>>>
>>> And remember, this is not "We have tested all compiler versions and
>>> promise you there are no bugs."  It's, "If someone finds a bug for this
>>> set of compilers, we will tell you about it so you can do something
>>> about it."
>>
>> I can see and understand all of what you say; my argument,
>> however was more towards the matrix of what needs supporting
>> possibly becoming unreasonably large (no matter whether we
>> specify a range of compilers, as once again distros tend to not
>> ship plain unpatched upstream compiler versions).
> 
> What do you mean, "The matrix of what needs supporting [may possibly
> become] increasingly large"?   What is the problem with having a large
> (implicit) "supported" matrix?  How is supporting a "large matrix" for
> livepatch tools different than the current "large matrix" we support
> for just building Xen at all?

The matrix of Xen only has just a single dimension. Since livepatch
tools and Xen are independent, any pair of them would need
building/testing in order to be sure things work in all supported
combinations.

>>> Suppose instead we issued an XSA with a patch, and that it was later
>>> discovered that the patch opened up a different security hole when
>>> applied on top of XenServer's patchqueue, but not on the baseline
>>> XenProject.  Would we issue another XSA and/or an update to an existing XSA?
>>>
>>> The obvious *default* answer to that is "No; it's not practical for us
>>> to deal with software that is not inside the XenProject's control."  One
>>> could imagine circumstances in which we issue statements or an XSA
>>> anyway, but that would the exception and not the rule.
>>>
>>> I think the same kind of thing would apply to the livepatch tools: *by
>>> default*, we only issue XSAs for the livepatch tools if they create
>>> security issues when generating blobs based on security patches issued
>>> by the XenProject, and on top of XenProject-released software.  As
>>> always, if there's some unforeseen circumstance then someone could argue
>>> for an exception.
>>
>> Not sure here - if analysis showed that the same issue could happen
>> elsewhere, and others were just lucky so far, I think we'd have to
>> alter the default (and I'm hesitant to call this an exception). Plus
>> analysis may, the more different components are involved
>> (specifically the compiler, which perhaps none of us has deep enough
>> knowledge about), become more and more difficult.
>>
>> Bottom line - while technically I agree it would be good for the tools
>> to be security supported, from a practical perspective I see too
>> much complexity for this to be reasonably manageable.
> 
> But I still don't understand why you think so.  Every single objection
> or question about what would or would  not be supported that has been
> raised so far has analogs in what we already support.  It is no more
> complex to support livepatch-tools than to support HVM USB
> passthrough, or credit2.

I don't think we currently have any scenario where it might be
required (rather than just being optional) to do in-depth analysis
of compiler behavior. If we ran into a compiler induced vulnerability
in Xen, I'm sure we'd forward this to the compiler folks. If, however,
there's an issue with a livepatch, and it's unclear whether the root
cause are the tool chain or the livepatch tools, both would need to
be analyzed to find the culprit. I don't think forwarding this to the
compiler folks would be appropriate until we're sure it's in their code
rather than ours.

> I have elsewhere described a hypothetical scenario where I think we
> should issue an XSA for livepatch-tools.  Are you really seriously
> suggesting that in that scenario we should simply publish the
> vulnerability onto xen-devel with no predisclosure?

Well, at least I'm not 100% convinced issuing an XSA in this case
would be appropriate.

Anyway - since it feels like we're moving in circles (which in part
may be because I can't express well enough the reasons for my
hesitation to go to the full XSA extent with the livepatch tools)
I'd like to just conclude my part here with saying that I'm not
going to stand in the way whichever decision is taken. I've
voiced my reservations, and that will have to do. I'd therefore
prefer to leave the discussion to those more familiar with those
tools (and their possible limitations and issues).

Jan

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