Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

[Mathieu Tarral <mathieu.tarral@xxxxxxxxxxxxxx>]

Hi,

Yes I missed that PatchGuard would eventually check those shadow pages anyway.

I was already happy to see that my breakpoints were working, and I proceeded to the tests

hoping to have a quick reproduction of the bug.

I implemented a basic mem_access event on the restricting to --X only on the original GFN being remapped,

and switching to hostp2m and singlestepping to escape PatchGuard.

It works, but I end up in a situation where Xen fails at some point, because at ~90 tests, it cannot populate the ring anymore:

INFO:root:==== test 92 ====

INFO:root:starting drakvuf

INFO:root:starting Ansible

INIT

xen_init_interface

xc_interface_open

create logger

allocating libxc context

init ring page

xc: error: Failed to populate ring pfn

(16 = Device or resource busy): Internal error

fail to enable monitoring: Device or resource busy

fail to init xen interface

CLOSE

Fail to init vmi

(I updated the Gist: https://gist.github.com/mtarral/d99ce5524cfcfb5290eaa05702c3e8e7#file-xen-drakvuf-c)

What do you think happened ?

I have a call to xc_domain_setmaxmem with ~0, so it shouldn't happen ?

https://gist.github.com/mtarral/d99ce5524cfcfb5290eaa05702c3e8e7#file-xen-drakvuf-c-L598

I moved the call to xc_domain_setmaxmem BEFORE xc_monitor_enable.

Which works.

I'm continuing my testing to see if I can reproduce the bug.

Mathieu

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel