Hi Pete,

See  http://www.underhanded-c.org/_page_id_2.html

I don't know if this contest is still being supported.  But as you can see, it highlights the limitations of C as a programming language.

So that ensuring "quality" of any C-based safety critical system is not easy, even before we get to the limitations of Linux and open source.

Unfortunately throughout my career I have seen plenty of code examples which, although not malicious in the sense of this contest, comply with accepted development/coding/test processes – but are inherently unsafe, sometimes by design.

Regards

Elana

Hi Elana,

Not sure why you directed this to me.  I have always advocated for product and process quality, of which code quality is just one aspect.  The safety of a product, as you say at the end might be compromised by the design, which is why I have been advocating for the quality and safety aspects mentioned above.

Pete

[AMD Official Use Only - General]

Hi,

I jumped in because I found the topic interesting.

The shortcomings of C in comparison to other type safe languages like Java and Rust are being highlighted in security context too.

Although, I am not sure that today’s automobiles’ SW stacks (AutoSAR, Adaptive AutoSAR) use them. They would be pretty much written in C.

Regards

Poonam

Indeed.

But the point here is much more subtle: 

For the code submitted to this contest, I would assume that all of the aspects related to product and process quality, including design, are well covered and would be qualified by any safety standard.  But the final result is not safe.

The inherent features of C (and, to a lesser extent, C++) enable the clever developer to write qualified unsafe code.

And although the contest focuses on security issues (which as noted by Poonam is more highlighted), similar tricks can be implemented to evade safety as well as functional features.

The type of testing which would block such code is on a different level altogether.

Bottom line, documented architecture and design; requirements; and classic testing (primarily static); and other aspects dominating safety standards and legacy processes, are not necessarily appropriate mechanisms for ensuring quality and safety of modern software systems, primarily if written in a language such as C.

Thanks very much for your comments, agreed – the value of type safe languages such as Rust is well known.  But this relates to only one facet of the issues at hand.

We need to deal with the current commonly accepted state of software development:

1. An overwhelming amount of code written in C is being deployed in safety critical systems.  No one is going to migrate all that code to C.
2. Embedded software developers continue to "think" C, even when writing C++ code. 
3. There are common software practices (such as direct hardware access, incomplete fault handling, type coercion, etc.) which are deeply entrenched in C-minded software.  The mindset needs to change, not (only) the programming language.  But we will continue to live with legacy software, and legacy development methodologies, for a long time.
4. The safety standards are focused on a waterfall mode, documentation intensive development process which is not economical (as per your note 4 below), not scalable, and not aligned with complex software which is increasingly dependent on open source or even "SOUP" (= Software Of Unknown Pedigree).
5. Multicore, multithreaded software systems introduce additional levels of complexity, requiring more intense testing focused on dynamic analysis.
6. Flexible software updates present a challenge for testing and deployment of the "whole" (vs the individual parts).

What can be done?  Some suggestions  (feel free to pitch in here with some more!!):

1. Support software developers with safe libraries for development and testing.  For example, 

• https://github.com/oneapi-src/oneTBB  an Intel open source library which is qualified for safety critical applications, and manages parallel threads for software developers in a safe way. 
• https://www.arm.com/products/development-tools/embedded-and-software/software-test-libraries for ARM HW testing (@paul.albertella@... and Codethink have been doing some work here).
• Dynamic analysis test tools such as kcsan (Linux kernel concurrency santizer, used to detect race conditions) or  kfence (low overhead utility for detecting memory access errors).  @Shuah Khan is actively integrating relevant test tools in the Linux kernel test systems.

2. Software developers – change in paradigm.  Python became the de facto programming language for data science because of the abundance of supportive libraries which have evolved in this domain.  Rust and other type safety languages can also become standard, if there are sufficient supporting and safety qualified libraries to make the evolution worthwhile.
3. Safety standards – change in paradigm.   The safety standards were defined based on legacy development methodologies; they are not aligned with the fast pace and complexity of modern safety critical systems.  There is ongoing work to update the standards and help to provide the necessary framework for qualification of such safety critical software.
4. In the security domain, it is becoming increasingly obvious that we can no longer rely exclusively on secure software development processes and test tools focusing on static analysis.  Prevention has unfortunately proven to be a losing battle against motivated hackers.  Modern paradigms (e.g., "zero trust") depend on machine learning and dynamic analysis to enable detection and confine the impact of a security breach.

For safety, we need a similar change in mindset and frameworks for dynamic analysis of a complete system for compliance with safety goals defined for that system.   We should continue to focus on the development process (requirements definition; architecture documentation; static analysis; configuration management) in an effective and realistic way, leveraging modern development, build and test tools, without pushing to the extreme of simplistic "waterfall" development processes.  And at the same time, build in to our CI systems strong utilities for dynamic configuration management and testing.

Elana