Patchwatcher security improvements

[Ambroz Bizjak]

Francois Gouget wrote:
> This seems like an almost perfect task for a virtual machine:
>  * set up you virtual machine to taste
>  * take a snapshot
>  * to test a patch, fire up the virtual machine
>  * have it test the patch
>  * after the test or when it times out, revert it to the snapshot *
rinse (done in the step above), repeat
>
> This could be done with VirtualBox, but maybe other alternatives based
on Xen or KVM or some such would be better. The main issue I see with this
is that the OpenGL / DirectSound tests will not run on the real hardware
(as usual), but maybe a Xen-like approach could help there.
>
> It would also make it easy to test on FreeBSD / Solaris, at least if
based on something like VirtualBox (not sure about the Xen-like
> approaches).

Seems like a good idea. I suggest only to use Linux as the host OS and run
guests with KVM or VirtualBox, or even UML for Linux builds. Then we can
run any OS that uses X as a guest and configure it to use the host's X
display (through the virtual network). This should theoretically allow
OpenGL through the XGL protocol, but VMGL can also be used if it doesn't
work well. And sound hardware would be emulated by the VM software.

I think I'll try getting a small Gentoo system to run in UML with a
read-only root fs and make it boot as fast as possible. To try a patch, I
would give it read access to the master Wine tree on the host, it would
copy it to a writable temp folder and try it out. After it's finished or
if the external timeout elapses, the UML process will be terminated and
all of its writable storage will be reverted.