Re: IOCTL_PRIVCMD_MMAPBATCH on Xen 4.13.0

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/05/2020 22:06, Manuel Bouyer wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
> unless you have verified the sender and know the content is safe.
>
> On Fri, May 15, 2020 at 10:00:07PM +0100, Andrew Cooper wrote:
>> What is qemu doing at the time?  Is it by any chance trying to map the
>> IOREQ server frame?
> Here's what gdb says about it:
> Core was generated by `qemu-dm'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x000000000046997d in cpu_x86_init (
>     cpu_model=cpu_model@entry=0x4d622d "qemu32")
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/i386-dm/helper2.c:156
> 156                 rc = xenevtchn_bind_interdomain(
> --Type <RET> for more, q to quit, c to continue without paging--
> [Current thread is 1 (process 1480)]
> (gdb) where
> #0  0x000000000046997d in cpu_x86_init (
>     cpu_model=cpu_model@entry=0x4d622d "qemu32")
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/i386-dm/helper2.c:156
> #1  0x000000000043628d in pc_init1 (ram_size=<optimized out>, 
>     vga_ram_size=4194304, boot_device=0x7f7fff460397 "cda", pci_enabled=1, 
>     cpu_model=0x4d622d "qemu32", initrd_filename=<optimized out>, 
>     kernel_cmdline=<optimized out>, kernel_filename=<optimized out>)
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/hw/pc.c:829
> #2  0x00000000004636e7 in xen_init_fv (ram_size=0, vga_ram_size=4194304, 
>     boot_device=0x7f7fff460397 "cda", kernel_filename=0x0, 
>     kernel_cmdline=0x4abff6 "", initrd_filename=0x0, cpu_model=0x0, 
>     direct_pci=0x0)
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/hw/xen_machine_fv.c:405
> #3  0x00000000004a975b in main (argc=23, argv=0x7f7fff45fc78, 
>     envp=<optimized out>)
>     at 
> /home/bouyer/pkgbuild/current/sysutils/xentools413/work/xen-4.13.0/tools/qemu-xen-traditional/vl.c:6014
>
> Does it help ?

Yes and no.  This is collateral damage of earlier bug.

What failed was xen_init_fv()'s

    shared_page = xc_map_foreign_range(xc_handle, domid, XC_PAGE_SIZE,
                                       PROT_READ|PROT_WRITE, ioreq_pfn);
    if (shared_page == NULL) {
        fprintf(logfile, "map shared IO page returned error %d\n", errno);
        exit(-1);
    }

because we've ended up with a non-NULL pointer with no mapping behind
it, hence the SIGSEGV for the first time we try to use the pointer.

Whatever logic is behind xc_map_foreign_range() should have returned
NULL or a real mapping.

ioreq_pfn ought to be something just below the 4G boundary, and the
toolstack ought to put memory there in the first place.  Can you
identify what value ioreq_pfn has, and whether it matches up with the
magic gfn range as reported by `xl create -vvv` for the guest?

~Andrew