xenaccess-devel Mailing List for XenAccess Library (Page 2)
Status: Beta
Brought to you by:
bdpayne
Menu
▾
▴
xenaccess-devel — General list for all technical issues related to the XenAccess Library
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(6) |
Jul
(21) |
Aug
(13) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(13) |
Sep
|
Oct
|
Nov
(4) |
Dec
(8) |
| 2008 |
Jan
(14) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bryan D. P. <br...@th...> - 2007-11-29 20:48:59
|
Thanks. The patch is now in the repository.
-bryan
On Nov 29, 2007 2:41 PM, <hi...@cc...> wrote:
> Here's a small patch that adds xa_symbol_to_address
> to the public API. It simply redirects to the appropriate
> symbol translation functions in the linux and windows
> layers.
>
> There are times when I want to know the address of a
> symbol without mapping it.
>
> -Jim
>
> Index: xa_util.c
> ===================================================================
> --- xa_util.c (revision 99)
> +++ xa_util.c (working copy)
> @@ -163,6 +163,17 @@
> }
> }
>
> +int xa_symbol_to_address (
> + xa_instance_t* instance, char* sym, uint32_t* vaddr)
> +{
> + if(XA_OS_LINUX == instance->os_type)
> + return linux_system_map_symbol_to_address(instance,
> sym, vaddr);
> + else if(XA_OS_WINDOWS == instance->os_type)
> + return windows_symbol_to_address(instance, sym, vaddr);
> + else
> + return XA_FAILURE;
> +}
> +
> int xa_get_bit (unsigned long reg, int bit)
> {
> unsigned long mask = 1 << bit;
> Index: xenaccess.h
> ===================================================================
> --- xenaccess.h (revision 99)
> +++ xenaccess.h (working copy)
> @@ -334,6 +334,16 @@
> int xa_read_long_long_mach (
> xa_instance_t *instance, uint32_t maddr, uint64_t *value);
>
> +/**
> + * Returns the address of a symbol.
> + *
> + * @param[in] instance XenAccess instance
> + * @param[in] sym Kernel symbol (must be exported)
> + * @param[out] vaddr The virtual address of the symbol
> + */
> +int xa_symbol_to_address (
> + xa_instance_t *instance, char* sym, uint32_t *vaddr);
> +
> /*-----------------------------
> * Linux-specific functionality
> */
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> 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
|
|
From: <hi...@cc...> - 2007-11-29 19:41:46
|
Here's a small patch that adds xa_symbol_to_address
to the public API. It simply redirects to the appropriate
symbol translation functions in the linux and windows
layers.
There are times when I want to know the address of a
symbol without mapping it.
-Jim
Index: xa_util.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xa_util.c (revision 99)
+++ xa_util.c (working copy)
@@ -163,6 +163,17 @@
}
}
+int xa_symbol_to_address (
+ xa_instance_t* instance, char* sym, uint32_t* vaddr)
+{
+ if(XA_OS_LINUX =3D=3D instance->os_type)
+ return linux_system_map_symbol_to_address(instance, =20
sym, vaddr);
+ else if(XA_OS_WINDOWS =3D=3D instance->os_type)
+ return windows_symbol_to_address(instance, sym, vaddr);
+ else
+ return XA_FAILURE;
+}
+
int xa_get_bit (unsigned long reg, int bit)
{
unsigned long mask =3D 1 << bit;
Index: xenaccess.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xenaccess.h (revision 99)
+++ xenaccess.h (working copy)
@@ -334,6 +334,16 @@
int xa_read_long_long_mach (
xa_instance_t *instance, uint32_t maddr, uint64_t *value);
+/**
+ * Returns the address of a symbol.
+ *
+ * @param[in] instance XenAccess instance
+ * @param[in] sym Kernel symbol (must be exported)
+ * @param[out] vaddr The virtual address of the symbol
+ */
+int xa_symbol_to_address (
+ xa_instance_t *instance, char* sym, uint32_t *vaddr);
+
/*-----------------------------
* Linux-specific functionality
*/
|
|
From: Bryan D. P. <br...@th...> - 2007-11-05 20:26:59
|
> I would very much like to be able to mmap multiple pages > in xenaccess. I believe this is possible using the same > function xenaccess employs, xc_map_foreign_range, and > changing the argument for size. > > However, this function seems to have very strange failure > semantics, since some pages in a range sometimes cannot > be mapped. Does anybody understand how partial failures > work with this function? I haven't played with this, but it sounds like it could be nasty. For example, if you need to check for a failed page mapping anyway, then you might not see much savings over just mapping the pages manually as you need them. > Bryan, would you have a problem if I added something like > xa_access_virtual_range to the API? This is fine with me. We will, of course, need to make sure that the semantics make sense and that failed page mappings are detectable and such. If this were c++, I'd say that we should just override the [] operator to transparently handle mapping pages as needed. In c, I'm not sure if there's an equally transparent solution. At any rate, I'm open to ideas, and if you'd like to play with this and code something up, then I'm happy to add the patch into the system. Thanks, -bryan -- Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Hajime I. <hi...@cc...> - 2007-11-05 19:41:04
|
I would very much like to be able to mmap multiple pages in xenaccess. I believe this is possible using the same function xenaccess employs, xc_map_foreign_range, and changing the argument for size. However, this function seems to have very strange failure semantics, since some pages in a range sometimes cannot be mapped. Does anybody understand how partial failures work with this function? Bryan, would you have a problem if I added something like xa_access_virtual_range to the API? -Jim |
|
From: <hi...@cc...> - 2007-08-28 16:41:48
|
This patch includes a revised description of the configuration file.
Index: README
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- README (revision 68)
+++ README (working copy)
@@ -49,21 +49,64 @@
place the following entry in the configuration file:
Fedora-HVM {
- sysmap =3D "/boot/System.map-2.6.18-1.2798.fc6";
+ sysmap =3D "/boot/System.map-2.6.18-1.2798.fc6";
+ ostype =3D "Linux";
+ linux_tasks =3D 268;
+ linux_mm =3D 276;
+ linux_pid =3D 312;
+ linux_name =3D 548;
+ linux_pgd =3D 40;
+ linux_addr =3D 132;
}
+or for Windows:
+
+WinXPSP2 {
+ ostype =3D "Windows";
+ win_tasks =3D 0x88;
+ win_pdbase =3D 0x18;
+ win_pid =3D 0x84;
+ win_peb =3D 0x1b0;
+ win_iba =3D 0x8;
+ win_ph =3D 0x18;
+}
+
+You need not specify offsets. Default values are found within
+linux_memory.c and windows_memory.c, respectively. However, you will
+probably need to calculate these values if you do not use the kernel
+distributed with xen.
+
In general, the configuration file contains records that look like:
<domain name> {
<key> =3D <value>;
}
-Currently, the only available key is 'sysmap'. In the future, additional
-keys may be added as needed. The list of keys is provided below:
+Currently there are 14 different keys available. Only ostype is common
+between Windows and Linux guests.
-- sysmap: path to the System.map file corresponding to the domain's kernel
+The list of keys is provided below:
+sysmap: The path to the System.map file corresponding to the
+ domain's Linux kernel.
+ostype: Linux or Windows guests are supported.
+linux_tasks: The number of bytes (offset) from the start of the
+ struct until task_struct->tasks. All of these
+ offsets are in linux/sched.h.
+linux_mm: Offset to task_struct->mm.
+linux_pid: Offset to task_struct->pid.
+linux_name: Offset to task_struct->name.
+linux_pgd: Offset to task_struct->pgd.
+linux_addr: Offset to task_struct->start_code.
+
+win_tasks: Offset to EPROCESS->ActiveProcessLinks.
+win_pdbase: Offset to EPROCESS->Pcb->DirectoryTableBase.
+win_pid: Offset to EPROCESS->UniqueProcessId.
+win_peb: Offset to EPROCESS->Peb.
+win_iba: Offset to EPROCESS->Peb->ImageBaseAddress.
+win_ph_offset: Offset to EPROCESS->Peb->ProcessHeap.
+
Using XenAccess
---------------
A quick way to see XenAccess in action is to try out the example code. Yo=
u
|
|
From: Daniele S. <da...@ya...> - 2007-08-28 07:09:40
|
I suggest including the Linux headers to find the correct offsets during compilation. In this way, you don't have to manually compute the offsets, but the compiler will do the job for you, and this solution is also portable. We've developed a set of functions that use XenAccess to introspect the Linux kernel, for example to retrieve the list of the running processes, the idt and the system call table, the list of the running modules, the list of the open files and also to check if an interface is set into promiscuous mode, by using the headers to "cast" the raw memory into the correct structure. Here you can find the code: http://www.di.unipi.it/~daniele/projects/xen_vmi/xen_vmi.php It's still a work in progress, but I hope that the idea of including the Linux headers may help you :) If you have any questions, let me know. ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html |
|
From: Bryan D. P. <br...@th...> - 2007-08-21 20:15:36
|
Thanks, this will be a great addition. I have committed your patch into the repository. -bryan On Aug 21, 2007, at 2:25 PM, hi...@cc... wrote: > This patch adds configurable offsets to xenaccess. See the > previous message for a longer description. > > Signed-off-by: Hajime Inoue <hi...@cc...> - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: <hi...@cc...> - 2007-08-21 18:25:55
|
This patch adds configurable offsets to xenaccess. See the
previous message for a longer description.
Signed-off-by: Hajime Inoue <hi...@cc...>
Index: xa_private.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xa_private.h=09(revision 65)
+++ xa_private.h=09(working copy)
@@ -46,22 +46,27 @@
/* offset to each of these fields from the beginning of the struct
assuming that CONFIG_SCHEDSTATS is not defined and CONFIG_KEYS
- is defined in the guest's kernel (this is the default in xen) */
-#define XALINUX_TASKS_OFFSET 24 * 4 /* task_struct->tasks */
-#define XALINUX_MM_OFFSET 30 * 4 /* task_struct->mm */
-#define XALINUX_PID_OFFSET 39 * 4 /* task_struct->pid */
-#define XALINUX_NAME_OFFSET 108 * 4 /* task_struct->comm */
-#define XALINUX_PGD_OFFSET 9 * 4 /* mm_struct->pgd */
-#define XALINUX_ADDR_OFFSET 32 * 4 /* mm_struct->start_code */
+ is defined in the guest's kernel (this is the default in xen)
+
+ These are defined in the OS specific memory files */
+
+extern int xalinux_tasks_offset; /* task_struct->tasks */
+extern int xalinux_mm_offset; /* task_struct->mm */
+extern int xalinux_pid_offset; /* task_struct->pid */
+extern int xalinux_name_offset; /* task_struct->name */
+extern int xalinux_pgd_offset; /* mm_struct->pgd */
+extern int xalinux_addr_offset; /* mm_struct->start_code */
+
/* offsets for Windows fields */
-#define XAWIN_TASKS_OFFSET 0x88 /* EPROCESS->ActiveProcessLinks */
-#define XAWIN_PDBASE_OFFSET 0x18 /* EPROCESS->Pcb->DirectoryTableBase =
*/
-#define XAWIN_PID_OFFSET 0x84 /* EPROCESS->UniqueProcessId */
-#define XAWIN_PEB_OFFSET 0x1b0 /* EPROCESS->Peb */
-#define XAWIN_IBA_OFFSET 0x8 /* EPROCESS->Peb->ImageBaseAddress */
-#define XAWIN_PH_OFFSET 0x18 /* EPROCESS->Peb->ProcessHeap */
+extern int xawin_tasks_offset; /* EPROCESS->ActiveProcessLinks */
+extern int xawin_pdbase_offset; /* EPROCESS->Pcb->DirectoryTableBase */
+extern int xawin_pid_offset; /* EPROCESS->UniqueProcessId */
+extern int xawin_peb_offset; /* EPROCESS->Peb */
+extern int xawin_iba_offset; /* EPROCESS->Peb->ImageBaseAddress */
+extern int xawin_ph_offset; /* EPROCESS->Peb->ProcessHeap */
+
/*------------------------------
* Utility function from xa_util
*/
Index: xa_core.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- xa_core.c=09(revision 65)
+++ xa_core.c=09(working copy)
@@ -91,6 +91,48 @@
printf("WARNING: Unknown or undefined OS type, assuming Linux.\n")=
;
instance->os_type =3D XA_OS_LINUX;
}
+
+ /* Copy config info based on OS type */
+ if(instance->os_type =3D=3D XA_OS_LINUX)
+ {
+=09 xa_dbprint("--reading in linux offsets from config file.\n");
+ if(entry->offsets.linux_offsets.tasks)
+ xalinux_tasks_offset =3D entry->offsets.linux_offsets.tasks;
+
+ if(entry->offsets.linux_offsets.mm)
+ xalinux_mm_offset =3D entry->offsets.linux_offsets.mm;
+
+ if(entry->offsets.linux_offsets.pid)
+ xalinux_pid_offset =3D entry->offsets.linux_offsets.pid;
+
+ if(entry->offsets.linux_offsets.name)
+ xalinux_name_offset =3D entry->offsets.linux_offsets.name;
+
+ if(entry->offsets.linux_offsets.addr)
+ xalinux_addr_offset =3D entry->offsets.linux_offsets.addr;
+ }
+ else /* This must be windows (see code above) */
+ {
+=09 xa_dbprint("--reading in windows offsets from config file.\n");
+ if(entry->offsets.windows_offsets.tasks)
+ xawin_tasks_offset =3D entry->offsets.windows_offsets.tasks;
+
+ if(entry->offsets.windows_offsets.pdbase)
+ xawin_pdbase_offset =3D entry->offsets.windows_offsets.pdbase;
+
+ if(entry->offsets.windows_offsets.pid)
+ xawin_pid_offset =3D entry->offsets.windows_offsets.pid;
+
+ if(entry->offsets.windows_offsets.peb)
+ xawin_peb_offset =3D entry->offsets.windows_offsets.peb;
+
+ if(entry->offsets.windows_offsets.iba)
+ xawin_iba_offset =3D entry->offsets.windows_offsets.iba;
+
+ if(entry->offsets.windows_offsets.ph)
+ xawin_ph_offset =3D entry->offsets.windows_offsets.ph;
+ }
+
#ifdef XA_DEBUG
xa_dbprint("--got ostype from config (%s).\n", entry->ostype);
if (instance->os_type =3D=3D XA_OS_LINUX){
@@ -247,7 +289,7 @@
goto error_exit;
}
instance->init_task =3D
- *((uint32_t*)(memory + local_offset + XALINUX_TASKS_OFFSET));
+ *((uint32_t*)(memory + local_offset + xalinux_tasks_offset));
munmap(memory, instance->page_size);
}
@@ -287,7 +329,7 @@
/* get address start of process list */
instance->init_task =3D
- *((uint32_t*)(memory + local_offset + XAWIN_TASKS_OFFSET));
+ *((uint32_t*)(memory + local_offset + xawin_tasks_offset));
munmap(memory, instance->page_size);
}
Index: windows_memory.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- windows_memory.c=09(revision 65)
+++ windows_memory.c=09(working copy)
@@ -35,6 +35,15 @@
#include <sys/mman.h>
#include "xa_private.h"
+/* Globals */
+int xawin_tasks_offset =3D 0x88;
+int xawin_pdbase_offset =3D 0x18;
+int xawin_pid_offset =3D 0x84;
+int xawin_peb_offset =3D 0x1b0;
+int xawin_iba_offset =3D 0x8;
+int xawin_ph_offset =3D 0x18;
+
+
/* finds the EPROCESS struct for a given pid */
unsigned char *windows_get_EPROCESS (
xa_instance_t *instance, int pid, uint32_t *offset)
@@ -61,7 +70,7 @@
}
memcpy(&task_pid,
- memory + *offset + XAWIN_PID_OFFSET - XAWIN_TASKS_OFFSET,
+ memory + *offset + xawin_pid_offset - xawin_tasks_offset,
4
);
@@ -92,7 +101,7 @@
/* now follow the pointer to the memory descriptor and
grab the pgd value */
- pgd =3D =20
*((uint32_t*)(memory+offset+XAWIN_PDBASE_OFFSET-XAWIN_TASKS_OFFSET));
+ pgd =3D =20
*((uint32_t*)(memory+offset+xawin_pdbase_offset-xawin_tasks_offset));
pgd +=3D instance->page_offset;
munmap(memory, instance->page_size);
Index: config/config_parser.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- config/config_parser.h=09(revision 65)
+++ config/config_parser.h=09(working copy)
@@ -32,10 +32,28 @@
#define CONFIG_STR_LENGTH 1024
-typedef struct xa_config_entry{
+typedef struct xa_config_entry {
char domain_name[CONFIG_STR_LENGTH];
char sysmap[CONFIG_STR_LENGTH];
char ostype[CONFIG_STR_LENGTH];
+ union {
+ struct linux_offsets {
+ int tasks;
+ int mm;
+ int pid;
+ int name;
+ int pgd;
+ int addr;
+ } linux_offsets;
+ struct windows_offsets {
+ int tasks;
+ int pdbase;
+ int pid;
+ int peb;
+ int iba;
+ int ph;
+ } windows_offsets;
+ } offsets;
} xa_config_entry_t;
void xa_parse_config(char *td);
Index: config/lexicon.l
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- config/lexicon.l=09(revision 65)
+++ config/lexicon.l=09(working copy)
@@ -35,9 +35,22 @@
%}
%%
+linux_tasks return LINUX_TASKS;
+linux_mm return LINUX_MM;
+linux_pid return LINUX_PID;
+linux_name return LINUX_NAME;
+linux_pgd return LINUX_PGD;
+linux_addr return LINUX_ADDR;
+win_tasks return WIN_TASKS;
+win_pdbase return WIN_PDBASE;
+win_pid return WIN_PID;
+win_peb return WIN_PEB;
+win_iba return WIN_IBA;
+win_ph return WIN_PH;
sysmap return SYSMAPTOK;
ostype return OSTYPETOK;
-[a-zA-Z0-9.-]+ yylval.str =3D strdup(yytext); return WORD;
+0x[0-9a-fA-F]|[1-9][0-9]+ yylval.str =3D strdup(yytext); return NUM;
+[a-zA-Z][a-zA-Z0-9.-]+ yylval.str =3D strdup(yytext); return WORD;
[a-zA-Z0-9\/.-]+ yylval.str =3D strdup(yytext); return FILENAME;
\" return QUOTE;
\{ return OBRACE;
Index: config/grammar.y
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- config/grammar.y=09(revision 65)
+++ config/grammar.y=09(working copy)
@@ -33,6 +33,7 @@
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
+#include <errno.h>
#include "config_parser.h"
xa_config_entry_t entry;
@@ -53,10 +54,13 @@
void entry_done ()
{
if (strncmp(tmp_entry.domain_name, target_domain, =20
CONFIG_STR_LENGTH) =3D=3D 0){
+ entry =3D tmp_entry;
+/*
memcpy(entry.domain_name, tmp_entry.domain_name, CONFIG_STR_LENGTH=
);
memcpy(entry.sysmap, tmp_entry.sysmap, CONFIG_STR_LENGTH);
- memcpy(entry.ostype, tmp_entry.ostype, CONFIG_STR_LENGTH);
- /* copy over other values here as they are added */
+ memcpy(entry.ostype, tmp_entry.ostype, CONFIG_STR_LENGTH)
+ entry.offsets =3D tmp_entry.offsets;
+*/
}
}
@@ -78,6 +82,19 @@
char *str;
}
+%token<str> NUM
+%token LINUX_TASKS
+%token LINUX_MM
+%token LINUX_PID
+%token LINUX_NAME
+%token LINUX_PGD
+%token LINUX_ADDR
+%token WIN_TASKS
+%token WIN_PDBASE
+%token WIN_PID
+%token WIN_PEB
+%token WIN_IBA
+%token WIN_PH
%token SYSMAPTOK
%token OSTYPETOK
%token<str> WORD
@@ -113,8 +130,128 @@
sysmap_assignment
|
ostype_assignment
+ |
+ linux_tasks_assignment
+ |
+ linux_mm_assignment
+ |
+ linux_pid_assignment
+ |
+ linux_name_assignment
+ |
+ linux_pgd_assignment
+ |
+ linux_addr_assignment
+ |
+ win_tasks_assignment
+ |
+ win_pdbase_assignment
+ |
+ win_pid_assignment
+ |
+ win_peb_assignment
+ |
+ win_iba_assignment
+ |
+ win_ph_assignment
;
+linux_tasks_assignment:
+ LINUX_TASKS EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.linux_offsets.tasks =3D tmp;
+ }
+ ;
+
+linux_mm_assignment:
+ LINUX_MM EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.linux_offsets.mm =3D tmp;
+ }
+ ;
+
+linux_pid_assignment:
+ LINUX_PID EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.linux_offsets.pid =3D tmp;
+ }
+ ;
+
+linux_name_assignment:
+ LINUX_NAME EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.linux_offsets.name =3D tmp;
+ }
+ ;
+
+linux_pgd_assignment:
+ LINUX_PGD EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.linux_offsets.pgd =3D tmp;
+ }
+ ;
+
+linux_addr_assignment:
+ LINUX_ADDR EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.linux_offsets.addr =3D tmp;
+ }
+ ;
+
+win_tasks_assignment:
+ WIN_TASKS EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.windows_offsets.tasks =3D tmp;
+ }
+ ;
+
+win_pdbase_assignment:
+ WIN_PDBASE EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.windows_offsets.pdbase =3D tmp;
+ }
+ ;
+
+win_pid_assignment:
+ WIN_PID EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.windows_offsets.pid =3D tmp;
+ }
+ ;
+
+win_peb_assignment:
+ WIN_PEB EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.windows_offsets.peb =3D tmp;
+ }
+ ;
+
+win_iba_assignment:
+ WIN_IBA EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.windows_offsets.iba =3D tmp;
+ }
+ ;
+
+win_ph_assignment:
+ WIN_PH EQUALS NUM
+ {
+ int tmp =3D strtol($3, NULL, 0);
+ tmp_entry.offsets.windows_offsets.ph =3D tmp;
+ }
+ ;
+
sysmap_assignment:
SYSMAPTOK EQUALS QUOTE FILENAME QUOTE
{
Index: linux_memory.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux_memory.c=09(revision 65)
+++ linux_memory.c=09(working copy)
@@ -34,6 +34,15 @@
#include <sys/mman.h>
#include "xa_private.h"
+
+/* Globals */
+int xalinux_tasks_offset =3D 0x60;
+int xalinux_mm_offset =3D 0x78;
+int xalinux_pid_offset =3D 0x9c;
+int xalinux_name_offset =3D 0x1b0;
+int xalinux_pgd_offset =3D 0x24;
+int xalinux_addr_offset =3D 0x80;
+
/* finds the task struct for a given pid */
unsigned char *linux_get_taskstruct (
xa_instance_t *instance, int pid, uint32_t *offset)
@@ -60,7 +69,7 @@
}
memcpy(&task_pid,
- memory + *offset + XALINUX_PID_OFFSET - XALINUX_TASKS_OFFSET=
,
+ memory + *offset + xalinux_pid_offset - xalinux_tasks_offset=
,
4
);
@@ -91,15 +100,15 @@
/* now follow the pointer to the memory descriptor and
grab the pgd value */
- memcpy(&ptr, memory + offset + XALINUX_MM_OFFSET - =20
XALINUX_TASKS_OFFSET, 4);
+ memcpy(&ptr, memory + offset + xalinux_mm_offset - =20
xalinux_tasks_offset, 4);
munmap(memory, instance->page_size);
memory =3D xa_access_virtual_address(instance, ptr, &offset);
if (NULL =3D=3D memory){
printf("ERROR: failed to follow mm pointer");
goto error_exit;
}
- /* memcpy(&pgd, memory + offset + XALINUX_PGD_OFFSET, 4); */
- pgd =3D *((uint32_t*)(memory + offset + XALINUX_PGD_OFFSET));
+ /* memcpy(&pgd, memory + offset + xalinux_pgd_offset, 4); */
+ pgd =3D *((uint32_t*)(memory + offset + xalinux_pgd_offset));
error_exit:
if (memory) munmap(memory, instance->page_size);
@@ -142,7 +151,7 @@
}
/* copy the information out of the memory descriptor */
- memcpy(&ptr, memory + offset + XALINUX_MM_OFFSET - =20
XALINUX_TASKS_OFFSET, 4);
+ memcpy(&ptr, memory + offset + xalinux_mm_offset - =20
xalinux_tasks_offset, 4);
munmap(memory, instance->page_size);
memory =3D xa_access_virtual_address(instance, ptr, &offset);
if (NULL =3D=3D memory){
@@ -151,7 +160,7 @@
}
memcpy(
taskaddr,
- memory + offset + XALINUX_ADDR_OFFSET,
+ memory + offset + xalinux_addr_offset,
sizeof(xa_linux_taskaddr_t)
);
|
|
From: <hi...@cc...> - 2007-08-21 18:17:12
|
My next message is a patch that allows one to specify memory offsets within
the configuration file. Previously, those values were hardcoded
within xa_private.h. Those values now are ints declared as extern
within xa_private.h and are defined (with the default values intact),
within (linux|windows)_memory.c. The variable names are no longer
capitalized (e.g. XALINUX_TASKS_OFFSET becomes xalinux_tasks_offset).
My new configuration file looks like:
Fedora7 {
sysmap =3D "/home/hinoue/research/xenaccess/syms/fedora.syms";
ostype =3D "Linux";
linux_tasks =3D 268;
linux_mm =3D 276;
linux_pid =3D 312;
linux_name =3D 548;
linux_pgd =3D 40;
linux_addr =3D 132;
}
I have moved the windows offsets into the config file as well.
Those would be win_tasks, etc.
The config parser required a few changes. There's now a union of
structs within the config_entry struct which store these values. =20
Also, the configuration options have been added as keywords within the =20
parser.
DomU names must now begin with a letter. Previously, they could begin
with a number. Numbers can be specified in hex or dec.
-Jim
|
|
From: Bryan D. P. <br...@th...> - 2007-08-20 19:23:26
|
Ah yes, sorry about that. This should be the offset to the start_code field in the mm_struct. The variable is used in linux_memory.c to copy information into the taskaddr struct. I'll update the comment in xa_private.h. Thanks, bryan On Aug 20, 2007, at 2:26 PM, Hajime Inoue wrote: > I'm trying to calculate the offsets in xaprivate.h > > The last offset, XALINUX_ADDR_OFFSET 32 * 4 is commented as > mm_struct->pgd, > which is the comment of the line above. Can anyone tell me what > it's supposed to be? > (I don't think it actually matters right now, because it's not > accessed anywhere > else, AFAIK, but I'm guessing it will be). > > Thanks, > -Jim - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Hajime I. <hi...@cc...> - 2007-08-20 18:32:45
|
I'm trying to calculate the offsets in xaprivate.h The last offset, XALINUX_ADDR_OFFSET 32 * 4 is commented as mm_struct->pgd, which is the comment of the line above. Can anyone tell me what it's supposed to be? (I don't think it actually matters right now, because it's not accessed anywhere else, AFAIK, but I'm guessing it will be). Thanks, -Jim |
|
From: Bryan D. P. <br...@th...> - 2007-08-16 20:59:13
|
> I've been doing all my testing so far on Fedora, and it's been > working. > On Debian, I've had a problem getting my code (and the examples to > work). > > I'm assuming it's a problem with my kernel configuration. Have any > ideas? Yes, it is very likely the kernel configuration. More specifically, a different kernel build config (or a different kernel version) will result in different offsets within the various data structures that are used within XenAccess. You can figure out what these new offsets are for the new kernel, and then you should be all set :-) Of course, I'm not suggesting that's trivial, but it's doable. An automated method for doing this would be very nice, of course. And that's actually on my todo list right now, but it will likely be a while before I get to it. Cheers, bryan - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: <hi...@cc...> - 2007-08-16 20:49:35
|
Sorry guys, The second sentence should be "On debian, I've had a problem..." -Jim Quoting hi...@cc...: > Hi, > > I've been doing all my testing so far on Fedora, and it's been working. > On Fedora, I've had a problem getting my code (and the examples to work). > > I'm assuming it's a problem with my kernel configuration. Have any ideas? > > Thanks, > -Jim > > > Here is the output for module-list: > > [root@easy-mark examples]# ./module-list 17 > --got domain info. > --got domain name from id (17 =3D=3D> debian). > --got sysmap from config (/home/hinoue/xenaccess/syms/debian.syms). > WARNING: Unknown or undefined OS type, assuming Linux. > --got ostype from config (). > **set instance->os_type to Linux. > --got memory layout. > **set instance->hvm to true (HVM). > --got vaddr for swapper_pg_dir (0xc0350000). > **set instance->kpgd (0xc0350000). > ���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 6553 > 3;ᦙ > 3;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= A > 533;A > 533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;&# > 65533;&# > 65533;��������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533; > � > ���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 6553 > 3;ᦙ > 3;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= A > 533;A > 533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;&# > 65533;&# > 65533;��������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533; > � > ���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 6553 > 3;ᦙ > 3;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= A > 533;A > 533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;&# > 65533;&# > 65533;��������A= 533;���������= ������UXYVVV��ᦙ= 3;���yyyyyyyyyyyyfffeeeUUU=1C=1D=1E��A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= �&# > 65533;&# > 65533;��������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533; > � > ���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 6553 > 3;ᦙ > 3;���������= ���������A= 533;���������= ��� > � > �S� > > ERROR: address not in page table > failed to map memory for module list pointer: Success > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > XenAccess-devel mailing list > Xen...@li... > https://lists.sourceforge.net/lists/listinfo/xenaccess-devel > |
|
From: <hi...@cc...> - 2007-08-16 20:43:58
|
Hi, I've been doing all my testing so far on Fedora, and it's been working. On Fedora, I've had a problem getting my code (and the examples to work). I'm assuming it's a problem with my kernel configuration. Have any ideas? Thanks, -Jim Here is the output for module-list: [root@easy-mark examples]# ./module-list 17 --got domain info. --got domain name from id (17 =3D=3D> debian). --got sysmap from config (/home/hinoue/xenaccess/syms/debian.syms). WARNING: Unknown or undefined OS type, assuming Linux. --got ostype from config (). **set instance->os_type to Linux. --got memory layout. **set instance->hvm to true (HVM). --got vaddr for swapper_pg_dir (0xc0350000). **set instance->kpgd (0xc0350000). ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;ᦙ 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;A 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= �&# 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;� ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;ᦙ 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;A 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= �&# 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;� ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;ᦙ 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;A 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= �&# 65533;��������ᦙ= 3;���������&#= 65533;�����UXYVVV���= ���yyyyyyyyyyyyfffeeeUUU=1C=1D=1E��ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;�&# 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;��������ᦙ= 3;� ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;���������= ���������A= 533;ᦙ 3;���������&#= 65533;��������ᦙ= 3;���������&#= 65533;�� � �S� ERROR: address not in page table failed to map memory for module list pointer: Success |
|
From: Bryan D. P. <br...@th...> - 2007-08-15 19:54:11
|
The latest version of the code is currently undergoing a lot of changes with the ultimate goal of supporting windows. The PSE check was added (along with other checks) to make sure that the page table layout is supported by xenaccess before trying to walk the page table and, possibly, interpreting the entries incorrectly. PSE is an interesting beast. Just because the bit is enabled in CR4 doesn't mean that variable sized pages are actually in use. It just means that they might be in use. Right now the code fails on the PSE check because my page table lookup code does not check the PTE bit to see what size the pages are. It probably works just fine for you because you are working on a system (or at least a part of a system) that has 4k pages. In general, there is no harm in just commenting out this code for now, if you'd like. This will provide the same functionality as previously was available with xenaccess. The only real risk is that the system may not work properly if you have a 4MB page. Before the next release, I plan on actually implementing the proper page table lookup techniques so that this whole issue goes away (i.e., I'll perform the proper checks so that the failure condition that you are currently seeing will not exist). From what I have seen, PV domains do not have the PSE bit set whereas HVM domains do. So if you're working with HVM, it would make sense that this check is giving you trouble. Sorry for the long answer, but hopefully that makes sense. Cheers, bryan On Aug 15, 2007, at 3:26 PM, Hajime Inoue wrote: > A recent update to subversion added a check for PSE. > This is enabled in my images. However, the examples > work when this check is commented out. Is this > a paravirtualized-only problem, or one where big pages > could cause problems, but since I'm not using big pages, > I don't see one? > > Thanks, > -Jim - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Hajime I. <hi...@cc...> - 2007-08-15 19:27:30
|
A recent update to subversion added a check for PSE. This is enabled in my images. However, the examples work when this check is commented out. Is this a paravirtualized-only problem, or one where big pages could cause problems, but since I'm not using big pages, I don't see one? Thanks, -Jim |
|
From: Hajime I. <hi...@cc...> - 2007-08-01 13:14:28
|
Hi Bryan, Here's the output: [root@easy-mark examples]# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 938 2 r----- 4441.3 Fedora7 22 512 1 -b---- 494.2 [root@easy-mark examples]# ./module-list 22 Got domain info. Got domain name from id (22 ==> Fedora7). Got sysmap (/boot/System.map-2.6.22.1-33.fc7). Got OS type. Got vaddr for swapper_pg_dir = 0xc136b000. swapper_pg_dir = 0xc136b000. ERROR: pte entry lookup failed (mach addr = 0xdfce2b98) ** pgd_entry = 0xdfce2b18 ** pte_entry = 0xdfce2b98 ** vaddr = 0xc12e6340 ERROR: address not in page table ERROR: failed to get task list head 'init_task' failed to init XenAccess library: Bad address [root@easy-mark examples]# Quoting "Bryan D. Payne" <br...@th...>: > Jim, > > Some preliminary HVM support is already in place, assuming you are > using the xenaccess code straight from the subversion repository. My > guess is that the problem you are seeing is due to some changes between > Xen 3.0.5 and Xen 3.1. I'm actively working on addressing this problem > now so hopefully we'll have something working soon. > > Just to be sure we're talking about the same problems, though. Would > you mind enabling debugging support (uncomment the line near the top of > xenaccess.h) and sending the output back to this mailing list? |
|
From: Hajime I. <hi...@cc...> - 2007-07-31 19:50:21
|
I am trying to run the example code (module-list) on a HVM on Xen 3.1 and Fedora Core 7. The guest is running the latest Fedora RPM Kernel (2.6.22.1-33) and I have it pointed to the correct System.map. It fails similarly to the problems described with HVM in the documentation. Can you tell me if it's the same problem? What is required to fix it? In the documentation you say those fixes are close to completion. Do you have an ETA on those fixes? Thanks, -Jim |
|
From: Daniele S. <da...@ya...> - 2007-02-23 17:27:26
|
Hi, I've added some macros that should help in page table lookup, by returning the address field from the pgd/pgt entries. It also checks if the pointed page table / page frame is in memory. It only works with x86/32 (not PAE). Tell me if you think it's ok. ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html |
|
From: Bryan D. P. <br...@th...> - 2007-01-27 14:03:51
|
Thanks, the patch has been applied. -bryan Stephan Creutz wrote: > On Fri, 26 Jan 2007 23:12:34 +0100 > Stephan Creutz <ste...@in...> wrote: > >> Hi, >> >> I have fixed a minor bug in linux_system_map.c. The loop should be >> exited when the end of a token was found. > > > The patch again, but this time with the right MIME type. > > Stephan > > |
|
From: Stephan C. <ste...@in...> - 2007-01-27 10:11:28
|
On Fri, 26 Jan 2007 23:12:34 +0100 Stephan Creutz <ste...@in...> wrote: > Hi, > > I have fixed a minor bug in linux_system_map.c. The loop should be > exited when the end of a token was found. The patch again, but this time with the right MIME type. Stephan |
|
From: Stephan C. <ste...@in...> - 2007-01-26 22:12:42
|
Hi, I have fixed a minor bug in linux_system_map.c. The loop should be exited when the end of a token was found. Stephan |
|
From: Bryan D. P. <br...@th...> - 2007-01-21 19:45:03
|
First, let's consider how to solve this problem locally (without XenAccess, from within the domU). You could need to identify the source port of the network connection and then use the command "netstat -nalp" (as root) to locate the process associated with that source port. So, we know that the necessary information exists, which is always a good thing :-) Now, the question is where is this information located in memory. I don't know off the top of my head, but it must be in the kernel memory somewhere (a guess because you must be root to view the information from the command line). So, your first step is to identify it's location. Next, you can use XenAccess to view that memory. So the entire procedure looks something like this: 0) All of this can happen in dom0 1) Watch for the network traffic that interests you 2) Note the source port for this network traffic, along with the source IP address 3) Use the source IP address to identify the domain id (you could also get the domain ID by tapping the network traffic from within the netback driver, avoiding the need for this lookup, but requiring kernel programming) 4) Use XenAccess to look into the domain's memory to find the process using the source port in question While I haven't done this, I believe that it should work just fine. Of course, the trick is figuring out where to look in the domU memory space. If you find that location, please post back to the list as it sounds like a generally useful piece of memory to access :-) Cheers, bryan On Jan 21, 2007, at 2:27 PM, Sanjam Garg wrote: > Hi > > I wanted to identify the process in domU generating a > particular packet from a kernel module in dom0, > identified by the code running on the packets passing > through a hook function. > > I have seen the process-list.c example, and understand > how the listing is done but do not have the idea how > to figure which of these processes generated the > packet. > > How can I do that? > > Sanjam - Bryan D. Payne Graduate Student, Computer Science Georgia Tech Information Security Center http://www.bryanpayne.org |
|
From: Sanjam G. <sa...@ya...> - 2007-01-21 19:27:21
|
Hi I wanted to identify the process in domU generating a particular packet from a kernel module in dom0, identified by the code running on the packets passing through a hook function. I have seen the process-list.c example, and understand how the listing is done but do not have the idea how to figure which of these processes generated the packet. How can I do that? Sanjam ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL |
|
From: Tomas K. <to...@ji...> - 2007-01-08 19:34:40
|
Bryan D. Payne wrote: > In case people are trying to use XenAccess with Xen 3.0.4, I wanted > to provide this update. The currently released version of XenAccess > (0.3) will work with Xen 3.0.3. > > However, there was a change in Xen 3.0.4 that breaks the XenAccess > HVM support (PV support works fine). I have already fixed the > problem and the updated code is in the subversion repository. The > fix allows the code to work with Xen 3.0.4, but not Xen 3.0.3. > > In short, Xen and XenAccess versions are linked as follows: > > Xen 3.0.3 --> XenAccess 0.3. > Xen 3.0.4 --> XenAccess via subversion. > > I will look into adding automatic version detection so that XenAccess > can detect what version of Xen you are running and automatically do > the right now. But for now, stick with the recommendations above. > > Hi, thanks a lot. I was trying to find the workaround myself, but am still quite lame with xen. So thanks again. -- Tomas Kouba |
