Open Source Security, Inc. Announces Funding of GCC Front-End for Rust
Open Source Security, Inc is proud to announce its funding of a full-time and public development effort of a GCC front-end for Rust. In this blog post, we'll detail the motivations for our involvement and the benefits the public will reap as a result of this effort.
A Security Need
In July of last year, shortly after my virtual presentation at the Linux Security Summit North America entitled "10 Years of Linux Security - A Report Card", we put out a call to other companies interested in funding a GCC front-end for Rust. The motivation for this arose from outreach from Nick Desaulniers of Google on LKML to discuss the possibility of Rust support in the Linux kernel at the upcoming Linux Plumbers Conference. One obvious hurdle mentioned immediately was that the kernel is most commonly compiled with GCC, while Rust currently requires rustc/LLVM. According to reports of the resulting discussion, kernel developers were open to the idea of allowing the kernel to be built with GCC and the Rust portions with LLVM, as long as the two were ABI compatible.
Such discussions appeared to sidestep a more fundamental issue however: the security viability of a mixed assembly/C/Rust execution environment and how cohesive security functionality could be provided while mixing different compilers with different implementations/availability of said functionality. The importance of this topic, though apparent on reflection, was formalized just recently in a paper by Michalis Papaevripides and Elias Athanasopoulos of the University of Cyprus entitled "Exploiting Mixed Binaries". In it, they detail how the overall security of an execution environment can be reduced by the introduction of code written in Rust or that of another language where the same binary-level security is not provided by the compiler. An excerpt from page 3 of the paper makes the impact clear:
"We experimentally show that CFI can be bypassed using Rust/Go code for developing clearly more straight-forward exploits than current state-of-the-art CFI bypasses [57, 70]. Our exploits do not rely on respecting the statically computed Control-flow Graph (CFG) for bypassing the enforced CFI and are much simpler to implement. [ ... ] Again, we stress here that in the absence of the safe part (Rust/Go code), the unsafe part cannot be trivially exploited."
The same exact scenario above was one of the motivations for Microsoft to recently push for their Control Flow Guard (CFG) support in Clang and Rust (see the heading of "Rust linked with C/C++").
As the source of the GCC plugin infrastructure in the Linux kernel and nearly all of the GCC plugins adapted for inclusion in the upstream Linux kernel, we too immediately spotted the importance of this problem and set out to ensure both those plugins as well as the security features built-in to GCC itself are able to instrument code from all languages supported by the Linux kernel with compatible and consistent security properties.
Funding Process
So despite not expecting Rust code to land in the Linux kernel in the near future, we reached out to other companies as mentioned above to pull together funding for the GCC front-end effort. None of the leads came to fruition, so we as a company decided to bootstrap the process, in the hopes that as progress in the work is observed, others would join in. Further, we wanted to offer funding under the same terms we would want as developers, across the entire spectrum: stability, salary, benefits, ownership, etc -- not token compensation or bounties that treat those working on free/open source software for the public as somehow less than developers of proprietary code. To that end, we decided to fund the first year of a full-time developer for the work ourselves.
If the failed experiment of the Core Infrastructure Initiative (CII) taught us anything, it's that one finds dedicated and competent developers for some work not among whoever happens to apply, but among those already involved in the work as a passion project. This led us to reach out to Philip Herron, who we noticed was already working on a GCC front-end for Rust with involvement of external contributors. We were extremely pleased to hear Philip was interested in performing the work full-time.
News of our outreach eventually extended to the GCC Steering Committee, who contacted us to coordinate efforts. They were very helpful in recommending to us Embecosm, a UK-based company with deep experience and involvement in GCC/LLVM development, among many other areas. Embecosm graciously offered to contribute to the effort by handling Philip's employment and, at no cost to us, providing project management services to help ensure the project's success. The location, expertise, and sharing of our vision of doing right by the developer couldn't have been a better match.
Vendor-Neutral, Developed in the Open
To make sure the project remains vendor-neutral and in the public interest, Open Source Security, Inc. will not own any of the copyright over the code developed through its funding. All relevant GCC code for the project is GPLv3-licensed and copyright is assigned, as required for upstream GCC inclusion, to the Free Software Foundation (FSF). The work is being performed in the open, with Philip providing public monthly status updates on GitHub at https://github.com/Rust-GCC/Reporting. Reports are already available for the months of November and December.
Get Involved
For more information about the "how" of this effort, Embecosm has prepared a blog at https://www.embecosm.com/2021/01/12/gcc-rust-how-it-can-be-achieved/ that we encourage all those interested to read. To get involved in contributing technical work to the effort, Philip can be found on Twitter at @the_philbert or committing to the project's Github repository at https://github.com/Rust-GCC/gccrs. To discuss additional funding of the work, please reach out to us at contact@opensrcsec.com.
Brad Spengler
President, Open Source Security, Inc.