The MISRA C Coding Standard and its Role in the Development and Analysis of Safety- and Security-Critical Embedded Software

The MISRA project started in 1990 with the mission of providing world-leading best practice guidelines for the safe and secure application of both embedded control systems and standalone software. MISRA C is a coding standard defining a subset of the C language, initially targeted at the automotive sector, but now adopted across all industry sectors that develop C software in safety- and/or security-critical contexts. In this paper, we introduce MISRA C, its role in the development of critical software, especially in embedded systems, its relevance to industry safety standards, as well as the challenges of working with a general-purpose programming language standard that is written in natural language with a slow evolution over the last 40+ years. We also outline the role of static analysis in the automatic checking of compliance with respect to MISRA C, and the role of the MISRA C language subset in enabling a wider application of formal methods to industrial software written in C.Comment: 19 pages, 1 figure, 2 table

MISRA C, for Security's Sake!

A third of United States new cellular subscriptions in Q1 2016 were for cars. There are now more than 112 million vehicles connected around the world. The percentage of new cars shipped with Internet connectivity is expected to rise from 13% in 2015 to 75% in 2020, and 98% of all vehicles will likely be connected by 2025. Moreover, the news continuously report about "white hat" hackers intruding on car software. For these reasons, security concerns in automotive and other industries have skyrocketed. MISRA C, which is widely respected as a safety-related coding standard, is equally applicable as a security-related coding standard. In this presentation, we will show that security-critical and safety-critical software have the same requirements. We will then introduce the new documents MISRA C:2012 Amendment 1 (Additional security guidelines for MISRA C:2012) and MISRA C:2012 Addendum 2 (Coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 "C Secure Coding Rules"). We will illustrate the relationship between MISRA C, CERT C and ISO/IEC TS 17961, with a particular focus on the objective of preventing security vulnerabilities (and of course safety hazards) as opposed to trying to eradicate them once they have been inserted in the code.Comment: 4 pages, 2 tables, presented at the "14th Workshop on Automotive Software & Systems", Milan, November 10, 201

BARR-C:2018 and MISRA C:2012: Synergy Between the Two Most Widely Used C Coding Standards

The Barr Group's Embedded C Coding Standard (BARR-C:2018, which originates from the 2009 Netrino's Embedded C Coding Standard) is, for coding standards used by the embedded system industry, second only in popularity to MISRA C. However, the choice between MISRA C:2012 and BARR-C:2018 needs not be a hard decision since they are complementary in two quite different ways. On the one hand, BARR-C:2018 has removed all the incompatibilities with respect to MISRA C:2012 that were present in the previous edition (BARR-C:2013). As a result, disregarding programming style, BARR-C:2018 defines a subset of C that, while preventing a significant number of programming errors, is larger than the one defined by MISRA C:2012. On the other hand, concerning programming style, whereas MISRA C leaves this to individual organizations, BARR-C:2018 defines a programming style aimed primarily at minimizing programming errors. As a result, BARR-C:2018 can be seen as a first, dramatically useful step to C language subsetting that is suitable for all kinds of projects; critical projects can then evolve toward MISRA C:2012 compliance smoothly while maintaining the BARR-C programming style. In this paper, we introduce BARR-C:2018, we describe its relationship with MISRA C:2012, and we discuss the parallel and serial adoption of the two coding standards.Comment: 14 pages, 1 figur

Coding Guidelines and Undecidability

The C and C++ programming languages are widely used for the implementation of software in critical systems. They are complex languages with subtle features and peculiarities that might baffle even the more expert programmers. Hence, the general prescription of language subsetting, which occurs in most functional safety standards and amounts to only using a "safer" subset of the language, is particularly applicable to them. Coding guidelines are the preferred way of expressing language subsets. Some guidelines are formulated in terms of the programming language and its implementation only: in this case they are amenable to automatic checking. However, due to fundamental limitations of computing, some guidelines are undecidable, that is, they are based on program properties that no current and future algorithm can capture in all cases. The most mature and widespread coding standards, the MISRA ones, explicitly tag guidelines with undecidable or decidable. It turns out that this information is not of secondary nature and must be taken into account for a full understanding of what the guideline is asking for. As a matter of fact, undecidability is a common source of confusion affecting many users of coding standards and of the associated checking tools. In this paper, we recall the notions of decidability and undecidability in terms that are understandable to any C/C++ programmer. The paper includes a systematic study of all the undecidable MISRA C:2012 guidelines, discussing the reasons for the undecidability and its consequences. We pay particular attention to undecidable guidelines that have decidable approximations whose enforcement would not overly constrain the source code. We also discuss some coding guidelines for which compliance is hard, if not impossible, to prove, even beyond the issue of decidability.Comment: 12 pages, 5 figures, 1 tabl

Robot Cybersecurity, a Review

Robots are often shipped insecure and in some cases fully unprotected. The rationale behind is threefold: first, defensive security mechanisms for robots are still in their early stages, not covering the complete threat landscape. Second, the inherent complexity of robotic systems makes their protection costly, both technically and economically. Third, vendors do not generally take responsibility in a timely manner, extending the zero-day exposure window (time until mitigation of a zero-day) to several years on average. Worse, several manufacturers keep forwarding the problem to the end-users of these machines or discarding it. In this article we review the status of robot cybersecurity considering three sources of data: 1) recent literature, 2) questionnaires performed in top robotics forums and 3) recent research results in robot cybersecurity. Building upon a decade of experience in robotics, this article reviews the current status of cybersecurity in robotics and argues about the current challenges to secure robotic systems. Ultimately, based on the empirical results collected over a period of three years performing security assessments in robots, the present text advocates for a complementary offensive approach methodology to protect robots in a feasible and timely manner

Robot Cybersecurity, a Review

Robots are often shipped insecure and in some cases fully unprotected. The rationale behind is threefold: first, defensive security mechanisms for robots are still in their early stages, not covering the complete threat landscape. Second, the inherent complexity of robotic systems makes their protection costly, both technically and economically. Third, vendors do not generally take responsibility in a timely manner, extending the zero-day exposure window (time until mitigation of a zero-day) to several years on average. Worse, several manufacturers keep forwarding the problem to the end-users of these machines or discarding it. In this article we review the status of robot cybersecurity considering three sources of data: 1) recent literature, 2) questionnaires performed in top robotics forums and 3) recent research results in robot cybersecurity. Building upon a decade of experience in robotics, this article reviews the current status of cybersecurity in robotics and argues about the current challenges to secure robotic systems. Ultimately, based on the empirical results collected over a period of three years performing security assessments in robots, the present text advocates for a complementary offensive approach methodology to protect robots in a feasible and timely manner

C-rusted: The Advantages of Rust, in C, without the Disadvantages

C-rusted is an innovative technology whereby C programs can be (partly) annotated so as to express: ownership, exclusivity and shareability of language, system and user-defined resources; dynamic properties of objects and the way they evolve during program execution; nominal typing and subtyping. The (partially) annotated C programs can be translated with unmodified versions of any compilation toolchain capable of processing ISO C code. The annotated C program parts can be validated by static analysis: if the static analyzer flags no error, then the annotations are provably coherent among themselves and with respect to annotated C code, in which case said annotated parts are provably exempt from a large class of logic, security, and run-time errors.Comment: 7 pages, 4 figure