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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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