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

To: "Brendan Cully" <brendan@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 1/3] Add support for OpenBSD
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Wed, 18 Oct 2006 19:13:46 +0100
Delivery-date: Wed, 18 Oct 2006 11:14:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AC9CC971-B2CA-422F-9FD8-FA6AB11295C3@xxxxxxxxxxxxx><C15C1753.2BF4%Keir.Fraser@xxxxxxxxxxxx> <20061018174719.GA15919@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acby3a/aDECZmedvR5m/sMv8xcP5FwAAXysg
Thread-topic: [Xen-devel] [PATCH 1/3] Add support for OpenBSD
> > 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. 

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.

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!

Thanks,
Ian







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