[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- Date: Mon, 25 Apr 2022 12:25:51 +0000
- Accept-language: en-GB, en-US
- 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=WbIxPqEv/xLRrZH4pYkY3if2CrUkLgZXQoVOuHU3MUU=; b=l7HsysdYG1MELQidr6PxR1oPWZdA25BrTXASRMpSEgtIZTP6VAAZ3KjJbm7MFXQuF0B6J5PlZGuwdilkDTuhwJsfuMcT/ItRVlJqfkyvlsKLrVH3Dk/1PGw4WPeYkekla6n85oUArL59EqUY/8NRWtDdyaA/1qG7oMq5Gi5paCKbM+vicu38OVrj9NwwN7ZrqDXYTzXBkiAeKQi0gFhMbDKEwvjlgRBaI+RvE5K+ygGCdBstBVPnsl9wi7MEk3wvPd9mutMqSBjt3zq3MoARkjfQ3hkqt+JdMHcpR/68kFpAy0PbhTa1H7QjJQfqsYAa5zegTK7rCS3BkhZJnG11ew==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MB51fat64wZZ9ohmjyFmMuyGIcKN+CNkxE19KfdDDw1GK/yh86Pe2aYzdHDseT8UOMPHc+KOL9ezOd1HOjAS/9PCp1w14FcRSnEjMnNDXG3MnOFBBGMgO/j9lJOPr//j8ON7LaDkl2UoK1izLOKLPqeWtPtahNfQKRrejIAZ2p0pZRczpeCOqAHDI+CDuXfqcO6puaFFVyueaA2XJ+aKwQmszTLnibPdhfJAY6+eNRbZ6H0KTi/CnygnD0QdSbWwG7mPmzv7Se3eOq/6IOatF+IReR4NL1WRg1N9O55hB+btmVOvH5B6OO7hOX6Nqdl/oUplg1VhRJ4jTps52oQCzg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 25 Apr 2022 12:26:08 +0000
- Ironport-data: A9a23:scq5vKO8myC2TxXvrR1FlsFynXyQoLVcMsEvi/4bfWQNrUpzhT1Sy jcXXG6HbPmJY2b9ct0iYNu+oUpSvJPcnNQ1Tgto+SlhQUwRpJueD7x1DKtR0wB+jCHnZBg6h ynLQoCYdKjYdleF+lH1dOKJQUBUjclkfJKlYAL/En03FFcMpBsJ00o5wbZl2NMw2LBVPivW0 T/Mi5yHULOa82Yc3lI8s8pvfzs24ZweEBtB1rAPTagjUG32zhH5P7pGTU2FFFPqQ5E8IwKPb 72rIIdVXI/u10xF5tuNyt4Xe6CRK1LYFVDmZnF+A8BOjvXez8CbP2lS2Pc0MC9qZzu1c99Zm fx/tbzrTgAVLrT1gcsXfAJnS31hFPgTkFPHCSDXXc276WTjKiOp6dMxSUY8MMsf5/p9BnxI+ boAMjcRYxufhuWwhrWmVu1rgcdlJ87uVG8dkig4kXeFUrB5GdaaG/yiCdxwhV/cguhnG/rEa tVfQj1odBnaODVEO0sNCYJ4l+Ct7pX6W2MJ9wnN+PJoi4TV5BByzun0adbSRsHQauQIo1nH+ lCX72usV3n2M/Tak1Jp6EmEhOXCgCf6U4I6D6Cj+7hhh1j77ncIFBQcWF+/oP+4ok2zQdRSL woT4CVGhbc23FymSJ/6RRLQiHyZuh8RXfJAHut87xuCooLW7ByeHXMsVSNaZZots8pebQIt0 liFjtb4HwtFubeeSW+e3rqMpDb0Mi8QRUcIaDUYVwID75/mqZsqkxPUZt95Fei+ididMSH9x XWGoTYzg50XjNUXzOOr8FbfmTWuq5PVCAkv6W3qsnmN6wp4YMuvYdOu4F2CtfJYdt/BFx+Go WQOnNWY4KYWF5aRmSeRQeILWra0+/KCNz6aillqd3U8ywmQF7eYVdg4yFlDyI1BaK7opReBj JfvhD5s
- Ironport-hdrordr: A9a23:BKW/0KkrVKA88vLQppoSTWoZ6tfpDfN1iWdD5ihNYBxZY6Wkfp +V8cjzhCWftN9OYhodcIi7SdK9qXO1z+8X3WGIVY3SEDUOy1HYVr2KirGSjAEIeheOu9K1sJ 0NT0EQMqyWMbEXt6fHCUyDYq4dKbq8ge6VbIXlvhFQpGhRAskOgTuRSDzra3GeLzM2Z6bRYa Dsgvav0ADQHEj/AP7aOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPcf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcdcsvy5zXIISdOUmRIXee r30lAd1gNImjXsl1SO0F7QMs/boW8TAjHZuAelaDDY0LHErXoBerZ8bMRiA1rkAgMbza9BOO gg5RPni7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4YkWUzxjIiLH47JlOy1GnnKp gdMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx+DBkwPoNac3TRalG1wixJw/r1Uol4QsJYmD5VU7e XNNapl0LlIU88NdKp4QOMMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+93JwloOWxPJAYxpo7n5 rMFFteqG4pYkrrTdaD2ZVamyq9N1lVnQ6dvv22y6IJyoEUHoCbQBFrYGpe4PeIsrEYHtDRXe q1NdZfH+LjRFGebLp04w==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHYWIw8chvpJExnr0WEKHKghrmtCq0Ad2cAgAAWtIA=
- Thread-topic: [PATCH v2] x86: Fix XEN_DOMCTL_gdbsx_guestmemio crash
On 25/04/2022 12:04, Jan Beulich wrote:
> On 25.04.2022 12:06, Andrew Cooper wrote:
>> @@ -178,6 +179,71 @@ void domain_pause_for_debugger(void)
>> send_global_virq(VIRQ_DEBUGGER);
>> }
>>
>> +long gdbsx_domctl(struct domain *d, struct xen_domctl *domctl, bool
>> *copyback)
> Is there anything that requires "long" (and not just "int") here and ...
>
>> +{
>> + struct vcpu *v;
>> + long ret = 0;
> ... here?
Consistency with its caller.
Although I can't actually see a good reason for arch_do_domctl() to use
long's either, and that would at least mean we've only got one place
doing extension of ret.
>
>> + switch ( domctl->cmd )
>> + {
>> + 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:
>> + ret = -EBUSY;
>> + if ( !d->controller_pause_count )
>> + break;
>> + ret = -EINVAL;
>> + if ( (v = domain_vcpu(d, domctl->u.gdbsx_pauseunp_vcpu.vcpu)) ==
>> NULL )
>> + break;
>> + ret = vcpu_pause_by_systemcontroller(v);
>> + break;
>> +
>> + case XEN_DOMCTL_gdbsx_unpausevcpu:
>> + ret = -EBUSY;
>> + if ( !d->controller_pause_count )
>> + break;
>> + ret = -EINVAL;
>> + if ( (v = domain_vcpu(d, domctl->u.gdbsx_pauseunp_vcpu.vcpu)) ==
>> NULL )
>> + break;
>> + ret = vcpu_unpause_by_systemcontroller(v);
>> + if ( ret == -EINVAL )
>> + printk(XENLOG_G_WARNING
>> + "WARN: %pd attempting to unpause %pv which is not
>> paused\n",
>> + current->domain, v);
>> + break;
>> +
>> + case XEN_DOMCTL_gdbsx_domstatus:
>> + 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;
>> + break;
>> +
>> + default:
>> + ASSERT_UNREACHABLE();
>> + ret = -ENOSYS;
>> + }
> Just as a remark: It's never really clear to me whether we actually want
> to permit omitting "break" in cases like this one.
That was an oversight. I'd intended to include one.
>> --- a/xen/arch/x86/include/asm/gdbsx.h
>> +++ b/xen/arch/x86/include/asm/gdbsx.h
>> @@ -2,18 +2,27 @@
>> #ifndef __X86_GDBX_H__
>> #define __X86_GDBX_H__
>>
>> -#ifdef CONFIG_GDBSX
>> +#include <xen/stdbool.h>
>>
>> struct domain;
>> -struct xen_domctl_gdbsx_memio;
>> +struct xen_domctl;
>>
>> -int gdbsx_guest_mem_io(struct domain *d, struct xen_domctl_gdbsx_memio
>> *iop);
>> +#ifdef CONFIG_GDBSX
>>
>> void domain_pause_for_debugger(void);
>>
>> +long gdbsx_domctl(struct domain *d, struct xen_domctl *domctl, bool
>> *copyback);
>> +
>> #else
>>
>> +#include <xen/errno.h>
>> +
>> static inline void domain_pause_for_debugger(void) {}
>>
>> +long gdbsx_domctl(struct domain *d, struct xen_domctl *domctl, bool
>> *copyback)
> static inline?
Oops yes. I clearly need more coffee.
~Andrew
|