Mailing List Archive

> I'm inviting other opinions on how we could move the project forward.  I
> suspect most participants are still very interested, but also very busy on
> other projects.  If anyone else has an update, please let us know.

I agree with a lot of Steve's points. However, perhaps I can add a
bit to this discussion.

* I have continued the development of XenAccess. However, this
process has been slow because I basically fit it in when I have some
spare time. I believe that XenAccess could serve as the foundation
for an "official" Xen introspection effort if this is what the
community wants. After all, it is the only current open source
solution available. To get there I think that we would need to smooth
out some of the edges (fix some bugs, add some important features).
And, of course, this is strictly a passive monitoring solution right
now.

* For active monitoring (i.e., memory-based triggers / typed shadow
page tables / etc), I have been in contact with someone who may be
interested in working with me to implement this feature. We are
currently in the very preliminary stages, but I'm hopefully that this
will evolve into a hypervisor patch that would ultimately allow us to
add active monitoring functionality into XenAccess.

* I would be interested in receiving feedback from the community as to
their interest level in seeing XenAccess matured and integrated with
Xen versus keeping it as a separate project. Perhaps this goes
towards understanding the overall goals of those who are interested in
introspection with Xen.

* I have heard from many people in the community that they are
interested in seeing an introspection solution for Xen. Perhaps
something like VMSafe. However, I have yet to see any solid
commitment from anyone to help make this happen. I am, of course,
personally interested in seeing this come together, and will continue
working on it when I can, but without outside support it will be slow.


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

_______________________________________________
Xen-introspect mailing list
Xen-introspect@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-introspect

> The second problem is the difficulty in altering the hypervisor for
> those of us unfamiliar with it. For example, we spent about a hundred man-hours
> trying to implement "memory trigger" functionality, but had to abandon
> the effort. I think the group needs some level of dedicated support from
> XenSource or Citrix to answer questions.

I think you'll find that folks like Tim Deegan and Gianluca Guida would be very helpful in reviewing design proposals and commenting on patches.

I'd very much like to see the ability to add type-codes to pages that enable synchronous and asynchronous triggers[*] to be delivered to a "monitor application" when pages are accessed, written, or executed[**]. These events can be captured through a fairly simple modification to the HAP and shadow code, and then delivered to the nominated monitor application in a manner very similar to the mechanism used for delivering IO and MMIO events to qemu-dm.

Best,
Ian

[*] Synchronous triggers block the VCPU until a response from the monitor application is received, whereas asynchronous triggers may be queued until the queue fills.

[**] I'd also add a special fast-path page-type that marks a page as executable-but-read-only, but allows it to automatically revert to the writeable-but-not-executable page type without requiring a synchronous trigger to manually changing the page type.



_______________________________________________
Xen-introspect mailing list
Xen-introspect@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-introspect

> Personally I'd like to see it upstream and promoted as a core API. I think we just need to get a bit of momentum behind this and then it will snowball and folks like security vendors will get involved.

I'd be happy to work in this direction. What would be the best way to
proceed with something like this? Should we ultimately provide a
patch to xen-devel? If so, how stable (with regard to features...
code stability seems to be quite good right now from my experiences)
should XenAccess be before we take that step? Are there particular
features and/or coding standards that we would need to provide to
integrate more cleanly with Xen?

Cheers,
bryan


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

_______________________________________________
Xen-introspect mailing list
Xen-introspect@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-introspect

> > Personally I'd like to see it upstream and promoted as a core API. I
> think we just need to get a bit of momentum behind this and then it will
> snowball and folks like security vendors will get involved.
>
> I'd be happy to work in this direction. What would be the best way to
> proceed with something like this? Should we ultimately provide a
> patch to xen-devel? If so, how stable (with regard to features...
> code stability seems to be quite good right now from my experiences)
> should XenAccess be before we take that step? Are there particular
> features and/or coding standards that we would need to provide to
> integrate more cleanly with Xen?

Posting to xen-devel soner rather than later is definitely worthwhile to get some more exposure and feedback. It would be great if that could then prompt some factoring of common code with Mukesh's debugger.

Thanks,
Ian

_______________________________________________
Xen-introspect mailing list
Xen-introspect@lists.xensource.com
http://lists.xensource.com/mailman/listinfo/xen-introspect