[racket-dev] fuzz testing the bytecode reader

Carl Eastlund wrote at 10/19/2010 04:51 PM:
> Caveat Emptor: be wary of running code designed to produce random, unsafe results if the computer you are running it on has any data you really care about.

KVM+QEMU virtual machines are good for dangerous fuzz testing.

You can chain copy-on-write (COW) drives to make setting up and running 
the tests in clean, safe environments easy and (in some ways) fast:

Example, just to give to give the flavor to people who haven't used QEMU 
and KVM before:

* One "unchanging" COW drive with your Linux install and other things 
that don't change often.  This drive is represented as a normal file on 
any host Linux filesystem.

* When you want to test a build, make a "build" COW drive linked to the 
"unchanging" drive.  Start a VM and do your build on that drive.

* For every test or set of tests for which you want a clean, safe 
environment, make a COW drive linked to "build" and use that for the 
tests.  (You might use a RAM disk for this last layer of COW, to avoid 
real disk writes.)

Note that, if you're using lots of fresh VMs for tests, rather than 
doing your test suite in one VM, you do have to wait for each VM to boot 
Linux.  But if you have multiple cores, you can be running VMs in 
parallel, or just starting them up in parallel.

All these things can be done from simple command-line tools or library 
calls.

Whatever you do, avoid XenServer.  XenServer is a favorite of 
pointy-haired "enterprise" IT managers who want to say the 
"virtualization" buzzword and have a cheaper way to let people run MS 
Word, but KVM is so much easier to work with.  Also, in kernel 
evolution, KVM is preferred over Xen.

-- 
http://www.neilvandyke.org/