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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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