diff --git a/docs/revised-stream-4-language.md b/docs/revised-stream-4-language.md index a0c47f1..efc1a7b 100644 --- a/docs/revised-stream-4-language.md +++ b/docs/revised-stream-4-language.md @@ -6,7 +6,7 @@ This is a draft of revised language for Stream 4 - Memory Safety of the [Open So It is common for vulnerabilities to result from a program mismanaging memory. These types of vulnerabilities are called memory safety vulnerabilities. -Some programming languages, including Rust, Go, and Java, are commonly referred to as "memory safe languages". By default, these languages prevent programmers from making the mistakes that result in classes of memory safety vulnerabilities. Other languages, including C and C++, are commonly referred to as "memory unsafe languages". Be default, these languages do not prevent programmers from making the mistakes that result in classes of memory safety vulnerabilities. +Some programming languages, including Rust, Go, and Java, are commonly referred to as "memory-safe languages". By default, these languages prevent programmers from making the mistakes that result in classes of memory safety vulnerabilities. Other languages, including C and C++, are commonly referred to as "memory unsafe languages". Be default, these languages do not prevent programmers from making the mistakes that result in classes of memory safety vulnerabilities. Microsoft estimates that 70% of the vulnerabilities in its products (those that were built with memory unsafe languages) over the past decade are memory safety vulnerabilities[^1]. Google estimates that 90% of vulnerabilities in Android media and Bluetooth components are memory safety vulnerabilities[^2]. @@ -23,18 +23,18 @@ In their information sheet on Software Memory Safety, the National Security Agen Unlike many other types of vulnerabilities, we know how to massively reduce (if not outright remove) complete classes of memory safety vulnerabilities. Whenever possible or practical, software should be written in or moved to programming languages which, in their default settings, prevent memory safety vulnerabilities. -For existing code bases that are not able to move away from memory unsafe by default languages, there are tools and specifications which can reduce memory safety vulnerabilities. These tools and specifications should continue to be developed. Software that cannot be moved to a memory safe by default language should use these tools and move to these specifications. +For existing code bases that are not able to move away from memory unsafe by default languages, there are tools and specifications which can reduce memory safety vulnerabilities. These tools and specifications should continue to be developed. Software that cannot be moved to a memory-safe by default language should use these tools and move to these specifications. The work we plan to do to reduce the number of memory safety vulnerabilities consists of five parts. -1. Wherever possible, move the internet’s most critical software to memory safe by default languages with an efficient strategy that emphasizes upgrading the most security-sensitive components first. -2. Invest in the tools that allow systems engineers to move lower-level systems-level code to a memory safe by default language. This will allow us to have impact beyond just the most critical projects. We will focus on tools for systems-level code because it is the most ubiquitous and vulnerable software in the ecosystem, and it is the most likely to be written in memory unsafe by default languages. +1. Wherever possible, move the internet’s most critical software to memory-safe by default languages with an efficient strategy that emphasizes upgrading the most security-sensitive components first. +2. Invest in the tools that allow systems engineers to move lower-level systems-level code to a memory-safe by default language. This will allow us to have impact beyond just the most critical projects. We will focus on tools for systems-level code because it is the most ubiquitous and vulnerable software in the ecosystem, and it is the most likely to be written in memory unsafe by default languages. 3. Invest in tools/specifications that improve memory safety when a migration to a memory safe by default language is not possible [^5]. 4. Invest in educating software engineers at all levels about the importance of memory safety and that skills for reliably and securely engineering computer software are critical [^5]: https://github.com/isocpp/CppCoreGuidelines -### Moving critical software infrastructure to memory safe by default languages +### Moving critical software infrastructure to memory-safe by default languages This component of our strategy will rely on [Prossimo](https://www.memorysafety.org/), a project run by the nonprofit [Internet Security Research Group (ISRG)](https://www.abetterinternet.org/). The Prossimo project works to identify the most critical software infrastructure that needs to be moved to a memory safe by default language, plan effective and efficient migrations with stakeholders, and oversee execution of the plans. @@ -48,7 +48,7 @@ The top-level risk criteria that Prossimo uses to identify potential investments Of software that fits those criteria, the following opportunity criteria are evaluated: 1. Is this a library or component that can be used in many different projects? -2. Can we efficiently replace key components with existing memory safe libraries? +2. Can we efficiently replace key components with existing memory-safe libraries? 3. Are funders willing to fund the work? 4. Are the maintainers on board and cooperative? @@ -58,13 +58,13 @@ Based on all of the above criteria, there are Prossimo initiatives underway for Much of the world’s most ubiquitous and critical software is lower-level systems software that underlies almost every computing device in the world (e.g. kernels, basic networking functionality, timekeeping). It’s in banks, hospitals, and government systems. This software is typically written in a memory unsafe by default language called C, because for much of computing history C was the go-to language for systems software development. -Because lower-level software has more operational constraints than higher-level software (e.g. it typically cannot tolerate a runtime or memory management via garbage collection), developing a memory safe language suitable for systems software is particularly challenging. The Rust language has met that challenge, however, and is an excellent candidate for replacing C in many systems applications. +Because lower-level software has more operational constraints than higher-level software (e.g. it typically cannot tolerate a runtime or memory management via garbage collection), developing a memory-safe language suitable for systems software is particularly challenging. The Rust language has met that challenge, however, and is an excellent candidate for replacing C in many systems applications. -We plan to invest in the tools that allow systems engineers to move their software to Rust. This means investing in improving package management, compilers, and Foreign Function Interface (FFI) generators. In many cases this will include providing interfaces compatible with existing widely-used components to enable transition. With these tools, adoption of a memory safe by default alternative will scale much faster without replication of efforts. We also propose to invest in similar efforts in the Go and Java communities. Both languages are frequently used for systems-level and network applications, including in security-sensitive environments. We propose to reach out to the community through a series of grant-making efforts focused on the same priorities and criteria described above, initially targeting existing projects that need an extra push to get to a production release and adoption and those that may help other workstreams in this plan. These investments will be made primarily via ISRG, the Rust Foundation for Rust-related work, the Eclipse Foundation for Java-related work, and independent grants for Go-related work. +We plan to invest in the tools that allow systems engineers to move their software to Rust. This means investing in improving package management, compilers, and Foreign Function Interface (FFI) generators. In many cases this will include providing interfaces compatible with existing widely-used components to enable transition. With these tools, adoption of a memory-safe by default alternative will scale much faster without replication of efforts. We also propose to invest in similar efforts in the Go and Java communities. Both languages are frequently used for systems-level and network applications, including in security-sensitive environments. We propose to reach out to the community through a series of grant-making efforts focused on the same priorities and criteria described above, initially targeting existing projects that need an extra push to get to a production release and adoption and those that may help other workstreams in this plan. These investments will be made primarily via ISRG, the Rust Foundation for Rust-related work, the Eclipse Foundation for Java-related work, and independent grants for Go-related work. ### Invest in tools and specifications that improve memory safety when migration is not possible -When movement to a memory safe by default language is not possible, we will invest in tools that improve memory safety in C and C++ code bases - including specifications and automated tools. +When movement to a memory-safe by default language is not possible, we will invest in tools that improve memory safety in C and C++ code bases - including specifications and automated tools. TO DO - need examples.