Re: [Xen-devel] [PATCH for-4.9] livepatch: Declare live patching as a supported feature

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 27/06/17 11:47, Andrew Cooper wrote:
> On 27/06/17 09:37, George Dunlap wrote:
>> On 26/06/17 18:18, Andrew Cooper wrote:
>>> On 26/06/17 17:50, George Dunlap wrote:
>>>> On 26/06/17 17:39, Andrew Cooper wrote:
>>>>>> * Bugs which allow a guest to prevent the application of a livepatch:
>>>>>>     A guest should not be able to prevent the application of a live
>>>>>>     patch. If an unprivileged guest can prevent the application of a
>>>>>>     live patch, it shall be treated as a security issue.
>>>>> This one is harder to say.  We know that enough concurrent live
>>>>> migrations can, which extends to "lots of activity in the guest".  Its
>>>>> perhaps worth noting the potential workaround of `xl pause $DOM;
>>>>> xen-livepatch ...; xl unpause`.
>>>> And what if the guest can prevent itself from being paused?
>>> In which case, that is an XSA in its own right.
>>>
>>> The underlying implementation uses XEN_DOMCTL_{,un}pausedomain which
>>> call straight into domain_{un,}pause().  We have very big problems if
>>> the guest has any influence in this...
>>>
>>>> Or, what if the guest can trigger some other persistent state change
>>>> such that livepatching will fail even if the domain is paused (or
>>>> destroyed)?
>>> Such as?
>>>
>>> The guest being able to cause damaging mutative state change in Xen is
>>> clearly a security issue, irrespective of any livepatch involvement.
>>>
>>> However, livepatch content (hook function for example) which trips over
>>> state as found in the hypervisor at the point of application is a bad
>>> livepatch, not a vulnerability in livepatching.
>>>
>>>> I agree that as long as the patch can be applied after "xl pause", then
>>>> the domain cannot be said to be preventing the application of the
>>>> livepatch.  But if either 'xl pause' doesn't work, or if livepatching
>>>> fails due to a malicious domain's actions after 'xl pause' (or 'xl
>>>> destroy'), then it should be treated as a security issue.
>>> I broadly agree, but these bugs feel like they would be self-standing,
>>> perhaps with an impact to applying a livepatch, rather than XSAs in
>>> livepatching itself.
>> So let me get this right.
>>
>> You think that all possible cases in which a guest can persistently
>> prevent a livepatch from being applied would already be a security issue
>> for other reasons.
> 
> Yes.  The only possible ways a guest (potentially) has of preventing
> livepatching from functioning (in the case that it is paused) is by
> mechanisms such as causing memory corruption, mis-refcounting or by
> having already achieved code injection.
> 
>> Therefore, you think we should include a paragraph in our security
>> support statement specifically stating that we do not provide security
>> support if the guest can prevent a livepatch.
>>
>> Is that correct?
> 
> Incorrect.  I don't think it is worth mentioning at all.
> 
> By calling it out, you are adding confusion to the area, as it is
> redundant with the rest of our policy.

So we shouldn't tell people we'll issue an XSA, because they should
already be able to infer from other things in our policy that an XSA
will be issued?  And if we clearly state that we'll issue an XSA in
those circumstances, they'll be confused?

 -George

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