WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 1/3] Add support for OpenBSD

On Wednesday, 18 October 2006 at 19:13, Ian Pratt wrote:
> > > I don't think stack-smashing attacks are a worrying vulnerability
> for
> > Xen.
> > > We don't do much variable-sized buffer manipulation, strcpy, and so
> on.
> > I'd
> > > much rather see someone put some effort into something more likely
> to be
> > > useful (albeit undoubtedly more work!) like randomised attacks on
> the
> > > hypercall interfaces.
> > 
> > I built something to do that for a course project a few months ago -
> > basically a kernel module to pass along completely unchecked
> > hypercalls, generated by a python script with a few hooks to filter
> > out those that it knew Xen would catch anyway. It even managed to
> > crash xen periodically, but I never quite finished the piece that was
> > supposed to reproduce crashes after they happened. I guess I should
> > clean it up and post it somewhere...
> 
> That would certainly be helpful -- thanks!
> I suspect you could get the most mileage with this by saving the domain,
> then having a loop that restores it and kicks off the test with a
> different seed. This should enable much faster cycling than having to
> boot the VM every time Xen decides to terminate it for misbehaving. 

That's exactly what it did.

> Many of the more complex situations come about by having complex
> pagetable structures etc that are almost valid but have subtle bugs.
> Generating these scenarios by hand is going to be tough. I think that
> possibly fault injection is the best way of handling these, perhaps
> having a special guest kernel module that runs off the ticker and tries
> to do interesting corruptions to pagetables. We could also arrange to
> corrupt hypercall arguments one time in a thousand or something.

Yes, 'almost correct' is the hard part, and page table manipulation
from userspace needs a bit more help than I ever put into my
module. But I don't think it would be that much work to export them,
let userspace fiddle with them a bit, and reload them.

> It would be *great* if someone could work at this sort of testing. It
> may not sexy as some of the other security work that's going on, but
> would be incredibly valuable to the project. Please could someone step
> forward!

I don't know if I've got the time for it in the near term, but if
anyone's interested, the code I wrote (such as it is) is available at
http://hg.kublai.com/monkey

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel