[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/vcpu: ensure no write when runstate handler is NULL



On Fri, Oct 23, 2026 at 04:46:42PM +0100, Andrew Cooper wrote:
> On 23/10/2026 2:33 pm, Roger Pau Monne wrote:
> > Both the normal and the compat versions of
> > VCPUOP_register_runstate_memory_area allow registering a NULL handler as a
> > way to signal deregistration of the previous area, and
> > update_runstate_area() will skip the update when the handler is NULL.
> >
> > However when handling the VCPUOP_register_runstate_memory_area hypercall
> > itself there's an unconditional attempt to update the newly registered
> > runstate area, without taking into account whether it points to NULL.  Skip
> > such update if the user-provided handle is NULL.
> >
> > Signed-off-by: Roger Pau Monné <roger@xxxxxxxxxxxxxx>
> > ---
> >  xen/arch/x86/x86_64/domain.c | 4 ++++
> >  xen/common/domain.c          | 4 ++++
> >  2 files changed, 8 insertions(+)
> >
> > diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c
> > index a02d4f569ee5..e4d49cbbfeb6 100644
> > --- a/xen/arch/x86/x86_64/domain.c
> > +++ b/xen/arch/x86/x86_64/domain.c
> > @@ -58,6 +58,10 @@ compat_vcpu_op(int cmd, unsigned int vcpuid, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >          rc = 0;
> >          guest_from_compat_handle(v->runstate_guest.compat, area.addr.h);
> >  
> > +        /* NULL handle is deregistering the address. */
> > +        if ( compat_handle_is_null(area.addr.h) )
> > +            break;
> > +
> >          if ( v == current )
> >          {
> >              XLAT_vcpu_runstate_info(&info, &v->runstate);
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 6b52713518da..30a17b8b7edb 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -2330,6 +2330,10 @@ long common_vcpu_op(int cmd, struct vcpu *v, 
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >          rc = 0;
> >          runstate_guest(v) = area.addr.h;
> >  
> > +        /* NULL handle is deregistering the address. */
> > +        if ( guest_handle_is_null(area.addr.h) )
> > +            break;
> > +
> >          if ( v == current )
> >          {
> >              __copy_to_guest(runstate_guest(v), &v->runstate, 1);
> 
> This is all horrible.
> 
> I think you ought to add /* Update the newly-registered runstate area,
> best-effort */ to both of these hunks.
> 
> I also think it would be easier to follow with the commit message
> structured in a different order.  I suggest:
> 
> --8<--
> The VCPUOP_register_runstate_memory_area hypercall tries to update the
> newly registered area, even when NULL is being registered.  If the guest
> happens to have memory mapped at 0 in the address space, this write will
> succeed.
> 
> Ever since it's introduction in Xen 3.0, NULL is the initial state of
> the pointer, and guards the update of the runstate area in
> context_switch().  NULL has also been accepted as an input to the hypercall.
> 
> It is unclear whether de-registration of the area was considered at the
> time, but the behaviour of the hypercall has always supported. 
> De-registering using NULL is a common pattern for other hypercalls, so
> formally make this the case for VCPUOP_register_runstate_memory_area by
> skipping the update if the area has been de-registered.
> --8<--
> 
> I think you also want an adjustment to the public header file to say
> that NULL can be used to de-register.
> 
> Thoughts?

LGTM, I will prepare v2 then, thanks a lot for the feedback.

Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.