[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Looking for Semester long Project



Julian,

 

  The current status, as I said, is that the code has not been touched for many years and I don’t actually know if it is functional against older versions of Windows as it stands.

  The kd protocol is a packet protocol and windbg is essentially in control; issuing commands to dump registers, memory etc. Setting normal breakpoints would indeed mean modifying guest memory and then dealing with the ensuing int3s. You may also get requests from windbg to use debug registers.

  I *think* the main issue with post-Windows 7 is going to be KASLR, but there may be a way to ask Windows to turn it off for debugging purposes without actually turning on full debug mode… I don’t know. Even if Windows does need to be put in debug mode, using kdd would be preferable to setting up emulated serial.

 

  Paul

 

From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Julian Tuminaro
Sent: 16 September 2019 17:56
To: Paul Durrant <pdurrant@xxxxxxxxx>
Cc: Lars Kurth <lars.kurth@xxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; paul@xxxxxxx; Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Julien Grall <julien.grall@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
Subject: 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 <pdurrant@xxxxxxxxx> 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 <jtuminar@xxxxxxxxxxxxxx> 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 <pdurrant@xxxxxxxxx> 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 <wl@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.