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

From: Andrew Cooper <andrew.cooper3@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	xen-devel@lists.xen.org
Cc: Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <liuw@liuw.name>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH for-4.9] livepatch: Declare live patching as a supported feature
Date: Tue, 27 Jun 2017 11:47:16 +0100	[thread overview]
Message-ID: <a7873138-56d5-2d37-1713-182e2193d7d4@citrix.com> (raw)
In-Reply-To: <9b1f7edb-2efc-3e10-d9d7-009200ca4989@citrix.com>

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@lists.xen.org
https://lists.xen.org/xen-devel