xenaccess-devel — General list for all technical issues related to the XenAccess Library

[XenAccess-devel] Moving to Google Code / Google Groups

[Bryan D. P. <br...@th...>]

As many of you have already noticed, I have moved the XenAccess
project from SourceForge to Google Code.  To complete the move, I am
also moving this mailing list (to Google Groups).  There is a new
Google Group set up called xenaccess.  You can find it using the link
below.  I will *not* be automatically moving / subscribing anyone to
the new Google Group.  However, the mailing list on SourceForge will
no longer be used.  If you would like to keep up with discussions on
XenAccess, then you should go join the group:

http://groups.google.com/group/xenaccess

Also, this summer I'm working on updating XenAccess with new features
and support for newer versions of Xen.  I'll be making announcements
on the Google Groups page as new features become available.

Cheers,
bryan


-- 
Bryan D. Payne
Research Scientist & Graduate Student
Georgia Tech Information Security Center
http://www.bryanpayne.org

Re: [XenAccess-devel] Getting the IDT of an HVM guest

[Bryan D. P. <br...@th...>]

This information should be in the VMCS.  You can access this via the
__vmread() function in the hypervisor, but to get this from dom0 may
be trickier.  It could be that this is what the comment on the mailing
list is referring to (basically finding the VMCS information in the
state to extract the IDTR information).  You could also add a
hypercall that exposes the VMCS information, but that is probably a
second choice if there's already another way using the existing API.

-bryan


On Feb 1, 2008 12:25 PM, Matthew Donovan <ma...@at...> wrote:
> Hey,
>
> I'm trying to retrieve the IDT of an HVM guest (XP/Vista) but the
> xc_vcpu_getcontext() function doesn't return anything useful.  I asked on
> the Xen devel mailing list and was told:
>
> "Unfortunately the IDTR is not exposed via vcpu_context for HVM guests. The
> only way to get it right now is to do a hvm save hypercall and then parse
> the pickled state to find the IDTR. It actually should be quite easy."
>
> I was digging around in the Xen source and found a hvm_save() function but
> it isn't in the Xen headers I have.
>
> Have you looked at this at all?
>
> Thanks
> -matthew


-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

[XenAccess-devel] Getting the IDT of an HVM guest

[Matthew D. <ma...@at...>]

Hey,

I'm trying to retrieve the IDT of an HVM guest (XP/Vista) but the
xc_vcpu_getcontext() function doesn't return anything useful.  I asked on
the Xen devel mailing list and was told:  

"Unfortunately the IDTR is not exposed via vcpu_context for HVM guests. The
only way to get it right now is to do a hvm save hypercall and then parse
the pickled state to find the IDTR. It actually should be quite easy."

I was digging around in the Xen source and found a hvm_save() function but
it isn't in the Xen headers I have.

Have you looked at this at all?  

Thanks
-matthew

Re: [XenAccess-devel] process-list works with Vista VM (with a co uple tweaks)

[Matthew D. <ma...@at...>]

Crap.  Once again, I hit the wrong button and sent the email before I =
was
done.

I got the process-list example to work with a Vista (Ultimate) VM.  The
offsets had to be changed, of course:

#define ActiveProcessLinks_OFFSET    0xa0
#define UniqueProcessId_OFFSET       0x9c
#define ImageFileName_OFFSET         0x14c=20

Also, the page_offset value that I had to change to get the samples =
working
for XP (I changed from 0x80000000 to 0x7FC00000) had to be changed back =
to
0x80000000.

I say the program worked, but the last entry in the list is wrong:
   [1182726] =C8-=B5'=01

I haven't had a chance to look at it more closely yet.

The module-list sample doesn't work but I suppose it's because of a
hard-coded address that is different for Vista.

One thing to note:  By default Vista's kernel debugging is off.  You =
can
turn it on in one of two ways:
   1)  Right as Vista starts to boot, hold F8 and select "Debugging =
mode"
   2)  From an administrative command line enter: "bcdedit.exe -debug =
on"
and reboot.

*IMPORTANT:  Don't do number 2.  I can't get Vista to boot in debug =
mode in
a Xen virtual machine.  Option 2 above changes boot parameters (akin to
modifying boot.ini) and I couldn't find a way to undo it without =
booting
Vista (which I couldn't do.)  So until you know if it works, I =
recommend
option 1.  (I had to reinstall my Vista VM twice before I learned my
lesson.)

If you find something about this (booting Vista in debug mode with Xen)
please let me know.

-matthew

Re: [XenAccess-devel] process-list works with Vista VM (with a couple tweaks)

[Bryan D. P. <br...@th...>]

Excellent, thanks!
-bryan


On Jan 23, 2008 3:16 PM, Matthew Donovan <ma...@at...> wrote:
> I got the process-list example to work with a Vista (Ultimate) VM.  The
> offsets had to be changed, of course:
>
> #define ActiveProcessLinks_OFFSET    0xa0
> #define UniqueProcessId_OFFSET       0x9c
> #define ImageFileName_OFFSET         0x14c
>
> Also, the page_offset value that I had to change to get the samples working
> for XP (I changed from 0x80000000 to 0x7FC00000) had to be changed back to
> 0x80000000.
>
> I say the program worked, but the last entry in the list is wrong:
>
>
> The module-list sample doesn't work but I'm guessing it's because of a
> hard-coded address that is different for Vista.
>



-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

[XenAccess-devel] process-list works with Vista VM (with a couple tweaks)

[Matthew D. <ma...@at...>]

I got the process-list example to work with a Vista (Ultimate) VM.  The
offsets had to be changed, of course:

#define ActiveProcessLinks_OFFSET    0xa0
#define UniqueProcessId_OFFSET       0x9c
#define ImageFileName_OFFSET         0x14c 

Also, the page_offset value that I had to change to get the samples working
for XP (I changed from 0x80000000 to 0x7FC00000) had to be changed back to
0x80000000.

I say the program worked, but the last entry in the list is wrong:


The module-list sample doesn't work but I'm guessing it's because of a
hard-coded address that is different for Vista.

Re: [XenAccess-devel] process-data example and Page Tables

[Bryan D. P. <br...@th...>]

> Do page tables store virtual or physical addresses?

Page tables (the last stage in the address translation procedure)
store physical addresses.


> So for a process (with PAE enabled) CR3 is the physical address of the page
> directory pointer (PDP) table (let's say 0x69C0020).  You take the last
> couple bits from the virtual address, multiply that by the size of an entry
> in the PDP (8 bytes) and you have the offset into the table (0x8), so the
> eight bytes at 0x69C0028 is an address to page directory.  Is that address a
> virtual address or a physical address?

"last couple of bits" == the high order bits

The resulting address is a physical address.


> As I mentioned before, the process-data example program isn't working
> correctly.  The problem seems to be when it is translating the virtual
> address of the PEB.  It gets the EPROCESS block without a problem, and gets
> the value of CR3/DirectoryTableBase (x69C0020).  It then converts that
> address to the virtual address (x865c0020), gets the offset (0x8) into the
> page directory pointer table and adds it to the virtual address, ending up
> with x865C0028.  The problem comes when it tries to look up 0x865C0028; it
> tries to look up the address (with xa_read_long_long_virt()) with a PID of 0
> (System Idle Process) and can't find it.
>
> If the page tables know physical addresses, it seems the physical - virtual
> - physical translations are unnecessary.

Yeah, this is true that there are some extra translations happening.
This is a result of some code evolution.  But I'm not sure that this
is the problem.  If the various translations are working properly,
then these extra translations shouldn't be breaking the example.

-bryan


-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

[XenAccess-devel] process-data example and Page Tables

[Matthew D. <ma...@at...>]

Do page tables store virtual or physical addresses?

So for a process (with PAE enabled) CR3 is the physical address of the page
directory pointer (PDP) table (let's say 0x69C0020).  You take the last
couple bits from the virtual address, multiply that by the size of an entry
in the PDP (8 bytes) and you have the offset into the table (0x8), so the
eight bytes at 0x69C0028 is an address to page directory.  Is that address a
virtual address or a physical address?

As I mentioned before, the process-data example program isn't working
correctly.  The problem seems to be when it is translating the virtual
address of the PEB.  It gets the EPROCESS block without a problem, and gets
the value of CR3/DirectoryTableBase (x69C0020).  It then converts that
address to the virtual address (x865c0020), gets the offset (0x8) into the
page directory pointer table and adds it to the virtual address, ending up
with x865C0028.  The problem comes when it tries to look up 0x865C0028; it
tries to look up the address (with xa_read_long_long_virt()) with a PID of 0
(System Idle Process) and can't find it.  

If the page tables know physical addresses, it seems the physical - virtual
- physical translations are unnecessary.

Thanks
-matthew

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Matthew D. <ma...@at...>]

The process-list and module-list examples work.  The process-data example
fails with "failed to get process addresses from peb: Bad address" (full
output below).  I haven't looked closely at this one yet.

Regarding the 'magic' EPROCESS number in Vista, I was a little off.  The
_DISPATCHER_HEADER struct definition has changed (from wdm.h):

typedef struct _DISPATCHER_HEADER {
    union {
        struct {
            UCHAR Type;
            union {
                UCHAR Abandoned;
                UCHAR Absolute;
                UCHAR NpxIrql;
                BOOLEAN Signalling;
            };

            union {
                UCHAR Size;
                UCHAR Hand;
            };

            union {
                UCHAR Inserted;
                BOOLEAN DebugActive;
                BOOLEAN DpcActive;
            };
        };

        volatile LONG Lock;
    };

In the Windbg output, I didn't notice that some of the offsets were the same
(i.e. the struct used unions.)  However, the size has changed to 0x20 so I
believe the 'magic' number for Vista is 0x00200003.

-matthew

process-data output:

XenAccess Devel Version
--got domain info.
**set instance->xen_version = 3.1.0
--got domain name from id (2 ==> winxp0).
     1 |winvista {
     2 |	sysmap		="/root/examin/libxa/winvista-exports.txt";
     3 |	ostype 		= "Windows";
     4 |	win_tasks	= 0xa0;
     5 |	win_pdbase	= 0x18;
     6 |	win_pid		= 0x9c;
     7 |	win_peb		= 0x188;
     8 |	win_iba		= 0x8;
     9 |        win_ph          = 0x18;
    10 |}
    11 |
    12 |winxp0 {
    13 |	sysmap
="/root/examin/libxa/winxp-vm-pae-exports.txt";
    14 |	ostype 		= "Windows";
    15 |	win_tasks	= 0x88;
    16 |	win_pdbase	= 0x18;
    17 |	win_pid		= 0x84;
    18 |	win_peb		= 0x1b0;
    19 |	win_iba		= 0x8;
    20 |        win_ph          = 0x18;
    21 |}
    22 |
--got sysmap from config (/root/examin/libxa/winxp-vm-pae-exports.txt).
--reading in windows offsets from config file.
--got ostype from config (Windows).
**set instance->os_type to Windows.
**set instance->pae = 1
**set instance->pse = 1
--got memory layout.
**set instance->hvm to true (HVM).
--got ntoskrnl (0x004d7000).
--PTLookup: lookup vaddr = 0x80159554
--PTLookup: cr3 = 0x00000001
--PTLookup: pdpi_entry = 0x00000010
--PTLookup: pdpe = 0x00000000bfcfd8a8
++Cache set (PsInitialSystemProcess --> 0x00000000)
--got PA to PsInititalSystemProcess (0x025c8a00).
**set instance->kpgd (0x806ee000).
**set instance->init_task (0x81fd8250).
--PTLookup: lookup vaddr = 0x81fd8250
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x023d8250
++Cache set (0x81fd8000 --> 0x023d8000)
--MapMFN: Mapping mfn = 0x000023d8.
--PTLookup: lookup vaddr = 0x820aad30
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1080
--PTLookup: pgd = 0x00000000024001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x024aad30
++Cache set (0x820aa000 --> 0x024aa000)
--MapMFN: Mapping mfn = 0x000024aa.
--PTLookup: lookup vaddr = 0x81fe70a8
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x023e70a8
++Cache set (0x81fe7000 --> 0x023e7000)
--MapMFN: Mapping mfn = 0x000023e7.
--PTLookup: lookup vaddr = 0x820bf3c0
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1080
--PTLookup: pgd = 0x00000000024001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x024bf3c0
++Cache set (0x820bf000 --> 0x024bf000)
--MapMFN: Mapping mfn = 0x000024bf.
--PTLookup: lookup vaddr = 0x81fbf0a8
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x023bf0a8
++Cache set (0x81fbf000 --> 0x023bf000)
--MapMFN: Mapping mfn = 0x000023bf.
--PTLookup: lookup vaddr = 0x81fd9a08
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x023d9a08
++Cache set (0x81fd9000 --> 0x023d9000)
--MapMFN: Mapping mfn = 0x000023d9.
--PTLookup: lookup vaddr = 0x81fba5d8
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x023ba5d8
++Cache set (0x81fba000 --> 0x023ba000)
--MapMFN: Mapping mfn = 0x000023ba.
--PTLookup: lookup vaddr = 0x81fe46f0
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x023e46f0
++Cache set (0x81fe4000 --> 0x023e4000)
--MapMFN: Mapping mfn = 0x000023e4.
--PTLookup: lookup vaddr = 0x820ca3d0
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1080
--PTLookup: pgd = 0x00000000024001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x024ca3d0
++Cache set (0x820ca000 --> 0x024ca000)
--MapMFN: Mapping mfn = 0x000024ca.
++Cache hit (0x81fe7e28 --> 0x023e7e28, 0x023e7000)
--MapMFN: Mapping mfn = 0x000023e7.
--PTLookup: lookup vaddr = 0x81fc6a10
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x023c6a10
++Cache set (0x81fc6000 --> 0x023c6000)
--MapMFN: Mapping mfn = 0x000023c6.
--PTLookup: lookup vaddr = 0x81f1c3d8
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1078
--PTLookup: pgd = 0x00000000022001e3
--PTLookup: 2MB page
--PTLookup: paddr = 0x0231c3d8
++Cache set (0x81f1c000 --> 0x0231c000)
--MapMFN: Mapping mfn = 0x0000231c.
++Cache hit (0x81fd8250 --> 0x023d8250, 0x023d8000)
--MapMFN: Mapping mfn = 0x000023d8.
++Cache hit (0x820aad30 --> 0x024aad30, 0x024aa000)
--MapMFN: Mapping mfn = 0x000024aa.
++Cache hit (0x81fe70a8 --> 0x023e70a8, 0x023e7000)
--MapMFN: Mapping mfn = 0x000023e7.
++Cache hit (0x820bf3c0 --> 0x024bf3c0, 0x024bf000)
--MapMFN: Mapping mfn = 0x000024bf.
++Cache hit (0x81fbf0a8 --> 0x023bf0a8, 0x023bf000)
--MapMFN: Mapping mfn = 0x000023bf.
++Cache hit (0x81fd9a08 --> 0x023d9a08, 0x023d9000)
--MapMFN: Mapping mfn = 0x000023d9.
++Cache hit (0x81fba5d8 --> 0x023ba5d8, 0x023ba000)
--MapMFN: Mapping mfn = 0x000023ba.
++Cache hit (0x81fe46f0 --> 0x023e46f0, 0x023e4000)
--MapMFN: Mapping mfn = 0x000023e4.
++Cache hit (0x820ca3d0 --> 0x024ca3d0, 0x024ca000)
--MapMFN: Mapping mfn = 0x000024ca.
++Cache hit (0x81fe7e28 --> 0x023e7e28, 0x023e7000)
--MapMFN: Mapping mfn = 0x000023e7.
++Cache hit (0x81fc6a10 --> 0x023c6a10, 0x023c6000)
--MapMFN: Mapping mfn = 0x000023c6.
++Cache hit (0x81f1c3d8 --> 0x0231c3d8, 0x0231c000)
--MapMFN: Mapping mfn = 0x0000231c.
--UserVirt: pgd for pid=1732 is 0x860401c0.
--PTLookup: lookup vaddr = 0x7ffd9000
--PTLookup: cr3 = 0x860401c0
--PTLookup: pdpi_entry = 0x860401c8
--PTLookup: lookup vaddr = 0x860401c8
--PTLookup: cr3 = 0x806ee000
--PTLookup: pdpi_entry = 0x806ee010
--PTLookup: pdpe = 0x0000000000af1001
--PTLookup: pgd_entry = 0x00af1180
--PTLookup: pgd = 0x000000000262a163
--PTLookup: pte_entry = 0x0262a200
--MapMFN: Mapping mfn = 0x0000262a.
--PTLookup: pte = 0x0000000000000000
--PTLookup: paddr = 0x00000000
ERROR: address not in page table (0x860401c8)
--PTLookup: pdpe = 0x00000000b7fec000
ERROR: address not in page table (0x7ffd9000)
ERROR: could not find PEB struct for pid = 1732
failed to get process addresses from peb: Bad address

-----Original Message-----
From: Bryan D. Payne [mailto:br...@th...] 
Sent: Tuesday, January 22, 2008 10:06 AM
To: Matthew Donovan
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

>  WOOT!
>
> Ok, I know what is happening.

Cool... I'm glad that it's working.  I was just starting to to dig into this
deeper :-)


> For debugging purposes, I changed get_ntoskrnl_base() to go search 
> physical memory for the string "System", then go back 0x174 bytes and 
> look for 0x001b0003.  When I found that I knew the phyiscal address of 
> the EPROCESS block we're looking for: 0x25c8a00.  Using a kernel 
> debugger, I found that the virtual address of the EPROCESS block is 
> 0x821c8a00.  Subtract the numbers and the distance is 0x7fc00000, not 
> 0x80000000.  I changed
> init_page_offset() to reflect this and recompiled.  That worked and I 
> got the process list for my XP VM!
>
> I'm not sure what the 0x7fc00000 is though it looks familiar.  I think 
> I've come across it in my readings but I haven't found it yet.  Any ideas?

Interesting.  I'm not sure about this value.  Does everything else seem to
be working properly using that as the page offset?  If it is, in fact, the
right value.  Then I'll need to figure out how to determine the correct
value when bootstrapping xenaccess...


> A couple things to note:
>
> 1)  In get_ntoskrnl_base(), the while() loop only goes to 0x01000000 
> bytes of memory.  My VM has 512 MB and so I had to change the break 
> condition up to 0x20000000.  Is there a way to know how much memory a 
> VM has via an xc_ function?  (The xa_ code could always read the Xen 
> config file used to boot the VM.)

Good point.  I'll see about updating it so the search cutoff is based on the
physical memory size.


> 2)  The "magic" number 0x001b0003 won't work for Vista.  I haven't 
> done any rigorous checking, but on one process I have looked at, the 
> number would be 0x00000003.  (Again, I don't know yet if this is 
> consistent for all EPROCESS
> blocks.)

It doesn't surprise me that this number is different for Vista.
However, it does surprise me that you're seeing the number that you
mentioned.  The '1b' is a size / length field, so I would think that this
would not be set to '00'.  But, stranger things have happened.
I'll see if I can get Vista installed on my system one of these days to see
if my system looks the same as yours.  If so, then it's probably safe to
assume that we have found the proper magic number.

Thanks for keeping me updated, this is all very helpful...

-bryan


--
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center http://www.bryanpayne.org

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Bryan D. P. <br...@th...>]

>  WOOT!
>
> Ok, I know what is happening.

Cool... I'm glad that it's working.  I was just starting to to dig
into this deeper :-)


> For debugging purposes, I changed get_ntoskrnl_base() to go search physical
> memory for the string "System", then go back 0x174 bytes and look for
> 0x001b0003.  When I found that I knew the phyiscal address of the EPROCESS
> block we're looking for: 0x25c8a00.  Using a kernel debugger, I found that
> the virtual address of the EPROCESS block is 0x821c8a00.  Subtract the
> numbers and the distance is 0x7fc00000, not 0x80000000.  I changed
> init_page_offset() to reflect this and recompiled.  That worked and I got
> the process list for my XP VM!
>
> I'm not sure what the 0x7fc00000 is though it looks familiar.  I think I've
> come across it in my readings but I haven't found it yet.  Any ideas?

Interesting.  I'm not sure about this value.  Does everything else
seem to be working properly using that as the page offset?  If it is,
in fact, the right value.  Then I'll need to figure out how to
determine the correct value when bootstrapping xenaccess...


> A couple things to note:
>
> 1)  In get_ntoskrnl_base(), the while() loop only goes to 0x01000000 bytes
> of memory.  My VM has 512 MB and so I had to change the break condition up
> to 0x20000000.  Is there a way to know how much memory a VM has via an xc_
> function?  (The xa_ code could always read the Xen config file used to boot
> the VM.)

Good point.  I'll see about updating it so the search cutoff is based
on the physical memory size.


> 2)  The "magic" number 0x001b0003 won't work for Vista.  I haven't done any
> rigorous checking, but on one process I have looked at, the number would be
> 0x00000003.  (Again, I don't know yet if this is consistent for all EPROCESS
> blocks.)

It doesn't surprise me that this number is different for Vista.
However, it does surprise me that you're seeing the number that you
mentioned.  The '1b' is a size / length field, so I would think that
this would not be set to '00'.  But, stranger things have happened.
I'll see if I can get Vista installed on my system one of these days
to see if my system looks the same as yours.  If so, then it's
probably safe to assume that we have found the proper magic number.

Thanks for keeping me updated, this is all very helpful...

-bryan


-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Matthew D. <ma...@at...>]

 WOOT!

Ok, I know what is happening.

For debugging purposes, I changed get_ntoskrnl_base() to go search physical
memory for the string "System", then go back 0x174 bytes and look for
0x001b0003.  When I found that I knew the phyiscal address of the EPROCESS
block we're looking for: 0x25c8a00.  Using a kernel debugger, I found that
the virtual address of the EPROCESS block is 0x821c8a00.  Subtract the
numbers and the distance is 0x7fc00000, not 0x80000000.  I changed
init_page_offset() to reflect this and recompiled.  That worked and I got
the process list for my XP VM!

I'm not sure what the 0x7fc00000 is though it looks familiar.  I think I've
come across it in my readings but I haven't found it yet.  Any ideas?

A couple things to note:

1)  In get_ntoskrnl_base(), the while() loop only goes to 0x01000000 bytes
of memory.  My VM has 512 MB and so I had to change the break condition up
to 0x20000000.  Is there a way to know how much memory a VM has via an xc_
function?  (The xa_ code could always read the Xen config file used to boot
the VM.)

2)  The "magic" number 0x001b0003 won't work for Vista.  I haven't done any
rigorous checking, but on one process I have looked at, the number would be
0x00000003.  (Again, I don't know yet if this is consistent for all EPROCESS
blocks.)

-matthew

-----Original Message-----
From: Matthew Donovan [mailto:ma...@at...] 
Sent: Monday, January 21, 2008 2:03 PM
To: Bryan D. Payne
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

Oops.  Hit send before I was done writing.

In test_ntoskrnl_base(), this chunk returns the correct virtual address of
the _EPROCESS block.

    sysproc += base;	

    xa_read_long_phys(instance, sysproc, &sysproc);
    if (sysproc <= instance->page_offset){
        return XA_FAILURE;
    }

 
The virtual-to-physical address translation isn't right (I guess) because
the returned header value is zero:

    sysproc -= instance->page_offset;

    /* sysproc should now be the PA of a an EPROCESS location */
    xa_read_long_phys(instance, sysproc, &header);
    
    /* Test for EPROCESS using technique from 'Searching for Processes
       and Threads in Microsoft Windows memory dumps' in DFRWS 2006 */
    if (header != 0x001b0003){ /* this number is different on Vista */
        return XA_FAILURE;
    }


We tried turning off PAE in hopes that it would also turn off PSE.  No such
luck.  However, I wrote a program that checks if PSE is enabled (using the
CPUID instruction) in the guest and it reports that it isn't. 

I see in your code that you use xc_vcpu_getcontext() and then check if a bit
is set in CR4.  I'm still having some problems knowing where the line
between VM and host is.  Should the CR4 register report the same as the
CPUID instruction?  From what I've read from the Xen mailing lists, I'm
assuming that if the guest doesn't see PSE enabled, then the page size is
always 4KB.  Is that a correct assumption?  Do you know how I could just
turn PSE off completely?

I'm not really sure what else to try here and any further suggestions would
be great.

Thanks
-matthew


-----Original Message-----
From: Matthew Donovan
Sent: Monday, January 21, 2008 1:50 PM
To: 'Bryan D. Payne'
Cc: xen...@li...
Subject: RE: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

Hi Bryan,

I think I have the problem pretty well narrowed down.  Perhaps you can shed
some light on what I'm seeing.

The code is breaking in test_ntoskrnl_base().  Using WinDbg in the Windows
VM, I verified that we are getting the correct virtual address of the
_EPROCESS block for the System process.


-----Original Message-----
From: Bryan D. Payne [mailto:br...@th...]
Sent: Thursday, January 17, 2008 3:43 PM
To: Matthew Donovan
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

One more thought.  I just had another look at your debug output.  It looks
like it is failing in the get_ntoskrnl_base function (located in
windows_memory.c), because there is no evidence that it found the kernel
image.  Normally you would see something like:

--got ntoskrnl (0x004d7000)

This function would fail if it had the wrong offset for
PsInitialSystemProcess (but it sounds like you have tried all kinds of
options for that, since this is read from the exports file), if the kernel
image did not start at the top of the mapped page (which is conceivable for
PSE), or if we were just having trouble reading memory from the VM.  You
might try adding additional debugging code within this function (and its
helper, test_ntoskrnl_base) to see exactly where it's failing.

-bryan


On Jan 17, 2008 2:27 PM, Matthew Donovan <ma...@at...> wrote:
> Thanks for the pointers.
>
> I think I've exhausted all combinations of option 1 with no success.  
> The extra output (= _Symbol@X) shows some linking information (calling 
> convention and total size of arguments in bytes) and was caused by 
> dumpbin.exe.  I used the version that came with Visual Studio 2008; an 
> older version of dumpbin doesn't produce it.  I generated export files 
> for both kernels (pae and non-paw) and stipped out the extra stuff.  
> Still
no go.
>
> I guess I'll move on to option 2.
>
> -matthew
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
XenAccess-devel mailing list
Xen...@li...
https://lists.sourceforge.net/lists/listinfo/xenaccess-devel

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Matthew D. <ma...@at...>]

Oops.  Hit send before I was done writing.

In test_ntoskrnl_base(), this chunk returns the correct virtual address of
the _EPROCESS block.

    sysproc += base;	

    xa_read_long_phys(instance, sysproc, &sysproc);
    if (sysproc <= instance->page_offset){
        return XA_FAILURE;
    }

 
The virtual-to-physical address translation isn't right (I guess) because
the returned header value is zero:

    sysproc -= instance->page_offset;

    /* sysproc should now be the PA of a an EPROCESS location */
    xa_read_long_phys(instance, sysproc, &header);
    
    /* Test for EPROCESS using technique from 'Searching for Processes
       and Threads in Microsoft Windows memory dumps' in DFRWS 2006 */
    if (header != 0x001b0003){ /* this number is different on Vista */
        return XA_FAILURE;
    }


We tried turning off PAE in hopes that it would also turn off PSE.  No such
luck.  However, I wrote a program that checks if PSE is enabled (using the
CPUID instruction) in the guest and it reports that it isn't. 

I see in your code that you use xc_vcpu_getcontext() and then check if a bit
is set in CR4.  I'm still having some problems knowing where the line
between VM and host is.  Should the CR4 register report the same as the
CPUID instruction?  From what I've read from the Xen mailing lists, I'm
assuming that if the guest doesn't see PSE enabled, then the page size is
always 4KB.  Is that a correct assumption?  Do you know how I could just
turn PSE off completely?

I'm not really sure what else to try here and any further suggestions would
be great.

Thanks
-matthew


-----Original Message-----
From: Matthew Donovan 
Sent: Monday, January 21, 2008 1:50 PM
To: 'Bryan D. Payne'
Cc: xen...@li...
Subject: RE: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

Hi Bryan,

I think I have the problem pretty well narrowed down.  Perhaps you can shed
some light on what I'm seeing.

The code is breaking in test_ntoskrnl_base().  Using WinDbg in the Windows
VM, I verified that we are getting the correct virtual address of the
_EPROCESS block for the System process.


-----Original Message-----
From: Bryan D. Payne [mailto:br...@th...]
Sent: Thursday, January 17, 2008 3:43 PM
To: Matthew Donovan
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

One more thought.  I just had another look at your debug output.  It looks
like it is failing in the get_ntoskrnl_base function (located in
windows_memory.c), because there is no evidence that it found the kernel
image.  Normally you would see something like:

--got ntoskrnl (0x004d7000)

This function would fail if it had the wrong offset for
PsInitialSystemProcess (but it sounds like you have tried all kinds of
options for that, since this is read from the exports file), if the kernel
image did not start at the top of the mapped page (which is conceivable for
PSE), or if we were just having trouble reading memory from the VM.  You
might try adding additional debugging code within this function (and its
helper, test_ntoskrnl_base) to see exactly where it's failing.

-bryan


On Jan 17, 2008 2:27 PM, Matthew Donovan <ma...@at...> wrote:
> Thanks for the pointers.
>
> I think I've exhausted all combinations of option 1 with no success.  
> The extra output (= _Symbol@X) shows some linking information (calling 
> convention and total size of arguments in bytes) and was caused by 
> dumpbin.exe.  I used the version that came with Visual Studio 2008; an 
> older version of dumpbin doesn't produce it.  I generated export files 
> for both kernels (pae and non-paw) and stipped out the extra stuff.  Still
no go.
>
> I guess I'll move on to option 2.
>
> -matthew
>

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Matthew D. <ma...@at...>]

Hi Bryan,

I think I have the problem pretty well narrowed down.  Perhaps you can shed
some light on what I'm seeing.

The code is breaking in test_ntoskrnl_base().  Using WinDbg in the Windows
VM, I verified that we are getting the correct virtual address of the
_EPROCESS block for the System process.


-----Original Message-----
From: Bryan D. Payne [mailto:br...@th...] 
Sent: Thursday, January 17, 2008 3:43 PM
To: Matthew Donovan
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

One more thought.  I just had another look at your debug output.  It looks
like it is failing in the get_ntoskrnl_base function (located in
windows_memory.c), because there is no evidence that it found the kernel
image.  Normally you would see something like:

--got ntoskrnl (0x004d7000)

This function would fail if it had the wrong offset for
PsInitialSystemProcess (but it sounds like you have tried all kinds of
options for that, since this is read from the exports file), if the kernel
image did not start at the top of the mapped page (which is conceivable for
PSE), or if we were just having trouble reading memory from the VM.  You
might try adding additional debugging code within this function (and its
helper, test_ntoskrnl_base) to see exactly where it's failing.

-bryan


On Jan 17, 2008 2:27 PM, Matthew Donovan <ma...@at...> wrote:
> Thanks for the pointers.
>
> I think I've exhausted all combinations of option 1 with no success.  
> The extra output (= _Symbol@X) shows some linking information (calling 
> convention and total size of arguments in bytes) and was caused by 
> dumpbin.exe.  I used the version that came with Visual Studio 2008; an 
> older version of dumpbin doesn't produce it.  I generated export files 
> for both kernels (pae and non-paw) and stipped out the extra stuff.  Still
no go.
>
> I guess I'll move on to option 2.
>
> -matthew
>

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Bryan D. P. <br...@th...>]

One more thought.  I just had another look at your debug output.  It
looks like it is failing in the get_ntoskrnl_base function (located in
windows_memory.c), because there is no evidence that it found the
kernel image.  Normally you would see something like:

--got ntoskrnl (0x004d7000)

This function would fail if it had the wrong offset for
PsInitialSystemProcess (but it sounds like you have tried all kinds of
options for that, since this is read from the exports file), if the
kernel image did not start at the top of the mapped page (which is
conceivable for PSE), or if we were just having trouble reading memory
from the VM.  You might try adding additional debugging code within
this function (and its helper, test_ntoskrnl_base) to see exactly
where it's failing.

-bryan


On Jan 17, 2008 2:27 PM, Matthew Donovan <ma...@at...> wrote:
> Thanks for the pointers.
>
> I think I've exhausted all combinations of option 1 with no success.  The
> extra output (= _Symbol@X) shows some linking information (calling
> convention and total size of arguments in bytes) and was caused by
> dumpbin.exe.  I used the version that came with Visual Studio 2008; an older
> version of dumpbin doesn't produce it.  I generated export files for both
> kernels (pae and non-paw) and stipped out the extra stuff.  Still no go.
>
> I guess I'll move on to option 2.
>
> -matthew
>

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Matthew D. <ma...@at...>]

Thanks for the pointers.

I think I've exhausted all combinations of option 1 with no success.  The
extra output (= _Symbol@X) shows some linking information (calling
convention and total size of arguments in bytes) and was caused by
dumpbin.exe.  I used the version that came with Visual Studio 2008; an older
version of dumpbin doesn't produce it.  I generated export files for both
kernels (pae and non-paw) and stipped out the extra stuff.  Still no go.  

I guess I'll move on to option 2.

-matthew

-----Original Message-----
From: Bryan D. Payne [mailto:br...@th...] 
Sent: Thursday, January 17, 2008 10:11 AM
To: Matthew Donovan
Cc: xen...@li...
Subject: Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

Matthew,

Welcome to the list.  I have a few thoughts for you to explore...

(1)  My best guess is that you are using the wrong windows "sysmap"
file.  Of course, it is not really a sysmap file for windows but it does
have critical offset information.  And, while the snippet that you showed
appears to be close to the right format (the extra "= xxx"
and the end of each line looks weird to me), I would question if it is the
correct information.  Specifically, these data will be different for PAE and
non-PAE kernels.  Here's how to get the file:

(non-PAE)  dumpbin /exports c:\windows\system32\ntoskrnl.exe

(PAE)  dumpbin /exports c:\windows\system32\ntkrnlpa.exe

Just save the output of these commands to a file and use that for the
"sysmap".  As an example, the files for my version of Windows XP SP2 are
provided under the notes directory in subversion.

(2)  I noticed in the debug output that your version of windows is using
PSE.  My setup at this end does not use that, so it is likely that there are
bugs in the PSE support mechanism.  If (1) doesn't fix your problem, I would
look into this next.

(3)  Finally, you are using Xen 3.1.2.  This *should* work with HVM domains,
but I haven't had time to work out all the kinks in supported Xen 3.1.x.  So
it's possible that there is some weird bug that you are triggering.
Although I think that (1) and (2) are more likely.

Also, it's worth noting that I haven't played with Vista yet.  I imagine
that it will "just work" if you get the right offsets and exports file.
But, you'll be charting new territory there.  Let me know how that goes as
I'd be very interested in knowing if it works!

Cheers,
bryan



On Jan 17, 2008 9:36 AM, Matthew Donovan <ma...@at...> wrote:
> Hi,
>
> I'm trying to get the Xenaccess examples working with Windows.  I 
> ultimately want to use it with Vista but for a first step I'd be happy 
> to get it working with XP SP2.  When I try to run the process-list and 
> module-list examples on Vista or XP, it fails during initialization 
> with "failed to init XenAccess library: Bad address".  (The full 
> output is below.)
>
> For Vista, I changed the constants in process-list.c to be appropriate 
> (determined using windbg).
> For XP I just used the constants that were already there and verified 
> they were correct.
>
> I talked with Jim (I've just started on the project) and he showed me 
> a Windows sysmap(?) file.  I included part of that just so you can 
> tell me if I got the format right.  I assume it's OK since there isn't 
> an error looking up PsInitialSystemProcess.
>
> I'm using Xen 3.1.2 and XenAccess 0.4 on Fedora Core 8.
>
> I'm not really sure what to try next.
>
> Thanks for the help.
> -matthew
>
>
> XENACCESS.CONF:
> winvista {
>         sysmap          ="/root/libxa/winvista-exports.txt";
>         ostype          = "Windows";
>         win_tasks       = 0xa0;
>         win_pdbase      = 0x18;
>         win_pid         = 0x9c;
>         win_peb         = 0x188;
>         win_iba         = 0x8;
>         win_ph          = 0x18;
> }
>
> winxp0 {
>         sysmap          ="/root/libxa/winxp-exports.txt";
>         ostype          = "Windows";
>         win_tasks       = 0x88;
>         win_pdbase      = 0x18;
>         win_pid         = 0x84;
>         win_peb         = 0x1b0;
>         win_iba         = 0x8;
>         win_ph          = 0x18;
> }
>
> SYSMAP (?) SNIPPET:
>          94    0 000CA3D3 AlpcGetHeaderSize = _AlpcGetHeaderSize@4
>          95    1 000CA451 AlpcGetMessageAttribute =
> _AlpcGetMessageAttribute@8
>          96    2 000CA414 AlpcInitializeMessageAttribute =
> _AlpcInitializeMessageAttribute@16
>          97    3 0003273E CcCanIWrite = _CcCanIWrite@16
>          98    4 001D7530 CcCopyRead = _CcCopyRead@24
>
>
>
> PROCESS-LIST OUTPUT FOR XP VM:
>
> XenAccess Version 0.4
> --got domain info.
> **set instance->xen_version = 3.1.0
> --got domain name from id (4 ==> winxp0).
>      1 |winvista {
>      2 |        sysmap          ="/root/libxa/winvista-exports.txt";
>      3 |        ostype          = "Windows";
>      4 |        win_tasks       = 0xa0;
>      5 |        win_pdbase      = 0x18;
>      6 |        win_pid         = 0x9c;
>      7 |        win_peb         = 0x188;
>      8 |        win_iba         = 0x8;
>      9 |        win_ph          = 0x18;
>     10 |}
>     11 |
>     12 |winxp0 {
>     13 |        sysmap          ="/root/libxa/winxp-exports.txt";
>     14 |        ostype          = "Windows";
>     15 |        win_tasks       = 0x88;
>     16 |        win_pdbase      = 0x18;
>     17 |        win_pid         = 0x84;
>     18 |        win_peb         = 0x1b0;
>     19 |        win_iba         = 0x8;
>     20 |        win_ph          = 0x18;
>     21 |}
>     22 |
> --got sysmap from config (/root/libxa/winxp-exports.txt).
> --reading in windows offsets from config file.
> --got ostype from config (Windows).
> **set instance->os_type to Windows.
> **set instance->pae = 1
> **set instance->pse = 1
> --got memory layout.
> **set instance->hvm to true (HVM).
> --MapPFN: Mapping mfn = 1.
> --MapPFN: Mapping mfn = 2.
> --MapPFN: Mapping mfn = 3.
> --MapPFN: Mapping mfn = 4.
> --MapPFN: Mapping mfn = 5.
> --MapPFN: Mapping mfn = 6.
> --MapPFN: Mapping mfn = 7.
> --MapPFN: Mapping mfn = 8.
> <snip>
> --MapPFN: Mapping mfn = 4093.
> --MapPFN: Mapping mfn = 4094.
> --MapPFN: Mapping mfn = 4095.
> failed to init XenAccess library: Bad address
>
>
>
> ----------------------------------------------------------------------
> --- This SF.net email is sponsored by: Microsoft Defy all challenges. 
> Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> XenAccess-devel mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenaccess-devel
>



--
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center http://www.bryanpayne.org

Re: [XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Bryan D. P. <br...@th...>]

Matthew,

Welcome to the list.  I have a few thoughts for you to explore...

(1)  My best guess is that you are using the wrong windows "sysmap"
file.  Of course, it is not really a sysmap file for windows but it
does have critical offset information.  And, while the snippet that
you showed appears to be close to the right format (the extra "= xxx"
and the end of each line looks weird to me), I would question if it is
the correct information.  Specifically, these data will be different
for PAE and non-PAE kernels.  Here's how to get the file:

(non-PAE)  dumpbin /exports c:\windows\system32\ntoskrnl.exe

(PAE)  dumpbin /exports c:\windows\system32\ntkrnlpa.exe

Just save the output of these commands to a file and use that for the
"sysmap".  As an example, the files for my version of Windows XP SP2
are provided under the notes directory in subversion.

(2)  I noticed in the debug output that your version of windows is
using PSE.  My setup at this end does not use that, so it is likely
that there are bugs in the PSE support mechanism.  If (1) doesn't fix
your problem, I would look into this next.

(3)  Finally, you are using Xen 3.1.2.  This *should* work with HVM
domains, but I haven't had time to work out all the kinks in supported
Xen 3.1.x.  So it's possible that there is some weird bug that you are
triggering.  Although I think that (1) and (2) are more likely.

Also, it's worth noting that I haven't played with Vista yet.  I
imagine that it will "just work" if you get the right offsets and
exports file.  But, you'll be charting new territory there.  Let me
know how that goes as I'd be very interested in knowing if it works!

Cheers,
bryan



On Jan 17, 2008 9:36 AM, Matthew Donovan <ma...@at...> wrote:
> Hi,
>
> I'm trying to get the Xenaccess examples working with Windows.  I ultimately
> want to use it with Vista but for a first step I'd be happy to get it
> working with XP SP2.  When I try to run the process-list and module-list
> examples on Vista or XP, it fails during initialization with "failed to init
> XenAccess library: Bad address".  (The full output is below.)
>
> For Vista, I changed the constants in process-list.c to be appropriate
> (determined using windbg).
> For XP I just used the constants that were already there and verified they
> were correct.
>
> I talked with Jim (I've just started on the project) and he showed me a
> Windows sysmap(?) file.  I included part of that just so you can tell me if
> I got the format right.  I assume it's OK since there isn't an error looking
> up PsInitialSystemProcess.
>
> I'm using Xen 3.1.2 and XenAccess 0.4 on Fedora Core 8.
>
> I'm not really sure what to try next.
>
> Thanks for the help.
> -matthew
>
>
> XENACCESS.CONF:
> winvista {
>         sysmap          ="/root/libxa/winvista-exports.txt";
>         ostype          = "Windows";
>         win_tasks       = 0xa0;
>         win_pdbase      = 0x18;
>         win_pid         = 0x9c;
>         win_peb         = 0x188;
>         win_iba         = 0x8;
>         win_ph          = 0x18;
> }
>
> winxp0 {
>         sysmap          ="/root/libxa/winxp-exports.txt";
>         ostype          = "Windows";
>         win_tasks       = 0x88;
>         win_pdbase      = 0x18;
>         win_pid         = 0x84;
>         win_peb         = 0x1b0;
>         win_iba         = 0x8;
>         win_ph          = 0x18;
> }
>
> SYSMAP (?) SNIPPET:
>          94    0 000CA3D3 AlpcGetHeaderSize = _AlpcGetHeaderSize@4
>          95    1 000CA451 AlpcGetMessageAttribute =
> _AlpcGetMessageAttribute@8
>          96    2 000CA414 AlpcInitializeMessageAttribute =
> _AlpcInitializeMessageAttribute@16
>          97    3 0003273E CcCanIWrite = _CcCanIWrite@16
>          98    4 001D7530 CcCopyRead = _CcCopyRead@24
>
>
>
> PROCESS-LIST OUTPUT FOR XP VM:
>
> XenAccess Version 0.4
> --got domain info.
> **set instance->xen_version = 3.1.0
> --got domain name from id (4 ==> winxp0).
>      1 |winvista {
>      2 |        sysmap          ="/root/libxa/winvista-exports.txt";
>      3 |        ostype          = "Windows";
>      4 |        win_tasks       = 0xa0;
>      5 |        win_pdbase      = 0x18;
>      6 |        win_pid         = 0x9c;
>      7 |        win_peb         = 0x188;
>      8 |        win_iba         = 0x8;
>      9 |        win_ph          = 0x18;
>     10 |}
>     11 |
>     12 |winxp0 {
>     13 |        sysmap          ="/root/libxa/winxp-exports.txt";
>     14 |        ostype          = "Windows";
>     15 |        win_tasks       = 0x88;
>     16 |        win_pdbase      = 0x18;
>     17 |        win_pid         = 0x84;
>     18 |        win_peb         = 0x1b0;
>     19 |        win_iba         = 0x8;
>     20 |        win_ph          = 0x18;
>     21 |}
>     22 |
> --got sysmap from config (/root/libxa/winxp-exports.txt).
> --reading in windows offsets from config file.
> --got ostype from config (Windows).
> **set instance->os_type to Windows.
> **set instance->pae = 1
> **set instance->pse = 1
> --got memory layout.
> **set instance->hvm to true (HVM).
> --MapPFN: Mapping mfn = 1.
> --MapPFN: Mapping mfn = 2.
> --MapPFN: Mapping mfn = 3.
> --MapPFN: Mapping mfn = 4.
> --MapPFN: Mapping mfn = 5.
> --MapPFN: Mapping mfn = 6.
> --MapPFN: Mapping mfn = 7.
> --MapPFN: Mapping mfn = 8.
> <snip>
> --MapPFN: Mapping mfn = 4093.
> --MapPFN: Mapping mfn = 4094.
> --MapPFN: Mapping mfn = 4095.
> failed to init XenAccess library: Bad address
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> XenAccess-devel mailing list
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenaccess-devel
>



-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

[XenAccess-devel] Xenaccess examples with Windows XP/Vista

[Matthew D. <ma...@at...>]

Hi,

I'm trying to get the Xenaccess examples working with Windows.  I ultimately
want to use it with Vista but for a first step I'd be happy to get it
working with XP SP2.  When I try to run the process-list and module-list
examples on Vista or XP, it fails during initialization with "failed to init
XenAccess library: Bad address".  (The full output is below.)

For Vista, I changed the constants in process-list.c to be appropriate
(determined using windbg).
For XP I just used the constants that were already there and verified they
were correct.

I talked with Jim (I've just started on the project) and he showed me a
Windows sysmap(?) file.  I included part of that just so you can tell me if
I got the format right.  I assume it's OK since there isn't an error looking
up PsInitialSystemProcess.

I'm using Xen 3.1.2 and XenAccess 0.4 on Fedora Core 8.

I'm not really sure what to try next.

Thanks for the help.
-matthew


XENACCESS.CONF:
winvista {
	sysmap		="/root/libxa/winvista-exports.txt";
	ostype 		= "Windows";
	win_tasks	= 0xa0;
	win_pdbase	= 0x18;
	win_pid		= 0x9c;
	win_peb		= 0x188;
	win_iba		= 0x8;
        win_ph          = 0x18;
}

winxp0 {
	sysmap		="/root/libxa/winxp-exports.txt";
	ostype 		= "Windows";
	win_tasks	= 0x88;
	win_pdbase	= 0x18;
	win_pid		= 0x84;
	win_peb		= 0x1b0;
	win_iba		= 0x8;
        win_ph          = 0x18;
}

SYSMAP (?) SNIPPET:
         94    0 000CA3D3 AlpcGetHeaderSize = _AlpcGetHeaderSize@4
         95    1 000CA451 AlpcGetMessageAttribute =
_AlpcGetMessageAttribute@8
         96    2 000CA414 AlpcInitializeMessageAttribute =
_AlpcInitializeMessageAttribute@16
         97    3 0003273E CcCanIWrite = _CcCanIWrite@16
         98    4 001D7530 CcCopyRead = _CcCopyRead@24



PROCESS-LIST OUTPUT FOR XP VM:

XenAccess Version 0.4
--got domain info.
**set instance->xen_version = 3.1.0
--got domain name from id (4 ==> winxp0).
     1 |winvista {
     2 |	sysmap		="/root/libxa/winvista-exports.txt";
     3 |	ostype 		= "Windows";
     4 |	win_tasks	= 0xa0;
     5 |	win_pdbase	= 0x18;
     6 |	win_pid		= 0x9c;
     7 |	win_peb		= 0x188;
     8 |	win_iba		= 0x8;
     9 |        win_ph          = 0x18;
    10 |}
    11 |
    12 |winxp0 {
    13 |	sysmap		="/root/libxa/winxp-exports.txt";
    14 |	ostype 		= "Windows";
    15 |	win_tasks	= 0x88;
    16 |	win_pdbase	= 0x18;
    17 |	win_pid		= 0x84;
    18 |	win_peb		= 0x1b0;
    19 |	win_iba		= 0x8;
    20 |        win_ph          = 0x18;
    21 |}
    22 |
--got sysmap from config (/root/libxa/winxp-exports.txt).
--reading in windows offsets from config file.
--got ostype from config (Windows).
**set instance->os_type to Windows.
**set instance->pae = 1
**set instance->pse = 1
--got memory layout.
**set instance->hvm to true (HVM).
--MapPFN: Mapping mfn = 1.
--MapPFN: Mapping mfn = 2.
--MapPFN: Mapping mfn = 3.
--MapPFN: Mapping mfn = 4.
--MapPFN: Mapping mfn = 5.
--MapPFN: Mapping mfn = 6.
--MapPFN: Mapping mfn = 7.
--MapPFN: Mapping mfn = 8.
<snip>
--MapPFN: Mapping mfn = 4093.
--MapPFN: Mapping mfn = 4094.
--MapPFN: Mapping mfn = 4095.
failed to init XenAccess library: Bad address

[XenAccess-devel] Page mapping protections

[<hi...@cc...>]

Hi Bryan,

Although the individual mapping functions accept page protection arguments,
none of the public functions allows for anything but PROT_READ access.
There are reasons, however, for allowing PROT_WRITE (or even  
PROT_EXEC) access.
Perhaps the most general reason is lock grabbing.  For example,  
doesn't walking
the process list require a lock?  I think it's incorrect to iterate over the
tasks list without holding a lock (although the probability of generating an
incorrect list is apparently very low).

I would like some of the public functions, like xa_access_virtual* to  
include arguments for page protections.

What is your opinion?

-Jim

Re: [XenAccess-devel] XenAccess 0.4 HVM regression

[<hi...@cc...>]

Sorry.

Please ignore the last message.  I had forgotten I let the software
updater run and neglected to notice that it upgraded the kernel.

-Jim


Quoting "Bryan D. Payne" <br...@th...>:

> Hmmm, that's not good.  You mentioned that these worked before your
> svn update.  Can you provide the version number of the working code
> and the version number of the code that is not working (subversion
> repository version)?  This should help me get to the root of the
> problem pretty quickly.  Also, could you include the configuration
> file that you are using?

[XenAccess-devel] XenAccess 0.4 HVM regression

[<hi...@cc...>]

XenAccess is having problems with HVM with version 0.4.

No examples currently work:

[root@easy-mark examples]# ./module-list 1
ERROR: address not in page table (0xc02be7a0)
ERROR: failed to get task list head 'init_task'
failed to init XenAccess library: Success
[root@easy-mark examples]# ./process-list 1
ERROR: address not in page table (0xc02be7a0)
ERROR: failed to get task list head 'init_task'
failed to init XenAccess library: Success
[root@easy-mark examples]#

These worked before my svn update.  Any ideas about
where I should look?

-Jim

[XenAccess-devel] XenAccess 0.4 Released

[Bryan D. P. <br...@th...>]

XenAccess version 0.4 is now available!  This release includes lots of
new features including support for Windows domains, new API functions,
support for PAE memory addressing, new example code, improved cache
performance, improved debug output, and much more.  You can download
this release from SourceForge (see link below).  Also, be sure to read
through the much improved documentation to get up and running quickly.

http://xenaccess.sourceforge.net/

Enjoy,
-bryan


-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

Re: [XenAccess-devel] What's allocated on top 1M region of domU?

[Bryan D. P. <br...@th...>]

> Though I mean pseudo physical memory, this answer is correct?
> #I know xen is replaced on virtual address space of DomU.

Ahh yes, this is just for the virtual address spaces.  I'm not sure
what you would be seeing at the top of the physical address space,
unless that just happens to be how Xen implements its location in the
domain.  I'd have to poke through the Xen source code to know for
sure...


> Ok. If your answer is what I intended, top 1M region problem is solved.
> But there are some bit regions I can't access. What are they?
> #some regions can't be accessed continuously and some regions can't be
> accessed often.
> #incidentally, I access to domU while it being paused.

It is possible that there are regions of physical memory that you
won't always be able to access.  This is likely very dependent on your
system, but I can imagine you seeing this type of behavior when memory
is swapped to disk, for example.  If you can find the page table
entries associated with these "missing" pieces of memory, you can
check the flags in the PTE and probably learn more about why the
memory is not there.

Just scanning through all physical addresses offers no guarantee that
you will be able to access every page.  This is one reason why it is
usually more useful to access memory via virtual address instead of
physical address.

-bryan


-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

Re: [XenAccess-devel] What's allocated on top 1M region of domU?

[Ryo K. <kan...@hp...>]

very very thanks Bryan :-)
#I've tried to find a answer of this question for a week.

>> Now, I'm succeeded read and writing almost of the memory. But
>> It fails when I try to access top 1M region and some bit regions.
>> To be precise, xc_map_foreign_range() of libxc returns error code 14.
>>     
>
> This is where Xen locates itself.  So that would explain why it is not
> letting you map it.  The rest of the guest memory should be laid out
> as you would expect for whatever operating system you are looking at.
>
>   
Though I mean pseudo physical memory, this answer is correct?
#I know xen is replaced on virtual address space of DomU.

Ok. If your answer is what I intended, top 1M region problem is solved.
But there are some bit regions I can't access. What are they?
#some regions can't be accessed continuously and some regions can't be 
accessed often.
#incidentally, I access to domU while it being paused.

<javascript:goWordLink("incidentally")>
>> #and , Can I get a document about memory allocation of dom0 and DomU
>> somewhere?
>>     
>
> I'm not sure if I understand this question.  If you are curious about
> how Xen allocates the memory, then I don't know of any good
> documentation on that.  If you are curious about how the guest OS uses
> its memory, then you can check out a reference book about the
> operating system (e.g., Windows Internals or Understanding the Linux
> Kernel).
>
>   
I meant the former.
thank you for your suggestion :-)



regards.

****************************************
HPCS lab
4th grade student of Colledge of Information Science, University of Tsukuba

Ryo Kanbayashi

Re: [XenAccess-devel] What's allocated on top 1M region of domU?

[Bryan D. P. <br...@th...>]

> Now, I'm succeeded read and writing almost of the memory. But
> It fails when I try to access top 1M region and some bit regions.
> To be precise, xc_map_foreign_range() of libxc returns error code 14.

This is where Xen locates itself.  So that would explain why it is not
letting you map it.  The rest of the guest memory should be laid out
as you would expect for whatever operating system you are looking at.


> #and , Can I get a document about memory allocation of dom0 and DomU
> somewhere?

I'm not sure if I understand this question.  If you are curious about
how Xen allocates the memory, then I don't know of any good
documentation on that.  If you are curious about how the guest OS uses
its memory, then you can check out a reference book about the
operating system (e.g., Windows Internals or Understanding the Linux
Kernel).

-bryan


-- 
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

[XenAccess-devel] What's allocated on top 1M region of domU?

[Ryo K. <kan...@hp...>]

Hi all.

I'm now try to read and write puseud physical memory of domU from Dom0
with xa_access_physical_address() using my snippet code(phys-access-from-head.c).
#for writ access, I modified xa_access_physical_address to access memory with PROT_WRITE flag.

Now, I'm succeeded read and writing almost of the memory. But
It fails when I try to access top 1M region and some bit regions.
To be precise, xc_map_foreign_range() of libxc returns error code 14.

What's allocated on top 1M region of domU?
#and , Can I get a document about memory allocation of dom0 and DomU
somewhere?

regards.


---environment----
xen: Xen 3.1.0
xenaccess: head revision of subversion repository
processor type: 32bit PAE
Entire Memory: 2G

DomU type: paravirtualized
DomU Memory size: 512M

---using snippet---
#2 is DomU domain number, 0x0c000000 is arbitrary address accessible
./phys-access-from-head.out 2 0x0c000000

****************************************
HPCS lab
4th grade student of Colledge of Information Science, University of Tsukuba

Ryo Kanbayashi


-- 
****************************************
筑波大学第三学群情報学類4年　
HPCS研究室

神林　亮