For those who haven’t heard about the Xen 0wning Trilogy, make sure to check that out here and here.
In a followup post to some apparent misinformation being spread (Microsoft executive “rebuts” our research!), I was surprised by this comment:
Interestingly, if Mr. Riley only attended our Xen 0wning Trilogy at Black Hat, then he would notice that we were actually very positive about Hyper-V. Of course, I pointed out that Xen 3.3 certainly has a more secure architecture right now, but I also said that I knew (from talking to some MS engineers from the virtualization group) that Hyper-V is going to implement similar features in the next version(s) and that this is very good. I also prized the fact it has only about 100k LOC (vs. about 300k LOC in Xen 3.3).
Xen 3.3 has grown to 300k lines of code for the hypervisor?
At what point does the “tight security auditability” argument start to exponentially diminish for hypervisors in ring 0?
In the Virtual Workspace Service TP1.2.2 (just released) we used EasyMock for unit tests:
http://www.easymock.org
“EasyMock provides Mock Objects for interfaces in JUnit tests by generating them on the fly using Java’s proxy mechanism. Due to EasyMock’s unique style of recording expectations, most refactorings will not affect the Mock Objects.”
I am pretty happy with this package. For testing our internal state transition logic I could pre-record the exact methods on the task object that were expected to be called (including argument matching) for a certain transition, test that the expectations were met, and simultaneously test that the wrong tasks were not called.
We have around 30 internal states, around 15 types of tasks, and the tasks are launched out of band via work queue threads, so it was helpful to abstract out as much as possible and just concentrate on testing the transitions and the resulting tasks that were launched.
Having internal subsystem plugins that are instantiated via JNDI helped. Using a test JNDI config to override a factory implementation with a new one that returns mock objects, it was straightforward to isolate the code under test.
This will be good for testing a lot of things: it’s designed expressly to let you mock up the “collaborators” of a subsystem and make sure the interactions are correct without running code in the subsystems that are not being tested.
