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 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).

>>> We could even place more restrictions on the scope if we wanted to.  We
>>> could say that we only support the livepatch tools generating patches
>>> for XSAs.
>> 
>> For me, much depends on how tight such restrictions would be. I.e.
>> with the examples given above, how would we determine a canonical
>> livepatch-tools / hypervisor pair (or set of pairs)? After all tools
>> mis-behavior may be a result of some custom patch in someone's
>> derived tree.
> 
> Well, suppose that we issued an XSA with a patch, and suppose it was
> later discovered that the patch opened up a different security hole when
> applied on the upstream tree.  Would we issue another XSA and/or an
> update to the existing XSA?  I think obviously yes we would.

Yes (this has happened in the past already).

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

Jan

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