1. Harvesting Free Windows CPU Cycles for Linux Applications using Sandboxing Rasmus Andersen Dept. of Computer Science, University of Copenhagen, Denmark

2. Motivation ➢ One of the Grid promises: “Effectively share resources on an unprecedented scale“ But what about all those idle windows CPU cycles? ➢ We still need Screen Saver Science and a secure sandbox to provide us Linux cycles on idle windows CPU's

3. Basic Idea ➢ A sandbox provides an isolated environment in which applications can do no harm (ideally) ➢ So, we build our own linux iso-image, or modify an existing image, to fit our Grid, and run it in a sandbox. ➢ When the image is booted, it initiates itself as a Grid resource

4. MiG Introduction ➢ The MiG model: www.migrid.org

5. Resource Requirements ➢ “Minimum intrusion” implies: No root install of software on the resource No requirements on the firewall configuration ➢ All we need is a local grid user and an ssh-connection ➢ Thus everything must run in user space

6. Sandbox Security Issues ➢ Security regarding executing applications in a Grid is two- ways: ➢ From resource owner POV: Am I affected by executing an unknown, possibly malicious, application? ➢ From user POV: Can I trust the application result from an unknown remote resource?

7. Sandbox Options: Emulator or Virtual Machine ➢ Emulation: ➢ Provides the desired CPU functionality in user space software by translating all instructions (=> performance drawback) ➢ Highly generic, one architecture can be emulated on a completely different architecture ➢ Bochs, Qemu, etc.

8. Sandbox Options: Emulator or Virtual Machine ➢ Virtualization: ➢ Direct, native execution by partitioning hardware into multiple contexts ➢ Not generic: Need specific hardware architecture! ➢ Runs in kernel space, thus insecure and intrusive (two kernels at the same protection level enables the guest kernel to compromise the host)) ➢ Xen, coLinux, etc.

9. Sandbox Options: Emulator or Virtual Machine ➢ A Hybrid, a user space virtual machine, is the best of both worlds: ➢ Qemu + accelerator module ➢ MS Virtual PC ➢ VMWare Player ➢ All proprietary products

10. Qemu ➢ Qemu is an open source emulator ➢ Runs on x86, x86_64, and PowerPC ➢ Emulates x86, x86_64, PowerPC, ARM, SPARC, and MIPS ➢ Supports many OSes (Linux, windows, Solaris, SkyOS, Minix). ➢ So, we build an MiG linux distribution to start in Qemu!

11. Requirements to the MiG Linux Distribution ➢ Take any working linux distro and add what's required in MiG: ➢ ssh and https/openssl ➢ In MiG, every participant must present himself with a certificate, and data transfers are handled using ssh. ➢ Hence, we built permant storage where we can put individual certificates and ssh-keys.

12. Work Flow ➢ When the screen saver starts, Qemu is initiated and the specified OS is booted ➢ During boot, the hard disk image file is mountet ➢ Finally, the MiG resource startup scripts are initiated, and the resource starts accepting linux jobs.

13. Execution Time ➢ When does the screen saver stop? ➢ MiG SSS module makes a guess ➢ Suspend and migrate? ➢ Not possible to suspend Qemu ➢ Mobile occam-pi processes can migrate

14. Conclusion ➢ The sandbox effectively uses idle windows CPU cycles ➢ Users can choose which sandbox they want ➢ The MiG linux distribution is working and occupies less than 3 MB, the user chooses the size of the hard disk image ➢ The host system cannot be compromized