SEC Special Seminar October 14 th Chris Tapp, LDRA

Transcription

1 SEC Special Seminar October 14 th 2015 Chris Tapp, LDRA

2 Agenda MISRA C++ update MISRA Compliance Deviations Adopted Code 2

3 MISRA C++ Update Current activity and future plans

4 Current activity Group restarted July 2014 and plans to meet three or four times a year - Bulletin Board Questions - Stand-alone Technical Corrigendum and updated 2008 document (incorporating the TC) will likely be ready late in 2015 or early in New C++ version(s) o The ISO C++ group have released two new versions (2011, 2014) since MISRA C++:2008 was published and will release further versions every three years 4

5 Bulletin Board Questions Some 50 questions have been reviewed Many can be answered by simply posting a reply to the Bulletin Board A number will require corrections to be issued within the Technical Corrigendum 5

6 Future plans update MISRA C++ Bring document up to the same standard as MISRA C: Better rationale, more examples, exceptions, more precise Add support for later versions of C++ - Probably using a single document to support all versions Backport new C++ features for use with the 2003 version - E.g. overload and final from the 2011 version these features are helpful and can be emulated within 2003 (and 2008) code 6

7 Future plans secure programming Add new guidance to support secure programming - Much of this is already covered by the existing guidelines - Most security vulnerabilities have the same underlying causes as safety issues o Undefined behaviour o Common developer errors o Failure to validate input data / run-time errors 7

8 Future plans annotations Add new guidance for the use of annotations - Aim will be to improve the quality and / or precision of static analysis o Identify pure functions many MISRA guidelines are more tolerant if it can be shown that functions do not contain persistent side-effects o Pre-conditions and post-conditions these will help improve data-flow related analysis (range checking, array bounds) 8

9 Future plans formal methods New guidance in the area of formal methods - But in a way that most developers will be able to use and understand we don t want to frighten lighter users of MISRA! - Will work in conjunction with annotations with the aim of allowing a project to use limited formal specification when it will help a project to meet its (A)SIL requirements - It will be made clear that there is no obligation for a project to use formal methods for it to be MISRA compliant 9

10 Future plans rolling release Providing coverage for new versions of the language standard requires a lot of effort! Two options - Wait until coverage for a version is complete before releasing updates o Will be difficult to keep up with the ISO group! o Long delays in making improvements available to the user community - Release updates when significant milestones are reached o Significant will depend on what feature(s) are considered to add significant value to the user community - Implications on publication o PDF is easy o Printed not so easy as printing costs are high Print on demand (PoD) is being investigated 10

11 Other possibilities Other publications - Investigating the feasibility of producing various guides / papers o PDF only - Programming-related issues o Will be written to be applicable to MISRA C when there is a overlap - Possible topics o Security o Formal methods / contract-based programming o Application and low-level programming o Managing Adopted Code (libraries, SOUP) o Dynamic memory allocation o Others 11

12 MISRA Compliance

13 Compliance What is compliance? Why is it important? Does compliant always mean high quality? 13

14 What is compliance? It is a statement claiming that the code within a project complies with the restrictions and controls imposed by a MISRA subset (e.g. MISRA C:2012) A statement of compliance is a form of self-certification - The organization producing the code is responsible for ensuring that it is compliant - Evidence needs to be produced to support a claim of compliance 14

15 What is compliance? 15

16 What is compliance? Note that compliance can only be claimed for a project - Unlike (e.g.) CMMI, an organization cannot be MISRA Compliant An accurate claim of compliance requires the use of skilled staff - It is not good enough to simply rely on the reports produced by analysis tools these need to be thoroughly reviewed and tool configurations validated Trying to make a project compliant at the end will be a painful and demoralizing task - It is not a tick-box exercise - It needs to be designed in and monitored during development 16

17 Why is compliance important? Compliance with a language subset is often required by international standards, e.g. - IEC and derivatives, such as ISO DO-178C - Etc. Issuing a compliance statement helps to demonstrate how this objective has been met 17

18 Compliance claims Compliance claims must be supported by evidence to show o How compliance has been enforced o How compliance has been verified Compliance claims must be independently verifiable - A customer should not blindly accept a claim of compliance issued by a supplier - Suppliers should expect to provide evidence to support a claim Compliance claims are not absolute - Different tools and processes are likely to give different results o Mainly due to decidability issues and the use of natural language to specify the guidelines 18

19 Does compliant mean high quality? That depends u8 u8a; s8 s8a; u16 u16a; u32a = s8a * u8a; // Non-compliant Would a deviation be acceptable here or should the code be written in a compliant manner? - Both options make the code compliant, but the first would be unlikely to be consistent with high quality 19

20 Deviations

21 Deviations MISRA expects the majority of projects to contain violations of the guidelines - They are likely to be essential when hardware is being controlled - Probably avoidable in most pure application code Violations are acceptable provided that they are covered by a valid deviation - A violation is simply a non-compliance with a guideline - A deviation is a violation supported by a process and documentation Requests for code with no deviations should be treated with caution! - Most likely when the person ordering the code comes from a non-misra background. For example, SPARK ADA does not recognise the concept of deviations code must be strictly conforming with no violations 21

22 When is a violation a valid deviation? The violation must be justifiable on strong technical grounds - Never just for developer convenience! The use of deviations must be controlled through a formal deviation process - Deviations are requested by a developer - Approved by a manager - Signed-off (risk accepted) by a suitable technical authority It is never acceptable for code to be made compliant by using a deviation to cover a violation which could reasonably have been avoided 22

23 Justifying a Deviation Reasons Any deviation should be attributable to one or more of the following reasons: - Performance - Alternative build configurations - Access to hardware - Defensive coding - Code quality - Adopted code integration - Non-compliant adopted code 23

24 Justifying a deviation what are the options? Once a reason has been identified an explanation should be given to explain what other options were considered and why they are not suitable - Can a different compiler be used? o More efficient code - Can other language features be used? o May be less efficient, but do they result in better quality attributes (more readable, easier to maintain, better testability, etc.)? 24

25 Technical authorities Skill and experience is needed when deciding if a violation should be signedoff (accepted) as a deviation - The rationale must be understood - The steps taken to mitigate any danger must be understood - Review can be non-trivial due to the potential for interaction between the guidelines when one is violated: o A violation of Rule 11.8 A cast shall not remove any const or volatile qualification from the type pointer to by a pointer can negate the protection provided by Rule 7.4 A string literal shall not be assigned to an object unless the object s type is pointer to const-qualified char o In this case the implications of a violation may not be constrained to the point in the code where the violation occurs all paths leading to that point will also need to be considered 25

26 Example of interaction const char * const message = "Hello World!"; void f1( char * p1 ) { *p1 = ' 0'; // Processing "message" at this point leads // to undefined behaviour } void f2( const char * p2 ) { // Deviation XYZ f1( ( char * )p2 ); // Violates MISRA C:2012 Rule 11.8 } void f3( void ) { f2( message ); // Complies with MISRA C:2012 Rule 7.4 } 26

27 Technical authorities Knowledge of how the language behaves is also important - Consider the common practice of using defensive code static enum { E1, E2 } E; switch ( E ) { case E1: action_1(); break; case E2: action_2(); break; default: an_error(); break; // May be unreachable } - The compiler may eliminate the path to the default and remove the code - This may be reported by an analysis tool - Simply adding a deviation will not make the code reachable - Testing may show coverage of the default, but it may still be missing in the binary used in production! 27

28 28

29 29

30 30

31 31

32 32

33 Limiting the number of deviations

34 Why limit the number of deviations? For the supplier - Limit the process overhead associated with each deviation - Improve the development culture For the customer - Reduce the effort required to audit compliance It is important to ensure that code is easy to understand, test and maintain - Too many deviations may give code that meets its time and resource constraints, but is it really a feasible solution? - One real danger is the uncontrolled, excessive use of macros o At the extreme, the code can only be reviewed when looking at the output of the pre-processor 34

35 How can their numbers be controlled? By the use of a guideline re-categorization policy By the use of deviation use-cases 35

36 Guideline re-categorization MISRA allocates a category to each guideline - Mandatory violations are never permitted - Required violations are permitted when supported by a deviation - Advisory violations should be avoided where practicable, but a formal deviation may not be required where violations exist The categories within the MISRA documents define the minimum enforcement level to be used for the guidelines - It is likely that a project will be able to raise the enforcement level for many Required guidelines to Mandatory - A project may also decide to raise Advisory guidelines to Required (or even Mandatory ) 36

37 Guidelines categorized as Required The requirements and restrictions should generally be followed all the time, but there can be conditions under which a deviation may be required, which is why they are not Mandatory (as deviations are never permitted) - The guidelines relating to implementation-defined and undefined language behaviours used when dealing with hardware are most commonly the ones which are likely to require deviation o For example, using a pointer to short to access the two words of a long on a 16-bit machine - Any Required guidelines that are not expected to be subject to deviations should be elevated to Mandatory o Developers then know that a deviation request will not be accepted o Can be reduced to Required later on if deviation becomes necessary 37

38 Guidelines categorized as Advisory The requirements and restrictions suggested are generally considered to be best practice and they can be of significant benefit to code quality - They should be assessed and those considered to be important to a particular project should be elevated to an appropriate, higher level - Projects with greater safety/security requirements often raise all of the Advisory guidelines to Required so that any violations have to be approved through the normal deviation process 38

39 Deviation use-cases Definitions - Violation a non-compliance with a MISRA guideline - Deviation a violation that is to be permitted within the code and which is supported by a deviation record - Deviation record documentation required to support a claim that a violation should be accepted as a deviation on the grounds that it is necessary and is proven not to have a negative impact on system integrity - Deviation use-case a deviation record template used to specify the conditions under which a guideline may be deviated 39

40 Deviation use-cases Specify the conditions and locations where deviations may be applied - Rule X may be subject to a deviation when performing CRC checks in the M module Ensure that any deviations have a good reason - Performance Allow a detailed rationale to be presented explaining why a deviation is the best option Allow a reasoned argument to be presented to explain how a deviation will not compromise system integrity Allow risks to be identified and any preventative measures required when deviating to be documented Allow the person responsible for approving deviations to easily decide if a particular deviation is acceptable 40

41 Deviation use-cases A deviation use-case is a deviation template that captures most of the information required by a deviation record - A subsequent deviation record can simply reference the deviation usecase, add relevant information (e.g. the location of the violation) and capture the required signatures - Deviation use-cases can be reused for other projects, especially when they relate to uses such as accessing hardware on a particular platform - Deviation use-cases allow developers to know if and where they can request the use of a deviation - Limiting the number of deviation use-cases available to the developers within a project will help to restrict the number of deviations they request 41

42 Use-case example for MISRA C:2004 Rule 13.7 Boolean operations whose results are invariant shall not be permitted 42

43 Re-Categorization and deviation use-cases A single level of guideline enforcement may not always be optimal - Access to hardware is normally encapsulated within device driver code o Deviations against a limited number of Required guidelines are likely o Deviations against the same guidelines are unlikely to be acceptable within higher level application code Two possible solutions - Use different guideline categorization profiles to alter the enforcement level applied to different parts of the code o Hardware categories and application categories - Use a single categorization profile with a set of deviation use-cases to restrict the conditions under which guidelines may be deviated 43

44 Categorization profiles Allow multiple guideline categorizations to be applied to the code - Typically one for hardware related code and one for application code Hardware profile - Generally less restrictive - Allows access to hardware features through deviations against a limited number of Required guidelines - All other Required guidelines should still be elevated to Mandatory Application profile - More restrictive - Most (or even all) Required guidelines will be elevated to Mandatory - Some (or even all) Advisory guidelines will be elevated to Required" 44

45 Categorization profiles Multiple profiles used - Code may need to be run through analysis tools for each profile, requiring more review effort - Multiple profiles may apply when crossing module boundaries (e.g. when application code invokes a device driver API) o Not an issue for Translation unit guidelines, but which profile should be applied for System guidelines? Single profile with deviation use-cases - More permissive profile used, but use-cases restrict use of deviations - Only one analysis run is needed in all cases - Module boundary issue can be handled by defining a deviation scope within a use-case o Enforcement of scope will be the responsibility of the people approving any deviations 45

46 Adopted code Third party code Legacy code Non-compliant code

47 Adopted code and enforcement profiles The term Adopted Code is used to describe - Third-party code - Legacy code - Code which is not MISRA compliant or that is compliant to a different version of a MISRA document Generally related to the use of libraries, applications, code from other projects - A particular piece of code can be one or more of the above o E.g. a library which is not MISRA compliant Basically, any code which may not meet the MISRA compliance objectives of the current project can be considered as Adopted Code - Note that this does not mean that Adopted Code is necessarily of poor quality good quality code does not have to be MISRA compliant 47

48 Issues with Adopted Code Any violations against the MISRA guidelines that have been adopted by the project need to be handled - It is never acceptable to simply declare that the MISRA guidelines do not apply to the Adopted Code - Deviations are likely to be required as it is often not possible or practicable to modify the Adopted Code to make it compliant o Such code is often well tested and there is a serious risk of introducing defects - Consideration must always be given to the potential for interaction between project code and Adopted Code 48

49 Interactions with Adopted Code Interactions can exist between Adopted Code and Native Code (project code) - A macro provided by an Adopted Code header file may be MISRA compliant within the header file and when used within the Adopted Code, but a use within Native Code could be non-compliant o It may then be possible to modify the Native Code to eliminate the violation - Identifier names with Adopted Code and Native Code may not meet the uniqueness requirements of MISRA o Adopted / Native conflicts are easy to resolve as Native Code can be changed o However, this may not be possible for conflicts between different pieces of Adopted Code (e.g. two libraries) o Such clashes are hard / impossible to detect for binary only code (e.g. a global name is reused but not defined within a header file) 49

50 Example Example is for MISRA C:2012 // Adopted_Code.h #define NOT_NULL( a ) ( ( a )!= 0 ) // Macro is compliant // Native_Code.c U32 f( const U32 * p ) { return NOT_NULL( p )? *p : 0U; // Use violates Rule 11.9 } 50

51 Adopted Code summary The Native and Adopted code within a project needs to be subjected to system-wide analysis using the guideline categories chosen for the project - This may highlight violations which would otherwise be missed - Adopted Code really needs to be in source code form o Some tools can check binary code, but this is not common or easy Any violations within Adopted Code will either need to be removed or covered by deviations Significant effort will be required, so make sure Adopted Code is subjected to MISRA checking as early as possible 51

52 Contact Details Portside Monks Ferry Wirral CH41 5LH United Kingdom 52