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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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.

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?

 -George

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