Verifikation von C-Programmen Vorlesung 1 vom 23.10.2014: Der - PowerPoint PPT Presentation

Mehrdimensionale Felder als Funktionsparameter ◮ Regel 3 gilt nicht rekursiv: ◮ Array of Arrays ist Array of Pointers, nicht Pointer to Pointer ◮ Mögliches Matching: Parameter Argument char (*c)[10]; char c[8][10]; char (*c)[10]; char **c; char *c[10]; char **c; char c[][10]; char c[8][10]; char (*c)[10]; ◮ f(int x[][]); nicht erlaubt (§6.7.5.2) ◮ NB. Warum ist int main(int argc, char *argv[]) erlaubt? 8 [14]

Programmausführung (§5.1.2.3) ◮ Standard definiert abstrakte Semantik ◮ Implementation darf optimieren ◮ Seiteneffekte: ◮ Zugriff auf volatile Objekte; ◮ Veränderung von Objekten; ◮ Veränderung von Dateien; ◮ Funktionsaufruf mit Seiteneffekten. ◮ Reihenfolge der Seiteneffekte nicht festgelegt! ◮ Sequenzpunkten (Annex C) sequentialisieren Seiteneffekte. 9 [14]

Semantik: Statements ◮ Full statement, Block §6.8 ◮ Iteration §6.8.5 10 [14]

Semantik: Speichermodell ◮ Der Speicher besteht aus Objekten ◮ lvalue §6.3.2.1: Expression with object type or incomplete type other than void ◮ lvalues sind Referenzen, keine Adressen ◮ Werden ausgelesen, außer ◮ als Operand von & , ++ , – , sizeof ◮ als Linker Operand von . und Zuweisung ◮ lvalue (has) array tyoe ◮ Woher kommen lvalues? ◮ Deklarationen ◮ Indirektion ( * ) ◮ malloc ◮ Adressen: ◮ Adressoperator ( & ) ◮ Zeigerarithmetik (§6.5.6) 11 [14]

Ausdrücke (in Auszügen) ◮ Einfache Bezeichner: lvalue ◮ Bezeichner von Array-Typ: Zeiger auf das erste Element des Feldes (§6.3.2.1) ◮ Felder: 6.5.2.1 ◮ a[i] definiert als *((a)+(i)) ◮ Damit: a[i] = *((a)+(i)) = *((i)+(a)) = i[a] ◮ Zuweisung: 6.5.16 ◮ Reihenfolge der Auswerung nicht spezifiziert! 12 [14]

Funktionsaufrufe §6.5.2.2 ◮ Implizite Konversionen: ◮ Nur wenn kein Prototyp ◮ Integer Promotions, float to double ◮ Argumente werden ausgewertet, und den Parametern zugewiesen ◮ Funktionsparameter sind wie lokale Variablen mit wechselnder Initialisierung ◮ Reihenfolge der Auswertung von Funktionausdruck und Argumenten nicht spezifiziert, aber Sequenzpunkt vor Aufruf. 13 [14]

Zusammenfassung ◮ Typkonversionen in C: meist klar, manchmal überraschend ◮ Auswertung durch eine abstrakte Maschine definiert ◮ Speichermodell: ◮ Speicher besteht aus Objekten ◮ Durch char addressiert ( byte ) ◮ Referenzen auf Objekte: lvalue 14 [14]

Verifikation von C-Programmen Universität Bremen, WS 2014/15 Lecture 03 (06.11.2014) Was ist eigentlich Verifikation? Christoph Lüth

Synopsis If you want to write safety-criticial software, then you need to adhere to state-of-the-art practise as encoded by the relevant norms & standards. Today: What is safety and security?  Why do we need it? Legal background.  How is it ensured? Norms and standards  ► IEC 61508 – Functional safety ► IEC 15408 – Common criteria (security)

The Relevant Question If something goes wrong: Whose fault is it?  Who pays for it?  That is why most (if not all) of these standards put a lot of emphasis on process and traceability. Who decided to do what, why, and how? The bad news: As a qualified professional, you may become personally  liable if you deliberately and intentionally ( grob vorsätzlich ) disregard the state of the art. The good news: Pay attention here and you will be sorted. 

Safety: norms & standards

What is Safety? Absolute definition: „ Safety is freedom from accidents or losses .“  ► Nancy Leveson , „ Safeware: System safety and computers “ But is there such a thing as absolute safety? Technical definition: „Sicherheit: Freiheit von unvertretbaren Risiken“  ► IEC 61508-4:2001, §3.1.8 Next week: a safety-critical development process

Some Terminology Fail-safe vs. Fail operational Safety-critical, safety-relevant ( sicherheitskritisch ) General term -- failure may lead to risk  Safety function ( Sicherheitsfunktion ) Techncal term, that functionality which ensures safety  Safety-related ( sicherheitsgerichtet, sicherheitsbezogen ) Technical term, directly related to the safety function 

Legal Grounds The machinery directive: The Directive 2006/42/EC of the European Parliament and of the Council of 17 May 2006 on machinery, and amending Directive 95/16/EC (recast) Scope: Machineries (with a drive system and movable parts).  Structure: Sequence of whereas clauses (explanatory)  followed by 29 articles (main body)  and 12 subsequent annexes (detailed information about  particular fields, e.g. health & safety) Some application areas have their own regulations: Cars and motorcycles, railways, planes, nuclear plants … 

What does that mean? Relevant for all machinery (from tin-opener to AGV) Annex IV lists machinery where safety is a concern Standards encode current best practice. Harmonised standard available?  External certification or self-certification Certification ensures and documents conformity to  standard. Result: Note that the scope of the directive is market harmonisation, not safety – that is more or less a byproduct.

The Norms and Standards Landscape • First-tier standards ( A-Normen ): General, widely applicable, no specific area of application • Example: IEC 61508 • • Second-tier standards ( B-Normen ): Restriction to a particular area of application • Example: ISO 26262 (IEC 61508 for automotive) • • Third-tier standards ( C-Normen ): Specific pieces of equipment • Example: IEC 61496- 3 (“ Berührungslos wirkende • Schutzeinrichtungen ”) • Always use most specific norm.

Norms for the Working Programmer IEC 61508: “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-  related Systems (E/E/PE, or E/E/PES )” Widely applicable, general, considered hard to understand  ISO 26262 Specialisation of 61508 to cars (automotive industry)  DIN EN 50128 Specialisation of 61508 to software for railway industry  RTCA DO 178-B: “ Software Considerations in Airborne Systems and Equipment Certification “  Airplanes, NASA/ESA  ISO 15408: “ Common Criteria for Information Technology Security Evaluation”  Security, evolved from TCSEC (US), ITSEC (EU), CTCPEC (Canada) 

Software Development Models

Software Development Models Flexibility Prototype-based Agile developments Methods Spiral model V-model Waterfall Model-driven model developement Structure from S. Paulus: Sichere Software

Waterfall Model (Royce 1970) Classical top-down sequential workflow with strictly separated phases. Requirement Design Implementation Verification Maintenance Unpractical as actual workflow (no feedback between phases), but even early papers did not really suggest this.

Spiral Model (Böhm, 1986) Incremental development guided by risk factors Four phases: Determine objectives  Analyse risks  Development and test  Review, plan next iteration  See e.g. Rational Unified Process (RUP)  Drawbacks: Risk identification is the key, and can be quite difficult 

Agile Methods Prototype-driven development E.g. Rapid Application Development  Development as a sequence of prototypes  Ever-changing safety and security requirements  Agile programming E.g. Scrum, extreme programming  Development guided by functional requirements  Less support for non-functional requirements  Test-driven development Tests as executable specifications: write tests first  Often used together with the other two 

Model-Driven Development (MDD, MDE) Describe problems on abstract level using a modelling language (often a domain-specific language ), and derive implementation by model transformation or run-time interpretation. Often used with UML (or its DSLs, eg. SysML) Variety of tools: Rational tool chain, Enterprise Architect  EMF (Eclipse Modelling Framework)  Strictly sequential development Drawbacks: high initial investment, limited flexibility

Development Models for Critical Systems Ensuring safety/security needs structure. …but too much structure makes developments  bureaucratic, which is in itself a safety risk. Cautionary tale: Ariane-5  Standards put emphasis on process . Everything needs to be planned and documented.  Best suited development models are variations of the V- model or spiral model.

Development Model in IEC 61508 IEC 61508 prescribes certain activities for each phase of the life cycle. Development is one part of the life cycle. IEC recommends V-model. Verification & Validation

V & V Verification Making sure the system satisfies safety requirements  „ Is the system built right (i.e. correctly )?“  Validation Making sure the requirements are correct and adequate.  „Do we build the right (i.e. adequate) system ?“  21

Development Model in DO-178B DO-178B defines different processes in the SW life cycle: Planning process  Development process, structured in turn into  ► Requirements process ► Design process ► Coding process ► Integration process Integral process  There is no conspicuous diagram, but these are the phases found in the V-model as well. Implicit recommendation. 

Artefacts in the Development Process Planning : Document plan Possible formats : • V&V plan Word documents • • QM plan Excel sheets • • Test plan Wiki text • • Project manual Database (Doors) • • Specifications : UML diagrams • Safety requirement spec. • System specification • Formal languages: • Detail specification • Z, HOL, etc. • User document (safety • Statecharts or • reference manual) similar diagrams Implementation : Source code • Code • Verification & validation: Documents must be identified and Code review protocols • reconstructable . Tests and test scripts • Revision control and configuration • Proofs • management obligatory .

Introducing IEC 61508

Introducing IEC 61508 Part 1: Functional safety management, competence, establishing SIL targets Part 2: Organising and managing the life cycle Part 3: Software requirements Part 4: Definitions and abbreviations Part 5: Examples of methods for the determination of safety-integrity levels Part 6: Guidelines for the application Part 7: Overview of techniques and measures

How does this work? 1. Risk analysis determines the safety integrity level (SIL) 2. A hazard analysis leads to safety requirement specification. 3. Safety requirements must be satisfied Need to verify this is achieved.  SIL determines amount of testing/proving etc.  4. Life-cycle needs to be managed and organised Planning: verification & validation plan  Note: personnel needs to be qualified.  5. All of this needs to be independently assessed. SIL determines independence of assessment body. 

Safety Integrity Levels SIL High Demand Low Demand (more than once a year) (once a year or less) 4 10 -9 < P/hr < 10 -8 10 -5 < P/yr < 10 -4 3 10 -8 < P/hr < 10 -7 10 -4 < P/yr < 10 -3 2 10 -7 < P/hr < 10 -6 10 -3 < P/yr < 10 -2 1 10 -6 < P/hr < 10 -5 10 -2 < P/yr < 10 -1 • P: Probabilty of dangerous failure (per hour/year) • Examples:  High demand: car brakes  Low demand: airbag control • Which SIL to choose?  Risk analysis • Note: SIL only meaningful for specific safety functions.

Establishing target SIL I IEC 61508 does not describe standard procedure to establish a SIL target, it allows for alternatives: Quantitative approach Maximum tolerable Individual risk Start with target risk level risk of fatality (per annum)  Employee 10 -4 Factor in fatality and  frequency Public 10 -5 Broadly acceptable 10 -6 („ Neglibile “) Example: Safety system for a chemical plant  Max. tolerable risk exposure A=10 -6  B= 10 -2 hazardous events lead to fatality  Unprotected process fails C= 1/5 years  Then Failure on Demand E = A/(B*C) = 5*10 -3 , so SIL 2 

Establishing target SIL II Risk graph approach Example: safety braking system for an AGV

What does the SIL mean for the development process? In general: „ Competent “ personnel  Independent assessment („ four eyes “)  SIL 1: Basic quality assurance (e.g ISO 9001)  SIL 2: Safety-directed quality assurance, more tests  SIL 3: Exhaustive testing, possibly formal methods  Assessment by separate department  SIL 4: State-of-the-art practices, formal methods  Assessment by separate organisation 

Increasing SIL by redudancy One can achieve a higher SIL by combining independent systems with lower SIL („ Mehrkanalsysteme “). Given two systems A, B with failure probabilities 𝑄 𝐵 , 𝑄 𝐶 , the chance for failure of both is (with 𝑄 𝐷𝐷 probablity of common-cause failures): 𝑄 𝐵𝐶 = 𝑄 𝐷𝐷 + 𝑄 𝐵 𝑄 𝐶 Hence, combining two SIL 3 systems may give you a SIL 4 system. However, be aware of systematic errors (and note that IEC 61508 considers all software errors to be systematic). Note also that for fail-operational systems you need three (not two) systems.

The Safety Life Cycle (IEC 61508) Planning Realisation Operation

The Software Development Process 61508 „ recommends “ V-model development process Appx A, B give normative guidance on measures to apply: Error detection needs to be taken into account (e.g runtime  assertions, error detection codes, dynamic supervision of data/control flow) Use of strongly typed programming languages (see table)  Discouraged use of certain features: recursion(!), dynamic  memory, unrestricted pointers, unconditional jumps Certified tools and compilers must be used.  ► Or `proven in use´

Proven in Use As an alternative to systematic development, statistics about usage may be employed. This is particularly relevant for development tools (compilers, verification tools etc),  and for re-used software (in particular, modules).  Note that the previous use needs to be to the same  specification as intended use (eg. compiler: same target platform). SIL Zero Failure One Failure 1 12 ops 12 yrs 24 ops 24 yrs 2 120 ops 120 yrs 240 ops 240 yrs 3 1200 ops 1200 yrs 2400 ops 2400 yrs 4 12000 ops 12000 yrs 24000 ops 24000 yrs

Table A.2, Software Architecture

Table A.4- Software Design & Development

Table A.9 – Software Verification

Table B.1 – Coding Guidelines Table C.1, programming languages, mentions: ADA, Modula-2,  Pascal, FORTRAN 77, C, PL/M, Assembler, … Example for a guideline: MISRA-C: 2004,  Guidelines for the use of the C language in critical systems.

Table B.5 - Modelling

Certification Certiciation is the process of showing conformance to a standard . Conformance to IEC 61508 can be shown in two ways: Either that an organisation (company) has in principle the ability to  produce a product conforming to the standard, Or that a specific product (or system design) conforms to the standard.  Certification can be done by the developing company (self- certification), but is typically done by an accredited body. In Germany, e.g. the TÜVs or the Berufsgenossenschaften (BGs)  Also sometimes (eg. DO-178B) called `qualification ‘.

Basic Notions of Formal Software Development

Formal Software Development In formal development, properties are stated in a rigorous way with a precise mathematical semantics. These formal specifications can be proven . Advantages: Errors can be found early in the development process, saving  time and effort and hence costs. There is a higher degree of trust in the system.  Hence, standards recommend use of formal methods for high  SILs/EALs. Drawback: Requires qualified personnel (that would be you ).  There are tools which can help us by finding (simple) proofs for us, or  checking our (more complicated proofs). 

Summary Norms and standards enforce the application of the state-of-the-art when developing software which is safety-critical or security-critical .  Safety standards such as IEC 61508, DO-178B suggest development according to V-model: Verification and validation link specification and  implementation. Variety of artefacts produced at each stage, which have to  be subjected to external review.

Verifikation von C-Programmen Vorlesung 4 vom 13.11.2014: MISRA-C: 2004 Guidelines for the use of the C language in critical systems Christoph Lüth Universität Bremen Wintersemester 2014/15 04.12.2014 1 [38]

MISRA-Standard ◮ Beispiel für eine Codierrichtlinie ◮ Erste Version 1998, letzte Auflage 2004 ◮ Kostenpflichtig (£40,-/£10,-) ◮ Kein offener Standard ◮ Regeln: 121 verbindlich (required), 20 empfohlen (advisory) 2 [38]

Gliederung §1 Background: The use of C and issues with it §2 MISRA-C: The vision §3 MISRA-C: Scope §4 Using MISRA-C §5 Introduction to the rules §6 Rules 3 [38]

Anwendung von MISRA-C (§4) ◮ §4.2: Training, Tool Selection, Style Guide ◮ §4.3: Adopting the subset ◮ Produce a compliance matrix which states how each rule is enforced ◮ Produce a deviation procedure ◮ Formalise the working practices within the quality management system 4 [38]

MISRA Compliance Matrix 5 [38]

Die Regeln (§5) ◮ Classification of rules: ◮ Required (§5.1.1): “C code which is claimed to conform to this document shall comply with every required rule” ◮ Advisory (§5.1.2):“should normally be followed”, but not mandatory. “Does not mean that these items can be ignored, but that they should be followed as far as is reasonably practical.” ◮ Organisation of rules (§5.4) ◮ Terminology (§5.5) — from C standard ◮ Scope(§5.6) : most can be checked for single translation unit 6 [38]

Environment 1.1 (req) All code shall conform to ISO 9899:1990 “Pro- gramming languages — C”, amended and cor- rected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996 . 1.2 (req) No reliance shall be placed on undefined or unspecified 2 behaviour . 1.3 (req) Multiple compilers and/or languages shall only be 1 used if there is a common defined interface standard for object code to which the languages/compilers/as- semblers conform. 1.4 (req) The compiler/linker shall be checked to ensure that 1 31 character significance and case sensitivity are sup- ported for external identifiers. 1.5 (adv) Floating-point implementations should comply with a 1 defined floating-point standard . 7 [38]

Language extensions 2.1 (req) Assembly language shall be encapsulated and isolated. 1 2.2 (req) Source code shall only use /* ... */ style comments. 2 2.3 (req) The character sequence /* shall not be used within a 2 comment. 2.4 (adv) Sections of code should not be “commented out”. 2 8 [38]

Documentation 3.1 (req) All usage of implementation-defined behaviour shall 3 be documented. 3.2 (req) The character set and the corresponding encoding 1 shall be documented 3.3 (adv) The implementation of integer division in the chosen 1 compiler should be determined, documented and ta- ken into account. 3.4 (req) All uses of the #pragma directive shall be documen- 1 ted and explained. 3.5 (req) The implementation-defined behaviour and packing 1 of bitfields shall be documented if being relied upon. 3.6 (req) All libraries used in production code shall be written 1 to comply with the provisions of this document, and shall have been subject to appropriate validation . 9 [38]

Character sets 4.1 (req) Only those escape sequences that are defined in the 1 ISO C standard shall be used. 4.2 (req) Trigraphs shall not be used. 1 10 [38]

Identifiers 5.1 (req) Identifiers (internal and external) shall not rely on the 1 significance of more than 31 characters. 5.2 (req) Identifiers in an inner scope shall not use the same 1 name as an identifier in an outer scope, and therefore hide that identifier. 5.3 (req) A typedef name shall be a unique identifier. 2 5.4 (req) A tag name shall be a unique identifier. 2 5.5 (adv) No object or function identifier with static storage 2 duration should be reused. 5.6 (adv) No identifier in one name space should have the same 2 spelling as an identifier in another name space, with the exception of structure member and union member names. 5.7 (adv) No identifier name should be reused. 2 11 [38]

Types 6.1 (req) The plain char type shall be used only for storage and 2 use of character values. 6.2 (req) signed and unsigned char type shall be used only for 2 the storage and use of numeric values. 6.3 (adv) typedefs that indicate size and signedness should be 2 used in place of the basic numerical types. 6.4 (req) Bit fields shall only be defined to be of type unsigned 1 int or signed int. 6.5 (req) Bit fields of signed type shall be at least 2 bits long. 1 12 [38]

Constants 7.1 (req) Octal constants (other than zero) and octal escape 2 sequences shall not be used. 13 [38]

Declarations and definitions (I) 8.1 (req) Functions shall have prototype declarations and the 1 prototype shall be visible at both the function defini- tion and call. 8.2 (req) Whenever an object or function is declared or defined, 1 its type shall be explicitly stated. 8.3 (req) For each function parameter the type given in the 2 declaration and definition shall be identical, and the return types shall also be identical. 8.4 (req) If objects or functions are declared more than once 2 their types shall be compatible. 8.5 (req) There shall be no definitions of objects or functions 2 in a header file. 14 [38]

Declarations and definitions (II) 8.6 (req) Functions shall be declared at file scope. 1 8.7 (req) Objects shall be defined at block scope if they are 2 only accessed from within a single function. 8.8 (req) An external object or function shall be declared in one 2 and only one file. 8.9 (req) An identifier with external linkage shall have exactly 2 one external definition. 8.10 (req) All declarations and definitions of objects or functions 3 at file scope shall have internal linkage unless external linkage is required. 8.11 (req) The static storage class specifier shall be used in defi- 3 nitions and declarations of objects and functions that have internal linkage. 8.12 (req) When an array is declared with external linkage, its 2 size shall be stated explicitly or defined implicitly by initialisation. 15 [38]

Initialisation 9.1 (req) All automatic variables shall have been assigned a va- 3 lue before being used. 9.2 (req) Braces shall be used to indicate and match the struc- 1 ture in the non-zero initialisation of arrays and struc- tures. 9.3 (req) In an enumerator list, the “=” construct shall not be 1 used to explicitly initialise members other than the first, unless all items are explicitly initialised. 16 [38]

Arithmetic type conversions (I) 10.1 (req) The value of an expression of integer type shall not 2 be implicitly converted to a different underlying type if: a) it is not a conversion to a wider integer type of the same signedness, or b) the expression is complex, or c) the expression is not constant and is a function argument, or d) the expression is not constant and is a return expression. 17 [38]

Arithmetic type conversions (II) 10.2 (req) The value of an expression of floating type shall not 1 be implicitly converted to a different type if: a) it is not a conversion to a wider floating type, or b) the expression is complex, or c) the expression is a function argument, or d) the expression is a return expression. 18 [38]

Arithmetic type conversions (II) 10.3 (req) The value of a complex expression of integer type shall 2 only be cast to a type of the same signedness that is no wider than the underlying type of the expression. 10.4 (req) The value of a complex expression of floating type 1 shall only be cast to a floating type which is narrower or of the same size. 10.5 (req) If the bitwise operators ˜ and < < are applied to an 2 operand of underlying type unsigned char or unsigned short, the result shall be immediately cast to the un- derlying type of the operand. 10.6 (req) A “U” suffix shall be applied to all constants of unsi- 2 gned type. 19 [38]

Pointer type conversions 11.1 (req) Conversions shall not be performed between a pointer 1 to a function and any type other than an integral type. 11.2 (req) Conversions shall not be performed between a pointer 1 to object and any type other than an integral type, another pointer to object type or a pointer to void. 11.3 (adv) A cast should not be performed between a pointer 1 type and an integral type. 11.4 (adv) A cast should not be performed between a pointer to 1 object type and a different pointer to object type. 11.5 (req) A cast shall not be performed that removes any const 1 or volatile qualification from the type addressed by a pointer. 20 [38]