From e4bfd92165b4a4d0cb22dc6334b26b01ad48ed6a Mon Sep 17 00:00:00 2001 From: Avishay Balter Date: Fri, 9 Aug 2024 11:44:02 +0100 Subject: [PATCH] PR comments Signed-off-by: Avishay Balter --- docs/memory-safety-continuum.md | 97 ++++++++++++++++++--------------- 1 file changed, 53 insertions(+), 44 deletions(-) diff --git a/docs/memory-safety-continuum.md b/docs/memory-safety-continuum.md index 032e9ea..1290d1a 100644 --- a/docs/memory-safety-continuum.md +++ b/docs/memory-safety-continuum.md @@ -16,48 +16,49 @@ Rather than using terms like "Memory Safe Language" and "Memory Unsafe Language" ## The Continuum - Understanding Where Your Software Is Now -This continuum, from "least safe" to "most safe", is intended to help you define and understand the memory safety of your software and what you can do to improve it. We propose that developers and organizations should use modern toolchains and follow current best practices for their software ecosystems. In particular, whenever, there is a memory safe feature or workflow, it should be adopted over a non-memory safe variant. +This continuum, from "most safe" to "least safe", is intended to help you define and understand the memory safety of your software and what you can do to improve it. We propose that developers and organizations should use modern toolchains and follow current best practices for their software ecosystems. In particular, whenever, there is a memory safe feature or workflow, it should be adopted over a non-memory safe variant. The next section details the continuum for both memory safe by default languages and non-memory safe by default languages, since they cannot be compared directly. -* Using a non-memory safe by default language (such as C or C++) without developer best practices or automated tooling to check for memory safety -* Using a non-memory safe by default language with developer best practices, but no automated tooling to check for memory safety -* Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your software's code -* Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your software's code as well as in all your software's dependencies code -* Using a memory safe by default language (such as Rust, Go, Python, Java, JavaScript, C#) without developer best practices and compiler-activated plugin, post processors etc. and without additional automated tooling that checks for memory safety. -* Using a memory safe by default language with developer best practices and compiler-activated plugin, post processors etc. but no additional automated tooling to check for memory safety -* Using a memory safe by default language with developer best practices, compiler-activated plugin, post processors etc. and additional automated tooling to check for memory safety in your software's code -* Using a memory safe by default language with developer best practices, compiler-activated plugin, post processors etc. and additional automated tooling to check for memory safety in your software's code as well as in all your software's dependencies code +### Memory safe by default language (such as Rust, Go, Python, Java, JavaScript, C#) -### Using a non-memory safe by default language without developer best practies or automated tooling +- Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code as well as in all your dependencies' code ([examples](#Using-a-memory-safe-by-default-language-with-developer-best-practices-and-automated-tooling-to-check-for-memory-safety-in-your-code-as-well-as-in-all-dependencies-code)) +- Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code only ([examples](#using-a-memory-safe-by-default-language-with-developer-best-practices-language-processors-post-processors-etc-and-automated-tooling-to-check-for-memory-safety-in-your-code)) +- Following the language's best practices that include using language processors without any additional tooling ([examples](#using-a-memory-safe-by-default-language-with-developer-best-practices-and-language-processors-post-processors-etc-but-no-automated-tooling)) +- Not following the language's best practices ([examples](#using-a-memory-safe-by-default-language-without-developer-best-practices)) -Using raw C or C++ (or old versions of C and C++ language and compiler) +### Non-memory safe by default language (such as C or C++) -### Using a non-memory safe by default language with developer best practices, but no automated tooling +- Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code as well as in all your dependencies' code ([examples](#using-a-non-memory-safe-by-default-language-with-developer-best-practices-and-automated-tooling-to-check-for-memory-safety-in-your-code-as-well-as-in-all-your-dependencies-code)) +- Following the language's best practices that include using language processors and additional automated tooling to check for memory safety in your code only ([examples](#using-a-non-memory-safe-by-default-language-with-developer-best-practices-and-automated-tooling-to-check-for-memory-safety-in-your-code)) +- Following the language's best practices that include using language processors without any additional tooling ([examples](#using-a-non-memory-safe-by-default-language-with-developer-best-practices-but-no-automated-tooling)) +- Not following the language's best practices ([examples](#Using-a-non-memory-safe-by-default-language-without-developer-best-practies-or-automated-tooling)) -Examples: +### Examples -* [Using attributes such as `cleanup` and classes when writing C](https://lwn.net/Articles/934679/) (and depending on developers to manually check this) -* Following the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines) when writing C++ -* Using the [C++ Compiler Hardening Guide](https://github.com/ossf/wg-best-practices-os-developers/tree/main/docs/Compiler-Hardening-Guides) when compiling C++ code -* Isolating code that processes un-trusted data from code that performs direct memory management operations or uses raw pointers (see [Language-theoretic Security](https://github.com/ossf/Memory-Safety/pull/20)) -* Using [smart pointers](https://learn.microsoft.com/en-us/cpp/cpp/smart-pointers-modern-cpp?view=msvc-170) +### Using a memory safe by default language with developer best practices and automated tooling to check for memory safety in your code as well as in all dependencies' code -### Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your software's code +* Using a fuzzer such as [AFL++](https://github.com/AFLplusplus/AFLplusplus) on both your own code and third party code +* TO DO - add more examples -* [Using compiler options for hardening C and C++ Code](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html) -* Using a fuzzer such as [syzkaller](https://github.com/google/syzkaller) -* Using [sanitizers](https://github.com/google/sanitizers) -* Using tools to [detect dangling pointers](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/dangling_ptr.md) -* If using Visual Studio, using the [C/C++ code analysis tool](https://learn.microsoft.com/en-us/cpp/code-quality/code-analysis-for-c-cpp-overview?view=msvc-170) -* If using Visual Studio, using the [C++ Core Guidelines checkers](https://learn.microsoft.com/en-us/cpp/code-quality/using-the-cpp-core-guidelines-checkers?view=msvc-170) +### Using a memory safe by default language with developer best practices, language processors, post processors etc. and automated tooling to check for memory safety in your code + +Examples: + +* Using the [Go Data Race Detector](https://go.dev/doc/articles/race_detector) +* Using other tools such as [govulncheck, fuzzing, and vet](https://go.dev/doc/security/best-practices) when writing Go code +* Using a mutation tester such as [cargo-mutants](https://github.com/sourcefrog/cargo-mutants) * Using [CodeQL](https://codeql.github.com/) for the [languages that CodeQL supports](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/) -* Using [BinSkim](https://github.com/microsoft/binskim) to analyze binaries * Using [DevSkim](https://github.com/microsoft/devskim) IDE extensions/language analyzers -### Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your software's code as well as in all your software's dependencies code +### Using a memory safe by default language with developer best practices and language processors, post processors etc., but no automated tooling -TO DO +Examples: -### Using a memory safe by default language without developer best practices and compiler-activated plugin, post processors etc. or automated tooling +* Following the [Rustnomicon](https://doc.rust-lang.org/nomicon/intro.html) careful practices when using unsafe blocks in Rust +* Following best practices (LINK NEEDED) when using the Go [unsafe](https://pkg.go.dev/unsafe#pkg-overview) package +* Following [Javascript Memory Management](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management) practices +* Ensuring [soundness](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) of unsafe Rust code + +### Using a memory safe by default language without developer best practices Examples: @@ -66,29 +67,37 @@ Examples: * Using compiler options which turn off some or all of the compiler's memory safety checks * Disabling .NET's source code [Analyzers](https://learn.microsoft.com/en-gb/dotnet/fundamentals/code-analysis/overview?tabs=net-8) during build -### Using a memory safe by default language with developer best practices and compiler-activated plugin, post processors etc., but no automated tooling +### Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your code as well as in all your dependencies' code -Examples: +TO DO -* Following the [Rustnomicon](https://doc.rust-lang.org/nomicon/intro.html) careful practices when using unsafe blocks in Rust -* Following best practices (LINK NEEDED) when using the Go [unsafe](https://pkg.go.dev/unsafe#pkg-overview) package -* Following [Javascript Memory Management](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management) practices -* Ensuring [soundness](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) of unsafe Rust code +### Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety in your code + +* [Using compiler options for hardening C and C++ Code](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html) +* Using a fuzzer such as [syzkaller](https://github.com/google/syzkaller) +* Using [sanitizers](https://github.com/google/sanitizers) +* Using tools to [detect dangling pointers](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/dangling_ptr.md) +* If using Visual Studio, using the [C/C++ code analysis tool](https://learn.microsoft.com/en-us/cpp/code-quality/code-analysis-for-c-cpp-overview?view=msvc-170) +* If using Visual Studio, using the [C++ Core Guidelines checkers](https://learn.microsoft.com/en-us/cpp/code-quality/using-the-cpp-core-guidelines-checkers?view=msvc-170) +* Using [CodeQL](https://codeql.github.com/) for the [languages that CodeQL supports](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/) +* Using [BinSkim](https://github.com/microsoft/binskim) to analyze binaries +* Using [DevSkim](https://github.com/microsoft/devskim) IDE extensions/language analyzers -### Using a memory safe by default language with developer best practices, compiler-activated plugin, post processors etc. and automated tooling to check for memory safety in your software's code +### Using a non-memory safe by default language with developer best practices, but no automated tooling Examples: -* Using the [Go Data Race Detector](https://go.dev/doc/articles/race_detector) -* Using other tools such as [govulncheck, fuzzing, and vet](https://go.dev/doc/security/best-practices) when writing Go code -* Using a mutation tester such as [cargo-mutants](https://github.com/sourcefrog/cargo-mutants) -* Using [CodeQL](https://codeql.github.com/) for the [languages that CodeQL supports](https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/) -* Using [DevSkim](https://github.com/microsoft/devskim) IDE extensions/language analyzers +* [Using attributes such as `cleanup` and classes when writing C](https://lwn.net/Articles/934679/) (and depending on developers to manually check this) +* Following the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines) when writing C++ +* Using the [C++ Compiler Hardening Guide](https://github.com/ossf/wg-best-practices-os-developers/tree/main/docs/Compiler-Hardening-Guides) when compiling C++ code +* Isolating code that processes un-trusted data from code that performs direct memory management operations or uses raw pointers (see [Language-theoretic Security](https://github.com/ossf/Memory-Safety/pull/20)) +* Using [smart pointers](https://learn.microsoft.com/en-us/cpp/cpp/smart-pointers-modern-cpp?view=msvc-170) -### Using a memory safe by default language with developer best practices and automated tooling to check for memory safety in your software's code as well as in all your software's dependencies code -* Using a fuzzer such as [AFL++](https://github.com/AFLplusplus/AFLplusplus) on both your own code and third party code -* TO DO - add more +### Using a non-memory safe by default language without developer best practies or automated tooling + +Using raw C or C++ (or old versions of C and C++ language and compiler) + ## The Continuum - Getting to a Better State with re: to memory safety