Multi-Architecture Support
Problem Summary
Many critical infrastructure systems run on esoteric architectures (arm, ppc, power, mips, spare, eris, black fin, etc.) that are poorly documented, and at times were designed by companies who have since gone out of business. Some are also extraordinarily expensive to acquire, and typically require several NDAs to even get a look at any relevant source or engineering resources. Even the generally healthy and well supported qemu project that can emulate some of these systems can be painful to use. Non x86_64 architectures in the qemu project receive an order of magnitude less development attention and can be extremely difficult to configure correctly, making one of the most potentially useful tools in a security researchers tool-belt significantly less useful.
Additionally, no cloud infrastructures natively support orchestration using qemu when the host architecture doesn’t match the guest architecture, making techniques like distributed fuzzing significantly more difficult.
Proposal Summary
The Georgia Cyber Center proposed the following activities to address these shortcomings:
-
Ensure that libvirt no longer assumes that the host architecture = the guest architecture and will intelligently choose the qemu binary based on the reported architecture of a given image.
-
Ensure that the widely-used and open-source OpenStack project can take advantage of the improvements in qemu and libvirt.
-
Ensure that the contributions are designed in accordance with the respective project design guidelines so that they are supportable and may be maintained by their respective communities for years to come.
The above three goals will be achieved by submitting upstream code contributions to qemu, libvirt, OpenStack Nova, OpenStack Glance, and OpenStack Tempest. All developed products will have an open source license (Apache 2.0) and be freely available for use.