[Xen-devel] [PATCH] Fix the KDD_LOG statements to use appropriate format specifier for printing uint64_t
Previous commit in kdd.c had a small issue which lead to warning/error while
compiling
on 32-bit systems due to mismatch of type size while doing type cast from
uint64_t to
void *
Signed-off-by: Jenish Rakholiya
Signed-off-by: Julian Tuminaro
---
tools/debugger/kdd/kdd.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index 6d3febefda..3ebda9b12c 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -613,7 +613,7 @@ static void get_os_info_64(kdd_state *s)
idt0_addr |= ((buf >> 32) & 0x);
idt0_addr |= (buf & 0x);
-KDD_LOG(s, "idt0 addr: %p\n", (void *)idt0_addr);
+KDD_LOG(s, "idt0 addr: 0x%"PRIx64"\n", idt0_addr);
/*
* get the page start and look for "MZ" file header - we limit the search
@@ -621,7 +621,6 @@ static void get_os_info_64(kdd_state *s)
*/
base = idt0_addr & ~(PAGE_SIZE - 1);
-KDD_LOG(s, "%p\n", (void *)base);
while (search_limit) {
uint16_t val;
@@ -638,7 +637,7 @@ static void get_os_info_64(kdd_state *s)
search_limit -= 1;
}
-KDD_LOG(s, "base: %p\n", (void *)base);
+KDD_LOG(s, "base: 0x%"PRIx64"\n", base);
/* found the data section start */
if (get_pe64_sections(s, base, ".data", _base, _size))
@@ -689,9 +688,9 @@ static void get_os_info_64(kdd_state *s)
if (caddr < data_base + data_size) {
/* if found, set the field and return */
-KDD_LOG(s, "base: %p\n", (void *)base);
-KDD_LOG(s, "modules list: %p\n", (void *)modptr);
-KDD_LOG(s, "kddl: %p\n", (void *)kddl);
+KDD_LOG(s, "base: 0x%"PRIx64"\n", base);
+KDD_LOG(s, "modules list: 0x%"PRIx64"\n", modptr);
+KDD_LOG(s, "kddl: 0x%"PRIx64"\n", kddl);
KDD_LOG(s, "minor version: 0x%hx\n", minor);
s->os.base = base;
--
2.17.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH V2] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit)
From: Julian Tuminaro and Jenish Rakholiya
Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range. However, this
is not scalable to all version of Windows as it will require us to keep
adding new entries and also due to KASLR, chances of not hitting the PE
header is significant. We implement a way for 64-bit systems to use IDT
entry to get a valid exception/interrupt handler and then move back into
the memory to find the valid DOS header. Since IDT entries are protected
by PatchGuard, we think our assumption that IDT entries will not be
corrupted is valid for our purpose. Once we have the image base, we
search for the DBGKD_GET_VERSION64 structure type in .data section to
get information required for handshake.
Currently, this is a work in progress feature and current patch only
supports the handshake and memory read/write on 64-bit systems.
NOTE: This is the Updated version of the previous patch submitted
NOTE: This has currently been only tested when debugging was not enabled
on the guest Windows.
Signed-off-by: Jenish Rakholiya
Signed-off-by: Julian Tuminaro
---
tools/debugger/kdd/kdd.c | 392 ---
1 file changed, 366 insertions(+), 26 deletions(-)
diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index fb8c645355..6d3febefda 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -51,6 +52,16 @@
#include "kdd.h"
+/*
+ * TODO: kdd_os is a type which is used to represent os array. Adding a
+ * variable here would result in adding a new field to each element in array.
+ * However, since most of the fields are part of the same struct that we are
+ * trying to read from memory, we have added kddl to this structure. If
+ * required, we can possibly separate the kddl value to someplace else
+ *
+ * We also use kddl of size uint32_t which is actually used to represent the
+ * offset from image base rather than actual address
+ */
/* Windows version details */
typedef struct {
uint32_t build;
@@ -62,6 +73,7 @@ typedef struct {
uint32_t version; /* +-> NtBuildNumber */
uint32_t modules; /* +-> PsLoadedModuleList */
uint32_t prcbs; /* +-> KiProcessorBlock */
+uint32_t kddl; /* +-> KdDebuggerList */
} kdd_os;
/* State of the debugger stub */
@@ -85,6 +97,117 @@ typedef struct {
kdd_os os; /* OS-specific magic numbers */
} kdd_state;
+/**
+ * @brief Structure to represent DBGKD_GET_VERSION64
+ *
+ * reference:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdbgexts/ns-wdbgexts-_dbgkd_get_version64
+ */
+typedef struct {
+uint16_t MajorVersion; /* usually 0xf for free build */
+uint16_t MinorVersion; /* build number of target OS */
+uint8_t ProtocolVersion; /* version of the debugger protocol */
+uint8_t KdSecondaryVersion; /* secondary version number */
+uint16_t Flags;/* set of bit flags for the current debugging session */
+uint16_t MachineType; /* type of the target's processor */
+uint8_t MaxPacketType; /* one plus the highest number for a debugger */
+ /* packet type recognized by the target */
+uint8_t MaxStateChagne; /* one plus the highest number for a state */
+ /* change generated by the target */
+uint8_t MaxManipulate; /* one more that the highest number, recognized */
+/* by the target, for a command to manipulate the target */
+uint8_t Simulation;/* indication if target is in simulated execution */
+uint16_t Unused[1];
+uint64_t KernBase; /* base address of the kernel image */
+uint64_t PsLoadedModuleList; /* value of the kernel variable */
+ /* PsLoadedModuleList */
+uint64_t DebuggerDataList; /* value of the kernel variable */
+ /* KdDebuggerDataBlock */
+} PACKED DBGKD_GET_VERSION64;
+
+/**
+ * @brief Structure to represent the section in PE headers
+ *
+ * reference:
https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers
+ */
+typedef struct {
+uint8_t Name[8];/* name of section */
+uint32_t VirtualSize; /* total size of section in memory */
+uint32_t VirtualAddr; /* offset from image base */
+uint32_t SizeOfRawData; /* size of section in for object files */
+uint32_t PointerToRawData; /* file pointer to first page in
[Xen-devel] [PATCH 1/1] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit)
From: "julian.tumin...@gmail.com"
Current implementation of find_os is based on the hard-coded values for
different Windows version. It uses the value for get the address to
start looking for DOS header in the given specified range. However, this
is not scalable to all version of Windows as it will require us to keep
adding new entries and also due to KASLR, chances of not hitting the PE
header is significant. We implement a way for 64-bit systems to use IDT
entry to get a valid exception/interrupt handler and then move back into
the memory to find the valid DOS header. Since IDT entries are protected
by PatchGuard, we think our assumption that IDT entries will not be
corrupted is valid for our purpose. Once we have the image base, we
search for the DBGKD_GET_VERSION64 structure type in .data section to
get information required for handshake.
Currently, this is a work in progress feature and current patch only
supports the handshake and memory read/write on 64-bit systems.
Signed-off-by: Jenish Rakholiya
Signed-off-by: Julian Tuminaro
---
tools/debugger/kdd/kdd.c | 389 ++-
1 file changed, 388 insertions(+), 1 deletion(-)
diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c
index fb8c645355..407b70a21c 100644
--- a/tools/debugger/kdd/kdd.c
+++ b/tools/debugger/kdd/kdd.c
@@ -51,6 +51,8 @@
#include "kdd.h"
+// TODO: make fix this to actually use address instead of offset?
+// TODO: Maybe clean something as well?
/* Windows version details */
typedef struct {
uint32_t build;
@@ -62,6 +64,7 @@ typedef struct {
uint32_t version; /* +-> NtBuildNumber */
uint32_t modules; /* +-> PsLoadedModuleList */
uint32_t prcbs; /* +-> KiProcessorBlock */
+uint32_t kddl;
} kdd_os;
/* State of the debugger stub */
@@ -85,6 +88,106 @@ typedef struct {
kdd_os os; /* OS-specific magic numbers */
} kdd_state;
+/**
+ * @brief Size of pointer on 64 machine
+ */
+#define SIZE_PTR64 8
+
+/**
+ * @brief Size of pointer on 32 machine
+ */
+#define SIZE_PTR32 4
+
+
+/*
+ * PE and DOS Header related offsets
+ */
+
+/**
+ * @brief Offset in DOS header to look for PE header
+ */
+#define DOS_HDR_PE_OFF 0x3c
+
+/**
+ * @brief Size of PE header offset field in DOS header
+ */
+#define DOS_HDR_PE_SZ 4
+
+/**
+ * @brief Offset of number of sections field in PE header
+ */
+#define PE_NUM_SECTION_OFF 0x6
+
+/**
+ * @brief Size of number of sections field in PE header
+ */
+#define PE_NUM_SECTION_SZ 2
+
+/**
+ * @brief Offset of optional header size field in PE header
+ */
+#define PE_OPT_HDR_SZ_OFF 0x14
+
+/**
+ * @brief Size of optional header size field in PE header
+ */
+#define PE_OPT_HDR_SZ_SZ 2
+
+/**
+ * @brief Size of PE header
+ */
+#define PE_HDR_SZ 0x18
+
+/**
+ * @brief Size of section header entries in PE
+ */
+#define PE_SECT_ENT_SZ 0x28
+
+/**
+ * @brief Offset of name field in section header entry
+ */
+#define PE_SECT_NAME_OFF 0
+
+/**
+ * @brief Size of name field in section header entry
+ */
+#define PE_SECT_NAME_SZ 0x8
+
+/**
+ * @brief Offset of virtual address (RVA) field in section header entry
+ */
+#define PE_SECT_RVA_OFF 0xc
+
+/**
+ * @brief Offset of virtual size field in section header entry
+ */
+#define PE_SECT_VSIZE_OFF 0x8
+
+/**
+ * @brief Size of DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_GET_VERSION64_SZ 0x28
+
+/**
+ * @brief Offset of KERN_BASE in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_KERN_BASE_OFF 0x10
+
+/**
+ * @brief Offset of PsLoadedModulesList in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_MOD_LIST_OFF 0x18
+
+/**
+ * @brief Offset of DebuggerDataList in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_KDDL_OFF 0x20
+
+/**
+ * @brief Offset of DebuggerDataList in DBGKD_GET_VERSION64 struct
+ */
+#define DBGKD_MINOR_OFF 0x2
+
/*
* Utility functions
*/
@@ -390,6 +493,284 @@ static void find_os(kdd_state *s)
s->os = unknown_os;
}
+#if 0
+/**
+ * @brief Temporary function for printing memory dump while debugging
+ * Dumps in the format of QWORD type
+ *
+ * @param s Pointer to the kdd_state structure
+ * @param addr Address to start dumping memory from
+ * @param size Number of bytes to print (automatically aligned to higher
+ * multiple of 8 bytes
+ *
+ * @note TODO: Remove this before pushing to master
+ * @note TODO: Maybe add level of logging to kdd (using -v option) - The
+ * idea of using printf instead of KDD_LOG was to not print all other unwanted
+ * logging output
+ */
+static void my_memdump(kdd_state *s, uint64_t addr, int size)
+{
+int ret;
+uint64_t buf;
+
+// we don't handle mis-aligned addresses
+if (addr & 7) {
+// XXX: TODO: don't do this
+return;
+}
+
+
Re: [Xen-devel] Looking for Semester long Project
Paul, I am still trying to understand the current status. You mentioned "without having to enable debugging within the guest". Does that mean we will need to monitor all the debug exceptions, and see if one of these was because of us or them? Also, wouldn't setting breakpoints require us to modify kernel text section memory? Or is there an alternative? Is this the current kdd code that works for window 7: http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/debugger/kdd;h=fd82789a678fb8060cc74ebbe0a04dc58309d6d7;hb=refs/heads/master? Or is there another branch with some more updated code? I will start going through the patch for qemu. Lastly, can you give us some brief idea on what new issues come up for windows 10 vs windows 7. You mentioned KASLR, any other potential challenges? Wei, Could you also let us know some of the projects you have in mind for us? Julian On Mon, Sep 16, 2019 at 9:15 AM Paul Durrant wrote: > Hi Julian, > > The KDD code has been untouched for many years; the last OS that it > appears to have been tried with is Win7 SP1. However, debugging a > Windows guest with emulated serial is very slow and clunky so a > solution like KDD is very desirable. > The goal of a project would be to get the code functional against a > recent version of Windows (i.e. 10) such that we could run windbg > against it and walk kernel data structures, set breakpoints etc. > without having to enable debugging within the guest. > > Cheers, > > Paul > > On Mon, 16 Sep 2019 at 15:31, Julian Tuminaro > wrote: > > > > Hi Paul, > > > > Thanks for getting back to us in regards to the KDD project. I am trying > to understand the current status of the project. Could you provide a bit > more information on the current status and what would need to be done. > > > > Julian > > > > On Mon, Sep 16, 2019 at 5:53 AM Paul Durrant wrote: > >> > >> I think KDD is still a worthy thing to do, particularly in light of > >> https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg01723.html > >> (which is about the most recent ref I could find, and I don't know > >> what happened to the code after that). AFAIK, the biggest challenge is > >> getting round Windows' KASLR; it may be necessary to have some sort of > >> driver in the guest to get the necessary info. out but that shouldn't > >> be too hard to implement. > >> > >> Cheers, > >> > >> Paul > >> > >> On Mon, 16 Sep 2019 at 11:39, Wei Liu wrote: > >> > > >> > Hi Julian > >> > > >> > For the KDD related project I have CC'ed Paul. > >> > > >> > I have gathered some ideas for cleaning up hypervisor code but they > are > >> > of lower difficulty compared to other projects. They are definitively > >> > not as fun as the others. ;-) > >> > > >> > Wei. > >> > > >> > On Mon, Sep 09, 2019 at 08:58:51AM +0100, Julien Grall wrote: > >> > > +Andrew, Lars, Stefano and Wei > >> > > > >> > > On 9/5/19 11:23 PM, Julian Tuminaro wrote: > >> > > > Hi, > >> > > > >> > > Hello, > >> > > > >> > > Thank you for you interest on Xen. I have CCed few more person that > should > >> > > be able to answer your questions below. > >> > > > >> > > > > >> > > > We (a group of 2 students) are interested in doing a hypervisor > related > >> > > > project for the next 10-12 weeks as part of one of our courses > this > >> > > > semester. We have taken a look at this year's GSoC project list > >> > > > (https://wiki.xenproject.org/wiki/Outreach_Program_Projects). We > were > >> > > > interested in learning more about the "KDD (Windows Debugger Stub) > >> > > > enhancements" project and Xen on ARM based projects. Yet, on irc > we were > >> > > > told that this list is outdated. If there are any other project > >> > > > suggestions or list, we would be interesting in learning more > about > >> > > > them. > >> > > The list of projects for Xen on Arm is mostly update-to-date. The > only > >> > > project where some progress has been made so far is "Xen on ARM: > dynamic > >> > > virtual memory layout". > >> > > > >> > > I would be happy to go in more details for any those projects if > you are > >> > > interested. > >> > > > >> > > > > >> > > > Andrew Cooper suggested on irc the following project: Context > Switching > >> > > > with CR0.TS in HVM Guest. We would like to possible know more > about this > >> > > > project in terms of difficulty, potential estimate on time > required. > >> > > > Andrew also mentioned a slighter bigger xen/linux project and we > would > >> > > > like to know more detail about this one as well. > >> > > > >> > > Cheers, > >> > > > >> > > -- > >> > > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Looking for Semester long Project
Hi Paul, Thanks for getting back to us in regards to the KDD project. I am trying to understand the current status of the project. Could you provide a bit more information on the current status and what would need to be done. Julian On Mon, Sep 16, 2019 at 5:53 AM Paul Durrant wrote: > I think KDD is still a worthy thing to do, particularly in light of > https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg01723.html > (which is about the most recent ref I could find, and I don't know > what happened to the code after that). AFAIK, the biggest challenge is > getting round Windows' KASLR; it may be necessary to have some sort of > driver in the guest to get the necessary info. out but that shouldn't > be too hard to implement. > > Cheers, > > Paul > > On Mon, 16 Sep 2019 at 11:39, Wei Liu wrote: > > > > Hi Julian > > > > For the KDD related project I have CC'ed Paul. > > > > I have gathered some ideas for cleaning up hypervisor code but they are > > of lower difficulty compared to other projects. They are definitively > > not as fun as the others. ;-) > > > > Wei. > > > > On Mon, Sep 09, 2019 at 08:58:51AM +0100, Julien Grall wrote: > > > +Andrew, Lars, Stefano and Wei > > > > > > On 9/5/19 11:23 PM, Julian Tuminaro wrote: > > > > Hi, > > > > > > Hello, > > > > > > Thank you for you interest on Xen. I have CCed few more person that > should > > > be able to answer your questions below. > > > > > > > > > > > We (a group of 2 students) are interested in doing a hypervisor > related > > > > project for the next 10-12 weeks as part of one of our courses this > > > > semester. We have taken a look at this year's GSoC project list > > > > (https://wiki.xenproject.org/wiki/Outreach_Program_Projects). We > were > > > > interested in learning more about the "KDD (Windows Debugger Stub) > > > > enhancements" project and Xen on ARM based projects. Yet, on irc we > were > > > > told that this list is outdated. If there are any other project > > > > suggestions or list, we would be interesting in learning more about > > > > them. > > > The list of projects for Xen on Arm is mostly update-to-date. The only > > > project where some progress has been made so far is "Xen on ARM: > dynamic > > > virtual memory layout". > > > > > > I would be happy to go in more details for any those projects if you > are > > > interested. > > > > > > > > > > > Andrew Cooper suggested on irc the following project: Context > Switching > > > > with CR0.TS in HVM Guest. We would like to possible know more about > this > > > > project in terms of difficulty, potential estimate on time required. > > > > Andrew also mentioned a slighter bigger xen/linux project and we > would > > > > like to know more detail about this one as well. > > > > > > Cheers, > > > > > > -- > > > Julien Grall > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] Looking for Semester long Project
Hi, We (a group of 2 students) are interested in doing a hypervisor related project for the next 10-12 weeks as part of one of our courses this semester. We have taken a look at this year's GSoC project list ( https://wiki.xenproject.org/wiki/Outreach_Program_Projects). We were interested in learning more about the "KDD (Windows Debugger Stub) enhancements" project and Xen on ARM based projects. Yet, on irc we were told that this list is outdated. If there are any other project suggestions or list, we would be interesting in learning more about them. Andrew Cooper suggested on irc the following project: Context Switching with CR0.TS in HVM Guest. We would like to possible know more about this project in terms of difficulty, potential estimate on time required. Andrew also mentioned a slighter bigger xen/linux project and we would like to know more detail about this one as well. Thanks, Julian ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
