[Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[陳韋任 (Wei-Ren Chen)]

Hi all,

  Just for research, we are studying if we can leave the guest page
table walk to underlying hardware rather than using software emulation
(like current approach). So, maybe (if *doable*) we can use x86 hardware
to help us to walk guest (like ARM) page table. The rough idea is we
have to maintain a x86-format shadow page table for the corresponding
ARM page table, point host cr3 to the shadow page table, and let x86
hardware do its job. The problem is, we have to aware that guest is
modifying its guest page table entry so that we can sync its corrsponding
shadow page table. But, we still haven't find a good way to know when
the guest OS is modifying guest page table entry.

  Any idea is welcomed. Thanks.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[Peter Maydell]

On 8 August 2012 08:38, 陳韋任 (Wei-Ren Chen) <chenwj@iis.sinica.edu.tw> wrote:
>   Just for research, we are studying if we can leave the guest page
> table walk to underlying hardware rather than using software emulation
> (like current approach). So, maybe (if *doable*) we can use x86 hardware
> to help us to walk guest (like ARM) page table. The rough idea is we
> have to maintain a x86-format shadow page table for the corresponding
> ARM page table, point host cr3 to the shadow page table, and let x86
> hardware do its job. The problem is, we have to aware that guest is
> modifying its guest page table entry so that we can sync its corrsponding
> shadow page table. But, we still haven't find a good way to know when
> the guest OS is modifying guest page table entry.

Make it read-only for the guest, and then when you get the exception when
the guest tries to write it, you can (a) do what you need to do and (b)
emulate the failing write insn.

-- PMM

Re: [Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[陳韋任 (Wei-Ren Chen)]

On Wed, Aug 08, 2012 at 09:05:18AM +0100, Peter Maydell wrote:
> On 8 August 2012 08:38, 陳韋任 (Wei-Ren Chen) <chenwj@iis.sinica.edu.tw> wrote:
> >   Just for research, we are studying if we can leave the guest page
> > table walk to underlying hardware rather than using software emulation
> > (like current approach). So, maybe (if *doable*) we can use x86 hardware
> > to help us to walk guest (like ARM) page table. The rough idea is we
> > have to maintain a x86-format shadow page table for the corresponding
> > ARM page table, point host cr3 to the shadow page table, and let x86
> > hardware do its job. The problem is, we have to aware that guest is
> > modifying its guest page table entry so that we can sync its corrsponding
> > shadow page table. But, we still haven't find a good way to know when
> > the guest OS is modifying guest page table entry.
> 
> Make it read-only for the guest, and then when you get the exception when
> the guest tries to write it, you can (a) do what you need to do and (b)
> emulate the failing write insn.

  You mean like what KVM does for shadow page table? I think we should
mprotect the QEMU virtual memory which is allocated as a guest page
table by the guest OS, right? If so, how do we know what (QEMU) virtual
memory we should protect? The other way I was thought of is to see if
we can aware some guest code sequence modifying pte, but so far no clue
to it.

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[Blue Swirl]

On Wed, Aug 8, 2012 at 8:33 AM, 陳韋任 (Wei-Ren Chen)
<chenwj@iis.sinica.edu.tw> wrote:
> On Wed, Aug 08, 2012 at 09:05:18AM +0100, Peter Maydell wrote:
>> On 8 August 2012 08:38, 陳韋任 (Wei-Ren Chen) <chenwj@iis.sinica.edu.tw> wrote:
>> >   Just for research, we are studying if we can leave the guest page
>> > table walk to underlying hardware rather than using software emulation
>> > (like current approach). So, maybe (if *doable*) we can use x86 hardware
>> > to help us to walk guest (like ARM) page table. The rough idea is we
>> > have to maintain a x86-format shadow page table for the corresponding
>> > ARM page table, point host cr3 to the shadow page table, and let x86
>> > hardware do its job. The problem is, we have to aware that guest is
>> > modifying its guest page table entry so that we can sync its corrsponding
>> > shadow page table. But, we still haven't find a good way to know when
>> > the guest OS is modifying guest page table entry.
>>
>> Make it read-only for the guest, and then when you get the exception when
>> the guest tries to write it, you can (a) do what you need to do and (b)
>> emulate the failing write insn.
>
>   You mean like what KVM does for shadow page table? I think we should
> mprotect the QEMU virtual memory which is allocated as a guest page
> table by the guest OS, right? If so, how do we know what (QEMU) virtual
> memory we should protect? The other way I was thought of is to see if
> we can aware some guest code sequence modifying pte, but so far no clue
> to it.

See for example notdirty and watch_mem handling in exec.c.

>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Computer Systems Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
> Homepage: http://people.cs.nctu.edu.tw/~chenwj
>

Re: [Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[陳韋任 (Wei-Ren Chen)]

Hi Blue,

> >   You mean like what KVM does for shadow page table? I think we should
> > mprotect the QEMU virtual memory which is allocated as a guest page
> > table by the guest OS, right? If so, how do we know what (QEMU) virtual
> > memory we should protect? The other way I was thought of is to see if
> > we can aware some guest code sequence modifying pte, but so far no clue
> > to it.
> 
> See for example notdirty and watch_mem handling in exec.c.

  There are functions st{l,q}_phys_notdirty and notdirty_mem_write, you
mean which one? Sadly, I am not familiar with the memory stuff. Could
you explain a little bit about what notdirty and watch_mem does? Googleing 
doesn't help much...

  Thanks!

Regards,
chenwj

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[Blue Swirl]

On Thu, Aug 9, 2012 at 3:15 AM, 陳韋任 (Wei-Ren Chen)
<chenwj@iis.sinica.edu.tw> wrote:
> Hi Blue,
>
>> >   You mean like what KVM does for shadow page table? I think we should
>> > mprotect the QEMU virtual memory which is allocated as a guest page
>> > table by the guest OS, right? If so, how do we know what (QEMU) virtual
>> > memory we should protect? The other way I was thought of is to see if
>> > we can aware some guest code sequence modifying pte, but so far no clue
>> > to it.
>>
>> See for example notdirty and watch_mem handling in exec.c.
>
>   There are functions st{l,q}_phys_notdirty and notdirty_mem_write, you
> mean which one? Sadly, I am not familiar with the memory stuff. Could
> you explain a little bit about what notdirty and watch_mem does? Googleing
> doesn't help much...

Dirty tracking (notdirty_mem_write etc.) is used to handle
self-modifying code and to optimize video RAM access.

In the SMC case, pages with code are marked as not dirty until they
are written to. When they are thus dirtied, the TLB entries and TBs
are purged.

A simplistic way to handle video memory would be to track accesses
like any other device MMIO. But it's much faster if the guest can
access video RAM directly like system RAM. Then the video device
emulations track writes with another dirty bit and only redraw regions
which have been written to since last refresh.

For watchpoints, normal memory is replaced by watch_mem handlers (like
MMIO) for the page in concern. Then the watch memory handlers are
called only for those pages instead of for example slowing down all
memory accesses.

In your case, a new dirty bit could be added, or the page table area
could be replaced by dedicated MMIO.

>
>   Thanks!
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Computer Systems Lab, Institute of Information Science,
> Academia Sinica, Taiwan (R.O.C.)
> Tel:886-2-2788-3799 #1667
> Homepage: http://people.cs.nctu.edu.tw/~chenwj

Re: [Qemu-devel] Is it possible to detect guest OS modifying pte inside QEMU?

[陳韋任 (Wei-Ren Chen)]

Hi Peter,

On Wed, Aug 08, 2012 at 09:05:18AM +0100, Peter Maydell wrote:
> On 8 August 2012 08:38, 陳韋任 (Wei-Ren Chen) <chenwj@iis.sinica.edu.tw> wrote:
> >   Just for research, we are studying if we can leave the guest page
> > table walk to underlying hardware rather than using software emulation
> > (like current approach). So, maybe (if *doable*) we can use x86 hardware
> > to help us to walk guest (like ARM) page table. The rough idea is we
> > have to maintain a x86-format shadow page table for the corresponding
> > ARM page table, point host cr3 to the shadow page table, and let x86
> > hardware do its job. The problem is, we have to aware that guest is
> > modifying its guest page table entry so that we can sync its corrsponding
> > shadow page table. But, we still haven't find a good way to know when
> > the guest OS is modifying guest page table entry.
> 
> Make it read-only for the guest, and then when you get the exception when
> the guest tries to write it, you can (a) do what you need to do and (b)
> emulate the failing write insn.

  Let me try if I understand you correctly,

    Get cp15:c2 value (guest virtual address), then call something like
    qemu_get_ram_ptr with cp15:c2 to get its corresponding host virtual
    address. Then we mprotect(hva, 16k, PROT_READ).

  Is that a right direction? That's what I thought when you said make it
read-only. But after reading Blue's reply [1], it seems he give another
approach.    

Regards,
chenwj

[1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg125104.html

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
Homepage: http://people.cs.nctu.edu.tw/~chenwj