I'm new to Xen and Linux.
Could you please tell me is there any Xen-independent manner to modify
CR0, or the memory area protected by CR0.WP bit?
On 10/17/14 04:47, machi1271 wrote:
> hi,
> Background:
> I want to hook the syscalls for dom0. So, I get the syscall_enter
> address by calling HYPERVISOR_domctl, with xen_domctl.cmd =
> XEN_DOMCTL_getvcpucontext.
> The returned ctx.syscall_callback_eip is correct, and I find the
> syscall_table address from the syscall_callback_eip.
> Now, my target is to modify the original syscall_table, and I know I
> should clear the CR0.WP bit before modify.
>
> However, when I try to set cr0 back to hypervisor after the cr0.WP being
> cleared through HYPERVISOR_domctl(with xen_domctl.cmd =
> XEN_DOMCTL_setvcpucontext),
> dom0 DEAD.
>
> I traced into the hypercall, and I find the program dead in the
> following while loop:
> void vcpu_sleep_sync(struct vcpu *v)
> {
> vcpu_sleep_nosync(v);
>
> while ( !vcpu_runnable(v) && v->is_running )
> cpu_relax();
>
> sync_vcpu_execstate(v);
> }
> in domain_pause.
>
> Why? Is Calling XEN_DOMCTL_setvcpucontext from dom0 not allowed? Or, is
> there another way to make the memory area protected by WP to be writable?
>
> I am running my code on 2.6.18-194.el5xen., no domain is running except
> dom0.
Calling setvcpucontext() _from_ dom0 is indeed allowed (I'm doing it
with no apparent ill-effects), however I'm not sure about calling it
_from_ dom0 _to_ dom0 - I've only tried it with HVM guests _other_ than
dom0.
Calling that hypercall from dom0 to modify dom0's state does sound a bit
unnecessary - why can't you just modify dom0's state in a
Xen-independent manner?
Razvan
