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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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?


>> 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 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?

 -George

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