Prioritize CERT C sections for translating to Rust safety-critical coding guidelines

[PLeVasseur]

CERT C sections, prioritized

(below is @PLeVasseur's biased take, needs refinement with group)

1. Rule 04. Integers (INT)
2. Rule 05. Floating Point (FLP)
3. Rule 06. Arrays (ARR)
4. Rule 07. Characters and Strings (STR)
5. Rule 02. Declarations and Initialization (DCL)
6. Rule 12. Error Handling (ERR)
7. ...

Uncategorized list of CERT C sections to make creating prioritized list easier later

• Rule 01. Preprocessor (PRE)
• Rule 02. Declarations and Initialization (DCL)
• Rule 03. Expressions (EXP)
• Rule 04. Integers (INT)
• Rule 05. Floating Point (FLP)
• Rule 06. Arrays (ARR)
• Rule 07. Characters and Strings (STR)
• Rule 08. Memory Management (MEM)
• Rule 09. Input Output (FIO)
• Rule 10. Environment (ENV)
• Rule 11. Signals (SIG)
• Rule 12. Error Handling (ERR)
• Rule 13. Application Programming Interfaces (API)
• Rule 14. Concurrency (CON)

Below are a bit more speculative, but should be investigated:

• Rule 48. Miscellaneous (MSC)
• Rule 50. POSIX (POS)
• Rule 51. Microsoft Windows (WIN)

Mapping from CERT C => FLS

CERT C Section	FLS Chapter	FLS Paragraph ID	Notes
Rule 01. Preprocessor (PRE)	no equivalent	no equivalent	Determined based on a quick read-through, subject to refinement
Rule 02. Declarations and Initialization (DCL)	Ownership and Destruction	todo	Determined based on a quick read-through, subject to refinement
Rule 03. Expressions (EXP)	Expressions possibly Unsafety as well	todo	Determined based on a quick read-through, subject to refinement Does seem to focus primarily on those things which are either not possible or must be done using unsafe in Rust
Rule 04. Integers (INT)	Types and Traits	4.3.3.2. Integer Types
Rule 05. Floating Point (FLP)	Types and Traits	4.3.3.1. Floating Point Types
Rule 06. Arrays (ARR)	Unsafety possibly	todo	Determined based on a quick read-through, subject to refinement Does seem to focus primarily on those things which are either not possible or must be done using unsafe in Rust
Rule 07. Characters and Strings (STR)	FFI possibly	todo	Determined based on a quick read-through, subject to refinement Could be a fit in the FFI portion, due to the emphasis on ensuring safe CString and CStr handling
Rule 08. Memory Management (MEM)	Unsafety	todo	Determined based on a quick read-through, subject to refinement Safe-subset Rust is not concerned with the level of detail gone into here, but certainly unsafe Rust could be
Rule 09. Input Output (FIO)	Unsafety & FFI possibly Note there are some safe parts of Rust which could be misused we should call out: FIO32-C. Do not perform operations on devices that are only appropriate for files is a perfect example of applicability to a part of the standard library which is marked as safe, though it could be misused: /proc/self/mem and similar OS features	todo	Determined based on a quick read-through, subject to refinement
Rule 10. Environment (ENV)	Unsafety & FFI possibly	todo	Determined based on a quick read-through, subject to refinement But in general we should probably encourage usage of safe ways of interacting with the environment which may not have a clear 1 <=> 1 with the FLS
Rule 11. Signals (SIG)	Unsafety & FFI possibly	todo	Determined based on a quick read-through, subject to refinement But in general we should probably encourage usage of safe ways of interacting with signals which may not have a clear 1 <=> 1 with the FLS
Rule 12. Error Handling (ERR)	Exceptions and Errors FFI possibly	todo	Determined based on a quick read-through, subject to refinement
Rule 13. Application Programming Interfaces (API)	todo	todo	Currently empty section of CERT C We could still offer up some Rust coding guidelines for APIs, but it'd not link to anything CERT C-specific
Rule 14. Concurrency (CON)	Concurrency & Unsafety possibly	todo	Determined based on a quick read-through, subject to refinement

[rcseacord]

Priorities are pretty subjective. I think we probably did floating point last? It's possible you just want one rule that says don't use floating point.

I would probably put expressions pretty high on the list. Unclear how it will map though.

[rcseacord]

The misc rules might be decent rules. They are just things that didn't fall into existing categories.

[PLeVasseur]

Priorities are pretty subjective.

Definitely! To clarify, I put them in order of "ease in tackling, so that we can figure out how to handle the remaining ones".

I didn't put them in order of usefulness, just to be clear 😅

[rcseacord]

A couple of comments I made in the last meeting that may or may not have been recorded. FFI AFAICT allows you to use C types in Rust like short, int, long. These types only have minimum required ranges and can't be larger than a larger sized integer. If you allow these types in Rust now you have to consider the possibility they will have different range on different platforms. Now you have to decide on what basis you are going to diagnose violations:

1. Unsafe / insecure -- for a given implementation (which has to be input to the analyzer) the code is safe / unsafe
2. The code must be portably safe. This means, for example, that you can only assume 16 bits int

CERT always took the position that you could be secure on a platform without the code being portable

MISRA is all over the place. They have rules which seem to focus on portability but don't really enforce portability. I say "seem to" because you often have to guess what the purpose of some of these rules are.

[rcseacord]

A further general observation from years of evaluating source code is that the interface between languages is a frequent sort of errors and vulnerability. It's common to say, map a 32 bit unsigned int to a size_t. However, size_t might be 32 or 64 bits depending on the implementation.

[felix91gr]

Better late than never; here's a table of the mapping from CERT-C to Rust that @sei-dsvoboda and I have been working on over the last month and a bit. The division by zero issue and PRs are @vapdrs's ❤️

Cert C Guideline	Does it apply?	How does it apply? / Why doesn't it apply?	Status
INT30-C. Ensure that unsigned integer operations do not wrap	✅ Yes	Through using either wrapping_, saturating_ or checked_ arithmetic functions.	✍️ WIP
INT31-C. Ensure that integer conversions do not result in lost or misinterpreted data	✅ Yes	Through using Into and From for infallible conversions, and TryInto and TryFrom respectively for fallible ones. The case when a conversion doesn't work in a fallible process must be addressed in the code.	📝 Issue Opened for Defect Rule. (Subset Rule still WIP)
INT32-C. Ensure that operations on signed integers do not result in overflow	✅ Yes	Combined with INT30-C in one guideline. In C, they are separate because unsigned overflow is defined behavior whereas signed overflow isn't.	✍️ WIP
INT33-C. Ensure that division and remainder operations do not result in divide-by-zero errors	✅ Yes	Through either using NonZero<T> as the divisor, or using the checked_div and checked_rem functions	⛵ Shipped!
INT34-C. Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand	✅ Yes	Through using checked_shl and checked_shr	⛵ Shipped!
INT35-C. Use correct integer precisions	❌ No	It doesn't apply because every primitive integer type in Rust has a guaranteed precision	N/A
INT36-C. Converting a pointer to integer or integer to pointer	✅ Yes	WIP. This is the current consensus. More work is needed to flesh it out.	💬 Still in Discussion

[felix91gr]

CC @rcseacord

Priorities are pretty subjective. I think we probably did floating point last? It's possible you just want one rule that says don't use floating point.

I would probably put expressions pretty high on the list. Unclear how it will map though.

Wanna see something cool and a bit funny? There is an existing Clippy lint one can enable to disable floating point arithmetic 😁: clippy::float_arithmetic

The misc rules might be decent rules. They are just things that didn't fall into existing categories.

Good point! Checking them real quick, the first one (MSC30-C. Do not use the rand() function for generating pseudorandom numbers) appears in MISRA C as well:

• 21.24 The random number generator functions of <stdlib.h> shall not be used.

In our case, we'll have to wait until std::random becomes stable, so we're good on that one. The others seem very reasonable in the context of C. They are very varied, as well. Misc indeed.

Anywho, thanks for pointing those rules out :)

[PLeVasseur]

Better late than never; here's a table of the mapping from CERT-C to Rust that @sei-dsvoboda and I have been working on over the last month and a bit. The division by zero issue and PRs are @vapdrs's ❤️

I really like this @felix91gr -- perhaps you could add another column for done/not done for easy readability. 🤔

[felix91gr]

Better late than never; here's a table of the mapping from CERT-C to Rust that @sei-dsvoboda and I have been working on over the last month and a bit. The division by zero issue and PRs are @vapdrs's ❤️

I really like this @felix91gr -- perhaps you could add another column for done/not done for easy readability. 🤔

Good idea! I'll add that too, now that we have landed some of them :)