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

Re: [Xen-devel] [xen-4.5-testing test] 103161: regressions - FAIL



On 13/12/16 18:49, Ian Jackson wrote:
> Ian Jackson writes ("Re: [xen-4.5-testing test] 103161: regressions - FAIL"):
>> As we discussed yesterday, while this may be a real bug, I think it is
>> not really a _regression_ in the sense that the osstest baseline
>> version has the same bug.
>>
>> I therefore propose to do a force push of 4.4 too.
> I dug the coredump and built binaries out of 103161 and
>
> (gdb) bt
> #0  0x00007fd84de5a20d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x00007fd8519900d4 in address_space_rw ()
> #2  0x00007fd8519901bd in cpu_physical_memory_rw ()
> #3  0x00007fd851a6df4b in rw_phys_req_item ()
> #4  0x00007fd851a6df81 in read_phys_req_item ()
> #5  0x00007fd851a6e1dc in cpu_ioreq_move ()
> #6  0x00007fd851a6e3b6 in handle_ioreq ()
> #7  0x00007fd851a6e6d9 in cpu_handle_ioreq ()
> #8  0x00007fd8518e13fc in qemu_iohandler_poll ()
> #9  0x00007fd8518e238a in main_loop_wait ()
> #10 0x00007fd851973aa1 in main_loop ()
> #11 0x00007fd85197b049 in main ()
> (gdb)
>
> And the kernel said:
>
> qemu-system-i38[3905]: segfault at 0 ip 00007fd84de5a20d sp
> 00007ffc38857878 error 4 in libc-2.19.so[7fd84ddc8000+1a1000]
>
> The top ?? is probably because my gdb didn't find the corresponding
> correct libc.so.  Looking at the source for address_space_rw I wonder
> if it is trying to use one of the `memcpy' calls on the
> `memory_access_is_direct' branches, which would be a serious mistake.
>
> Sadly there is no debug information.  qemu seems to have crashed
> without producing any output of any knd.

The XSA-195 PoC is very short.

http://xenbits.xen.org/gitweb/?p=xtf.git;a=blob;f=tests/xsa-195/main.c;h=5cc2c18d82ab8d350cd07784d82680d4d0c7e72b;hb=HEAD

It constructs itself a memory hole with decrease_reservation of gfn 0,
then points a specially-crafted `bt` instruction to see whether Xen
crashes during emulation.

With Xen fixed, the emulation code in the hypervisor will come to the
conclusion that this is MMIO which should be sent to qemu.  Xen will
therefore ask Qemu what value should be found at guest physical address
0xff8.  I wonder if the fact that this is gfn 0 is causing Qemu to do
something wrong...

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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