[Xen-devel] [PATCH] viridian: make viridian_time_domain_freeze() safe to call...

Paul Durrant posted 1 patch 4 years, 7 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/xen tags/patchew/20190821082258.36549-1-paul.durrant@citrix.com
xen/arch/x86/hvm/viridian/time.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
[Xen-devel] [PATCH] viridian: make viridian_time_domain_freeze() safe to call...
Posted by Paul Durrant 4 years, 7 months ago
...on a partially destroyed domain.

viridian_time_domain_freeze() and viridian_time_vcpu_freeze() rely
(respectively) on the dynamically allocated per-domain and per-vcpu viridian
areas [1], which are freed during domain_relinquish_resources().
Because arch_domain_pause() can call viridian_domain_time_freeze() this
can lead to host crashes if e.g. a XEN_DOMCTL_pausedomain is issued after
domain_relinquish_resources() has run.

To prevent such crashes, this patch adds a check of is_dying into
viridian_time_domain_freeze(), and viridian_time_domain_thaw() which is
similarly vulnerable to indirection into freed memory.

NOTE: The patch also makes viridian_time_vcpu_freeze/thaw() static, since
      they have no callers outside of the same source module.

[1] See commit e7a9b5e72f26 "viridian: separately allocate domain and vcpu
    structures".

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wl@xen.org>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>
---
 xen/arch/x86/hvm/viridian/time.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian/time.c b/xen/arch/x86/hvm/viridian/time.c
index ac087383c8..e80330a6ae 100644
--- a/xen/arch/x86/hvm/viridian/time.c
+++ b/xen/arch/x86/hvm/viridian/time.c
@@ -296,7 +296,7 @@ void viridian_time_poll_timers(struct vcpu *v)
         poll_stimer(v, i);
 }
 
-void viridian_time_vcpu_freeze(struct vcpu *v)
+static void viridian_time_vcpu_freeze(struct vcpu *v)
 {
     struct viridian_vcpu *vv = v->arch.hvm.viridian;
     unsigned int i;
@@ -314,7 +314,7 @@ void viridian_time_vcpu_freeze(struct vcpu *v)
     }
 }
 
-void viridian_time_vcpu_thaw(struct vcpu *v)
+static void viridian_time_vcpu_thaw(struct vcpu *v)
 {
     struct viridian_vcpu *vv = v->arch.hvm.viridian;
     unsigned int i;
@@ -336,7 +336,7 @@ void viridian_time_domain_freeze(const struct domain *d)
 {
     struct vcpu *v;
 
-    if ( !is_viridian_domain(d) )
+    if ( d->is_dying || !is_viridian_domain(d) )
         return;
 
     for_each_vcpu ( d, v )
@@ -349,7 +349,7 @@ void viridian_time_domain_thaw(const struct domain *d)
 {
     struct vcpu *v;
 
-    if ( !is_viridian_domain(d) )
+    if ( d->is_dying || !is_viridian_domain(d) )
         return;
 
     time_ref_count_thaw(d);
-- 
2.20.1.2.gb21ebb671


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] viridian: make viridian_time_domain_freeze() safe to call...
Posted by Roger Pau Monné 4 years, 7 months ago
On Wed, Aug 21, 2019 at 09:22:58AM +0100, Paul Durrant wrote:
> ...on a partially destroyed domain.
> 
> viridian_time_domain_freeze() and viridian_time_vcpu_freeze() rely
> (respectively) on the dynamically allocated per-domain and per-vcpu viridian
> areas [1], which are freed during domain_relinquish_resources().
> Because arch_domain_pause() can call viridian_domain_time_freeze() this
> can lead to host crashes if e.g. a XEN_DOMCTL_pausedomain is issued after
> domain_relinquish_resources() has run.
> 
> To prevent such crashes, this patch adds a check of is_dying into
> viridian_time_domain_freeze(), and viridian_time_domain_thaw() which is
> similarly vulnerable to indirection into freed memory.
> 
> NOTE: The patch also makes viridian_time_vcpu_freeze/thaw() static, since
>       they have no callers outside of the same source module.
> 
> [1] See commit e7a9b5e72f26 "viridian: separately allocate domain and vcpu
>     structures".
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Note you could also drop the viridian_ prefix to the now static
functions.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] viridian: make viridian_time_domain_freeze() safe to call...
Posted by Paul Durrant 4 years, 7 months ago
> -----Original Message-----
> From: Roger Pau Monne <roger.pau@citrix.com>
> Sent: 21 August 2019 09:52
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: xen-devel@lists.xenproject.org; Jan Beulich <jbeulich@suse.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; Wei Liu <wl@xen.org>
> Subject: Re: [PATCH] viridian: make viridian_time_domain_freeze() safe to call...
> 
> On Wed, Aug 21, 2019 at 09:22:58AM +0100, Paul Durrant wrote:
> > ...on a partially destroyed domain.
> >
> > viridian_time_domain_freeze() and viridian_time_vcpu_freeze() rely
> > (respectively) on the dynamically allocated per-domain and per-vcpu viridian
> > areas [1], which are freed during domain_relinquish_resources().
> > Because arch_domain_pause() can call viridian_domain_time_freeze() this
> > can lead to host crashes if e.g. a XEN_DOMCTL_pausedomain is issued after
> > domain_relinquish_resources() has run.
> >
> > To prevent such crashes, this patch adds a check of is_dying into
> > viridian_time_domain_freeze(), and viridian_time_domain_thaw() which is
> > similarly vulnerable to indirection into freed memory.
> >
> > NOTE: The patch also makes viridian_time_vcpu_freeze/thaw() static, since
> >       they have no callers outside of the same source module.
> >
> > [1] See commit e7a9b5e72f26 "viridian: separately allocate domain and vcpu
> >     structures".
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Note you could also drop the viridian_ prefix to the now static
> functions.
> 

Yeah, they could be dropped. May be a friendly committer could do it? :-)

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] viridian: make viridian_time_domain_freeze() safe to call...
Posted by Andrew Cooper 4 years, 7 months ago
On 21/08/2019 10:13, Paul Durrant wrote:
>> -----Original Message-----
>> From: Roger Pau Monne <roger.pau@citrix.com>
>> Sent: 21 August 2019 09:52
>> To: Paul Durrant <Paul.Durrant@citrix.com>
>> Cc: xen-devel@lists.xenproject.org; Jan Beulich <jbeulich@suse.com>; Andrew Cooper
>> <Andrew.Cooper3@citrix.com>; Wei Liu <wl@xen.org>
>> Subject: Re: [PATCH] viridian: make viridian_time_domain_freeze() safe to call...
>>
>> On Wed, Aug 21, 2019 at 09:22:58AM +0100, Paul Durrant wrote:
>>> ...on a partially destroyed domain.
>>>
>>> viridian_time_domain_freeze() and viridian_time_vcpu_freeze() rely
>>> (respectively) on the dynamically allocated per-domain and per-vcpu viridian
>>> areas [1], which are freed during domain_relinquish_resources().
>>> Because arch_domain_pause() can call viridian_domain_time_freeze() this
>>> can lead to host crashes if e.g. a XEN_DOMCTL_pausedomain is issued after
>>> domain_relinquish_resources() has run.
>>>
>>> To prevent such crashes, this patch adds a check of is_dying into
>>> viridian_time_domain_freeze(), and viridian_time_domain_thaw() which is
>>> similarly vulnerable to indirection into freed memory.
>>>
>>> NOTE: The patch also makes viridian_time_vcpu_freeze/thaw() static, since
>>>       they have no callers outside of the same source module.
>>>
>>> [1] See commit e7a9b5e72f26 "viridian: separately allocate domain and vcpu
>>>     structures".
>>>
>>> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
>> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
>>
>> Note you could also drop the viridian_ prefix to the now static
>> functions.
>>
> Yeah, they could be dropped. May be a friendly committer could do it? :-)

Done.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel