Modify cr0 at dom0

Modify cr0 at dom0

[machi1271]

[-- Attachment #1.1: Type: text/plain, Size: 1120 bytes --]

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.

Regards~




machi1271

[-- Attachment #1.2: Type: text/html, Size: 2729 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Modify cr0 at dom0

[Razvan Cojocaru]

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

Re: Modify cr0 at dom0

[machi1271]

[-- Attachment #1.1: Type: text/plain, Size: 1915 bytes --]

Thanks Razvan~

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?

Regards




machi1271

From: Razvan Cojocaru
Date: 2014-10-17 14:25
To: machi1271; xen-devel
Subject: Re: [Xen-devel] Modify cr0 at dom0
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

[-- Attachment #1.2: Type: text/html, Size: 5152 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Modify cr0 at dom0

[Razvan Cojocaru]

On 10/17/14 09:34, machi1271 wrote:
> Thanks Razvan~
>  
> 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?

Sure, there's an example here:

https://stackoverflow.com/questions/3962950/how-to-set-control-register-0-cr0-bits-in-x86-64-using-gcc-assembly-on-linux


Razvan

Re: Modify cr0 at dom0

[machi1271]

[-- Attachment #1.1: Type: text/plain, Size: 3174 bytes --]

I'v tried the way to modify CR0 by writing to it directly. But I got the following error:
\x02(XEN) traps.c:1768:d0 Attempt to change unmodifiable CR0 flags.
general protection fault: 0000 [1] SMP 
last sysfs file: /devices/pci0000:00/0000:00:00.0/resource
CPU 0 
Modules linked in: fsp(U) autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc ip_conntrack_netbios_ns ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables acpiphp loop dm_multipath scsi_dh video backlight sbs power_meter hwmon i2c_ec dell_wmi wmi button battery asus_acpi ac ipv6 xfrm_nalgo crypto_api lp joydev floppy sg snd_ens1371 gameport i2c_piix4 snd_rawmidi snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq i2c_core pcspkr snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm e1000 snd_timer snd soundcore snd_page_alloc shpchp serio_raw ide_cd parport_pc parport cdrom serial_core dm_raid45 dm_message dm_region_hash dm_mem_cache dm_snapshot dm_zero dm_mirror dm_log dm_mod ata_piix libata mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 4103, comm: insmod Tainted: G      2.6.18-194.el5xen #1
RIP: e030:[<ffffffff88218020>]  [<ffffffff88218020>] :fsp:init_fsp+0x20/0x2d
RSP: e02b:ffff880025145f50  EFLAGS: 00010202
RAX: 000000008004003b RBX: ffffffff88680600 RCX: 0000000000000000
RDX: 000000008005003b RSI: 0000000000000000 RDI: 0000000000000000
RBP: 000000001fc65060 R08: 000000001fc65060 R09: 0000000000000000
R10: ffff880024967360 R11: ffff880032c42100 R12: 0000000000094ee5
R13: 00002b3383dc6010 R14: 0000000000100000 R15: 0000000000100000
FS:  00002b3383dc5750(0000) GS:ffffffff805d2000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process insmod (pid: 4103, threadinfo ffff880025144000, task ffff880032c42100)
Stack:  ffffffff802a28e8  0000000000100000  00002b3383dc6010  0000000000000003 
 00007fff5237dbdc  0000000000094ee5  ffffffff802602f9  0000000000000206 
 0000000000000000  0000000000001007 
Call Trace:
 [<ffffffff802a28e8>] sys_init_module+0xaf/0x1f2
 [<ffffffff802602f9>] tracesys+0xab/0xb6


Code: 0f 22 c0 31 c0 48 89 15 3c 09 47 00 c3 00 00 00 00 00 00 00 
RIP  [<ffffffff88218020>] :fsp:init_fsp+0x20/0x2d
 RSP <ffff880025145f50>
 <0>Kernel panic - not syncing: Fatal exception
 (XEN) Domain 0 crashed: rebooting machine in 5 seconds.

Directly modifying CR0 by assembly language seems to modify the real physical register on the  real CPU, 
but I just want to modify dom's virtual CR0 in the vcpu structure, since I want to modify some memory area 
in dom0's kernel which is protected by dom0's vcpu's CR0.WP bit.

Regards~




machi1271

From: Razvan Cojocaru
Date: 2014-10-17 14:48
To: machi1271; xen-devel
Subject: Re: [Xen-devel] Modify cr0 at dom0
On 10/17/14 09:34, machi1271 wrote:
> Thanks Razvan~
>  
> 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?

Sure, there's an example here:

https://stackoverflow.com/questions/3962950/how-to-set-control-register-0-cr0-bits-in-x86-64-using-gcc-assembly-on-linux


Razvan

[-- Attachment #1.2: Type: text/html, Size: 5535 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Modify cr0 at dom0

[Razvan Cojocaru]

On 10/17/2014 10:14 AM, machi1271 wrote:
> I'v tried the way to modify CR0 by writing to it directly. But I got the
> following error:
> 
>         \x02(XEN) traps.c:1768:d0 _Attempt to change unmodifiable CR0 flags.

I think you're only allowed to modify _some_ CR0 flags by Xen (CR0.TS
and maybe others). You'd have to look at the Xen source code to see
which ones.

Hope that helps, maybe someone with more experience doing what you need
to do can chime in.


Razvan

Re: Modify cr0 at dom0

[machi1271]

[-- Attachment #1.1: Type: text/plain, Size: 744 bytes --]

I modified the memory area by vmap the protected physical page to another writable virtual address region. 

So, solved~~




machi1271

From: Razvan Cojocaru
Date: 2014-10-17 16:01
To: machi1271; xen-devel
Subject: Re: [Xen-devel] Modify cr0 at dom0
On 10/17/2014 10:14 AM, machi1271 wrote:
> I'v tried the way to modify CR0 by writing to it directly. But I got the
> following error:
> 
>         \x02(XEN) traps.c:1768:d0 _Attempt to change unmodifiable CR0 flags.

I think you're only allowed to modify _some_ CR0 flags by Xen (CR0.TS
and maybe others). You'd have to look at the Xen source code to see
which ones.

Hope that helps, maybe someone with more experience doing what you need
to do can chime in.


Razvan

[-- Attachment #1.2: Type: text/html, Size: 2713 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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