adds initial draft of memory safety continuum #20
Conversation
Signed-off-by: Nell Shamrell <[email protected]>
Signed-off-by: Nell Shamrell <[email protected]>
Signed-off-by: Nell Shamrell <[email protected]>
| @@ -0,0 +1,66 @@ | |||
| # Memory Safety Continuum | |||
There was a problem hiding this comment.
I wonder if this should merge into the definitions.md, since it extends upon the notions in that and that way we would have a sharable, unified artifact that defines memory-safety?
There was a problem hiding this comment.
Possibly - though I'd like to keep it in a separate doc until we further discuss and refine the idea of the continuum.
|
|
||
| ## FAQ | ||
|
|
||
| ### Why do you rank using automated tooling higher than just using developer best practices? |
docs/memory-safety-continuum.md
Outdated
| * Using a non-memory safe by default language with developer best practices and automated tooling to check for memory safety | ||
| * Using a memory safe by default language (such as Rust, Go, Python, Java, JavaScript, C#) without developer best practices and automated tooling | ||
| * Using a memory safe by default language with developer best practices | ||
| * Using a memory safe by default language with developer best practices and automated tooling |
There was a problem hiding this comment.
i wonder if we should consider cases such as:
- using memory safe by default language that depends upon unsafe language (i.e. through the use of external/foreign functions, or with Ptyhon extensions)
- using memory safe by default languages which runtime was built with/without developer best practices and automated tooling (an edge case, but one that may exist, specifically in OT/edge/proprietary devices)
There was a problem hiding this comment.
What about when you disable the memory safeties (in languages like Rust, Ada, and C#, where that's possible)? If there's a small amount (say, a few dozen lines or under 0.1%) that's probably fine. If you have a large package that disables safeties, it's really just a memory-unsafe language & should be treated that way.
If you formally prove a program has no memory safety issues (as opposed to using a typical SAST) tool, then I'd say you are using a memory-safe language (even if it's C). Of course, the number of programs (like seL4) where that true is small, but it is a possibility.
There was a problem hiding this comment.
Good points - I've added content about them in the FAQs.
Signed-off-by: Nell Shamrell <[email protected]>
Signed-off-by: Nell Shamrell <[email protected]>
|
|
||
| ## What is Memory Safety? | ||
|
|
||
| Rather than using terms like "Memory Safe Language" and "Memory Unsafe Language", this SIG prefers the terms "memory safe by default" and "non-memory safe by default". Please see our [useful definitions](definitions.md) file for more information about memory safety and undefined behavior. |
Signed-off-by: Nell Shamrell <[email protected]>
Signed-off-by: Nell Shamrell <[email protected]>
|
Just to have a data point pinned to this PR, I shared in the call today that I think a continuum should focus more on adoption (amount of safe-by-default lang code vs unsafe-by-default) and commitment (no new code in unsafe-by-default langs) than it should on best practices/automated tooling. See my comments on ossf/scorecard#3736 for more of my thoughts on tools and process, what we actually care about with them, and how they relate to memory safety initiatives. |
| * [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 | ||
|
|
There was a problem hiding this comment.
How about? :
Isolating code that processes un-trusted data from code that performs direct memory management operations or uses raw pointers (See: https://langsec.org)
|
|
||
| ### Using a memory safe by default language with developer best practices and automated tooling to check for memory safety in first party code AND third party code | ||
|
|
||
| TO DO |
There was a problem hiding this comment.
Fuzzing components (including third-party code) that parse un-trusted data is a good way to find "low-hanging fruit" when auditing third party code is not feasible.
(One popular fuzzer is AFL++.)
@nellshamrell , I think if I were to say much more than this, it would make sense to stick it in its own file in /docs... should I have a go and make a PR?
|
Hi @jduck - after a lot of things happened, I'm finally coming back to this. I'd like to focus this pull request to the continuum on understanding where you are (speaking to a dev or an engineering manager) with re: to memory safety. I could see a future pull request focusing on how to get to a better state (where we could consider things like percentage of code in memory safe by default, percentage of code in non-memory safe by default, etc.). I will note the focus on understanding where you are in the draft. |
Signed-off-by: Nell Shamrell <[email protected]>
Signed-off-by: Nell Shamrell <[email protected]>
|
Got a couple of 👍 in our Slack channel when I asked about merging this. Going ahead and doing so. |
This is a very, very early draft (more of an extended outline) exploring the idea of a memory safety continuum. Feedback is most welcome!