This blog post was written by Felix Schmoll, currently studying Mechanical Engineering at ETH Zurich. After obtaining a Bachelor in Computer Science from Jacobs University he spent the summer working on fuzzing the hypervisor as a Google Summer of Code student. His main interests in code are low-level endeavours and building scalable applications.
Five months ago, I had never even heard of fuzzing, but this summer, I worked on fuzzing the Xen Project hypervisor as a Google Summer of Code student.
For everybody that is not familiar with fuzzing: it is a way to test interfaces. The most primitive form of it is to repeatedly generate random input and feed it to the interface. A more advanced version is coverage-guided fuzzing, which uses information on the code path taken by the binary to permute the input further. The goal of this project was to build a prototype of fuzzing the hypercall-interface, seeing if one could make the hypervisor crash with a definite sequence of hypercalls.
American Fuzzy Lop (AFL) is by far the most popular fuzzer, and so it was chosen as the one to be run on the hypervisor. As it is a fuzzer for user-space programs, it had to be ported to the kernel. To make this work, the first step was to allow it to obtain feedback on the coverage from Xen by implementing a hypercall. Further, a mechanism was needed to execute the hypercalls from a domain other than dom0 (there are many ways to stop the hypervisor from dom0). For this purpose, an XTF-test case was instrumented to run as a server, receiving test cases from an AFL-instance. In the end, changes were made to the hypervisor, libxl, xenconsole, XTF and AFL.
The biggest challenge of all was finding my way around the code base of Xen. A lot of components were relevant to the project, and it would be unrealistic to expect anybody to read all of the code at once. While documentation was at times scarce, a helpful community of experts was always available on IRC. It was also a great experience to meet these people at the Xen Project Summit in Budapest.
The result of my summer project are numerous patches. While there were no bugs actually found (i.e. the hypervisor never crashed), valuable experience was collected for future projects. I am confident that by building up on the prototype it will be possible to improve the reliability of Xen. A first step would be to pass the addresses of valid buffers into hypercalls. For a description of more possible improvements please read the technical summary of the project.
Lastly, I would like to thank everybody involved with GSoC, Xen Project and in particular my great mentor Wei Liu for allowing me to experience how it is to work on a well-lead open-source project.
Read more
In safety-critical industries like automotive and industrial systems, trust is non-negotiable. When building software that controls critical hardware, like braking systems or factory automation, you need confidence. The software must behave exactly as intended. Every time. On the actual device. That's why the Xen Project is investing in
The annual Xen Summit is right around the corner, and there has never been a more exciting time to be part of the Xen Project. As enterprise and industrial needs shift and proprietary vendors rethink their licensing, the industry is ready for strong, open alternatives. Xen stands out not only
Xen is open, secure, and built for the future. As the new Community Manager, I’m focused on growing the Xen community, welcoming new contributors, and ensuring a thriving ecosystem. Let’s build the future of virtualization together!
The Xen Project has released Xen 4.20 🎉! This release introduces a range of enhancements that further solidify its position as the premier open-source hypervisor. It delivers important security updates, improved performance, and broader hardware support. Xen has doubled down as the best choice for cloud providers, enterprise users, and