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

Re: [PATCH v3] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 24 Mar 2023 14:29:22 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RWWrS74WSOQUA1xT610YvJwS5RqChROnokLmJrPMQ1I=; b=m6loFVy4S8kS4WbGchMYgPPunZGwFrlEcdU5biOlUfNHThc8CdhxwaVF53PvlQy30loPjpAGfTQZt4DIS7x8GS7FmqSAnMU1v0HfDplM/nthod7pDWCFjBjsXC7hgeyKKd+xFmMRkyf3/aduUXAgceND4agT0oONbxfYGywBd6KFtcWy0v+snca03HOwqVediVX2/s3TiPdkZTXmwhCW35e/b5qcsIH3Uj1a/sT2HcsyG2OAbHaWdbbdUqe61p3839jksjiHBGEcw4864WjPKx/r0KfukTy4MQ5kH2p81UQtyYFGpnYMhvvQEH8gDcHCIkaaTpSIXDtYrcq+BKNFzA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WogrMn02h3T+8wdBe98HcUMa+lhcoSS+KGnEg+MycnfIJNtA4tTtAenH4pN0sF6PsZ/+7nttDEMUBu66ap1J84UKcMF+EI13g5zmaH/DTArGpHtiiiwPK5uIgj+44w2tqXwCiIvAyUXAe7c2g+9PxxAk5x+HOwAZQIF3LwzRUD3fsmOrIen6WzKxLEM3bSsLTfYV4Ke09sE/de9Tdj+dz7Pukeg5IhJJDbsxwrv0J1BGBTf6f/5nWqjU1zjZtc78NoXjk7I/4XecNOS1LG2ynkA+aInlDjQ5y0fD79qLoULxtAO4FiajlHWycaSSEjdMQ+XEi8kSY6uxCfujY27MPA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 24 Mar 2023 14:29:57 +0000
  • Ironport-data: A9a23:RaCYlam//6uHycmJqRq1oxvo5gwSJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xIaUGvXaf+KMTP8fNB0aI6x8kwF7JTSnNBgTQQ9+SBgHyMWpZLJC+rCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZmgH+a6U6icfHgqH2eIcQ954Tp7gek1n4V0ttawBgKJq LvartbWfVSowFaYCEpNg064gE4p7aSaVA8w5ARkPqgQ5gOGzRH5MbpETU2PByqgKmVrNrbSq 9brlNmR4m7f9hExPdKp+p6TnpoiG+O60aCm0xK6aoD66vRwjnVaPpUTbZLwXXx/mTSR9+2d/ f0W3XCGpaXFCYWX8AgVe0Ew/yiTpsSq8pefSZS0mZT7I0Er7xIAahihZa07FdRwxwp5PY1B3 flBcTkkKQGsvvir0pO6E7lKoZwfIta+aevzulk4pd3YJdAPZMmZBoD1v5pf1jp2gd1SF/HDY cZfcSBocBnLfxxIPBEQFY46m+CrwHL4dlW0qnrM/fZxvzeVklI3jOWF3Nn9I7RmQe18mEqCq 32A1GP+GhwAb/SUyCaf82LqjejK9c/+cNtKTufgpq8z2jV/wEQiCS0bWnK5psX+i3G0e8oAC RAm/i4h+P1aGEuDC4OVsweDiHyOswMYWtFQO/Yn8wzLwa3Riy6CHXQNRDNFbN0gtec1SCYs2 1vPmMnmbRRwtJWFRHTb8a2bxRuwJCwUIGkqdSICCwwf7LHLoo4piQnUZs1+C6PzhdrwcRnOx DSNoDk7lq8kp8cB3KWm/njKmzup4JPOS2Yd7AjNQnis6A8/YYe/fpGp8nDS9/MGJ4GcJnGRs X5Bl8WA4eQmCZCWiDfLUOgLBKuu5fuOLHvbm1EHInU63zGk+nrmeJ8K5jh7fR1tKpxcJWKvZ 1LPswRM4pMVJGGtcaJ8f4O2DYIt0LTkEtPmEPvTa7Kif6RMSeNOxwk2DWb44ownuBJEfX0XU XtDTfuRMA==
  • Ironport-hdrordr: A9a23:MK6VHqFc7Fdxv5FepLqELMeALOsnbusQ8zAXPiBKJCC9E/bo8v xG+c5w6faaslkssR0b9+xoW5PwI080l6QU3WB5B97LMDUO0FHCEGgI1/qA/9SPIUzDHu4279 YbT0B9YueAcGSTW6zBkXWF+9VL+qj5zEix792uq0uE1WtRGtldBwESMHf9LmRGADNoKLAeD5 Sm6s9Ot1ObCA8qhpTSPAhiYwDbzee77a7bXQ==
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 25/04/2022 2:36 pm, Jan Beulich wrote:
> On 25.04.2022 14:37, Andrew Cooper wrote:
>> When CONFIG_GDBSX is compiled out, iommu_do_domctl() falls over a NULL
>> pointer.  One of several bugs here is known-but-compiled-out subops
>> falling
>> into the default chain and hitting unrelated logic.
>>
>> Remove the CONFIG_GDBSX ifdefary in arch_do_domctl() by implementing
>> gdbsx_domctl() and moving the logic across.
>>
>> As minor cleanup,
>>  * gdbsx_guest_mem_io() can become static
>>  * Remove opencoding of domain_vcpu() and %pd
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>
> Technically
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

I'll tweak the commit message now that the IOMMU fix has gone in.

> Yet as mentioned before, ...
>
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -816,71 +816,12 @@ long arch_do_domctl(
>>      }
>>  #endif
>>  
>> -#ifdef CONFIG_GDBSX
>>      case XEN_DOMCTL_gdbsx_guestmemio:
>> -        ret = gdbsx_guest_mem_io(d, &domctl->u.gdbsx_guest_memio);
>> -        if ( !ret )
>> -           copyback = true;
>> -        break;
>> -
>>      case XEN_DOMCTL_gdbsx_pausevcpu:
>> -    {
>> -        struct vcpu *v;
>> -
>> -        ret = -EBUSY;
>> -        if ( !d->controller_pause_count )
>> -            break;
>> -        ret = -EINVAL;
>> -        if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= d->max_vcpus ||
>> -             (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) ==
>> NULL )
>> -            break;
>> -        ret = vcpu_pause_by_systemcontroller(v);
>> -        break;
>> -    }
>> -
>>      case XEN_DOMCTL_gdbsx_unpausevcpu:
>> -    {
>> -        struct vcpu *v;
>> -
>> -        ret = -EBUSY;
>> -        if ( !d->controller_pause_count )
>> -            break;
>> -        ret = -EINVAL;
>> -        if ( domctl->u.gdbsx_pauseunp_vcpu.vcpu >= d->max_vcpus ||
>> -             (v = d->vcpu[domctl->u.gdbsx_pauseunp_vcpu.vcpu]) ==
>> NULL )
>> -            break;
>> -        ret = vcpu_unpause_by_systemcontroller(v);
>> -        if ( ret == -EINVAL )
>> -            printk(XENLOG_G_WARNING
>> -                   "WARN: d%d attempting to unpause %pv which is not
>> paused\n",
>> -                   currd->domain_id, v);
>> -        break;
>> -    }
>> -
>>      case XEN_DOMCTL_gdbsx_domstatus:
>> -    {
>> -        struct vcpu *v;
>> -
>> -        domctl->u.gdbsx_domstatus.vcpu_id = -1;
>> -        domctl->u.gdbsx_domstatus.paused = d->controller_pause_count
>> > 0;
>> -        if ( domctl->u.gdbsx_domstatus.paused )
>> -        {
>> -            for_each_vcpu ( d, v )
>> -            {
>> -                if ( v->arch.gdbsx_vcpu_event )
>> -                {
>> -                    domctl->u.gdbsx_domstatus.vcpu_id = v->vcpu_id;
>> -                    domctl->u.gdbsx_domstatus.vcpu_ev =
>> -                        v->arch.gdbsx_vcpu_event;
>> -                    v->arch.gdbsx_vcpu_event = 0;
>> -                    break;
>> -                }
>> -            }
>> -        }
>> -        copyback = true;
>> +        ret = gdbsx_domctl(d, domctl, &copyback);
>>          break;
>> -    }
>> -#endif
>
> ... I'm not overly happy with the retaining of the case labels here
> (and the knock on effect it'll have for other subsystem domctl-s),

The crash in do_iommu_op() happened because things which weren't iommu
subops ended up in a function only expecting iommu subops, *because*
unrelated case labels got compiled out.

We've also had multiple XSAs elsewhere created by related "just chain
everything through default:" patterns.  The legacy MSR paths are still
especially guilty of doing this.


The case labels need to never ever get compiled out, even if their
subsystem has been.

So you have a choice between this patch, or a pattern of the form:

    case XEN_DOMCTL_gdbsx_domstatus:
        if ( !IS_ENABLED(CONFIG_GDBSX) )
        {
            ret = -Exxx;
            break;
        }
        ...

but the top level case labels need to stay one way or another.

For this patch, it moves a chunk of logic out of a fairly generic file
into its proper subsystem file, and a few extra case labels is a very
cheap price to pay.

~Andrew



 


Rackspace

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