Certifying delta-oriented programs

Abstract

A major design concern in modern software development frameworks is to ensure that mechanisms for updating code running on remote devices comply with given safety specifications. This paper presents a delta-oriented approach for implementing product lines where software reuse is achieved at the three levels of state-diagram modeling, C/$\text {C}^{_{_{_{++}}}}$source code and binary code. A safety specification is expressed on the properties of reusable software libraries that can be dynamically loaded at run time after an over-the-air update. The compilation of delta-engineered code is certified using the framework of proof-carrying code in order to guarantee safety of software updates on remote devices. An empirical evaluation of the computational cost associated with formal safety checks is done by means of experimentation.

Appendices

Appendices

1.1 Appendix A: Consistency check using the Z3 SMT solver

This appendix shows the Z3 [25] SMT solver scripts that check the satisfiability and validity of the consistency specification established between the state-diagram and build-system DOP product lines. The consistency $\varSigma$-theory [57] is formalized using constraints between pairs of deltas that share the same index in the application order. Further, the configuration knowledge (CK) of the DOP-SPL is consistent only if there is an activation rule for every delta index. The activation rules are defined in conjunctive normal form (CNF) and implicitly determine the application order.

In order to demonstrate the use of Z3 encoding of the $\varSigma$-theory presented in Sect. 5.2 consider two delta indexes and, correspondingly, two activation rules. Next, we present the CKs of the two DOP-SPLs under consideration. The delta sequences under consideration are $\langle \delta _1 \mathbin {;} \delta _1 \rangle$ and $\langle \dot{\delta }_1 \mathbin {;} \dot{\delta }_1 \rangle$, respectively.

• 1. Configuration Knowledge of the State Diagram DOP-SPL:

$F_1$	$\delta _1$
$F_1 \wedge F_2$	$\delta _2$

• 2. Configuration Knowledge of the Filenames DOP-SPL:

$F_1$	$\dot{\delta }_1$
$F_1 \wedge F_2$	$\dot{\delta }_2$

The Z3 definitions are given in Listing 1. The encoding of theory specifying the cross-consistency between the state-diagram DOP-SPL and the build-system DOP-SPL is presented in Listing 2, and the encoding of the DOP semantics with respect to cross-consistency between SPLs is given in Listing 2. The source script is available at https://github.com/esmifro/CertifiedDOP/tree/master/z3.

Examples of valid and unsatisfiable instances of product lines are described in Listing 4, Listing 5 and Listing 6.

The following encoding SPL shows that both deltas have the same position in the order and both declare the functions named name_1 and name_2 and the corresponding filenames (which must have the same name). Further, the predicate ck is satisfiable for every formula and delta index. This instance corresponds to a single virtual product (cf. Sect. 5) that is satisfiable.

The constraints (assert (=> (ck formula_1 index_2) false)) and (assert (=> (ck formula_1 index_2) false)) are necessary to properly encode CK (1) and CK (2).

Now consider Configuration Knowledge that is inconsistent, where $F_2$ is disabled by writing (assert (= false feature_2)). In this case, the activation rule for index_2 is not satisfiable. Therefore, the answer from the SMT solver is going to be “unsat”.

Now consider the case of inconsistency between deltas, $\delta _1$ and $\dot{\delta }_1$, written (assert (=(state “name_1” index_1) false)). The answer from the SMT solver is again going to be “unsat”.

1.2 Appendix B: The COQ proof system

This appendix shows the COQ definitions required to define the safety specification presented in Sect. 6. Listing 1 shows the inductive definitions for symbols, where the ELF type is an “ascii,” table of symbols and delta actions. The dynamic semantics of the delta-oriented “apply” function is encoded by predicate Apply in Listing 2. The definitions for types of symbols and table of symbols are shown in Listing 3.

Listing 4 shows the encoding of typed symbols and delta actions ($e \mathbin {:} \tau$), and the safety predicate Resolved. Finally, the inductive definitions for well-typed values (table of symbols) are shown in Listing 5. The proof of the safety theorem, which is presented in Sect. 6, is shown in Listing 6, and the required tactics to solve the verification conditions are given in Listing 7.

1.3 Appendix C: Haskell interpreter for the PCC agent

This appendix shows the Haskell source code that implements an interpreter for the big-step semantics of the PCC Agent presented in Table 6 and Sect. 6. The complete source-code project is available at https://github.com/esmifro/CertifiedDOP.

Listing 1 shows the algebraic datatypes used to represent tables of symbols, the verification-condition proof result and other type constructors for files and directories. The internal function signatures shown in Listing 4 are defined exclusively over the Internal domain. Listing 2 shows the algebraic datatypes and types used by the interpreter using Monad transformers (runCheck). The correspondence between high-level syntax and system-(Linux)level syntax is stored inside the map MetaMap. Abstract programs are created using Command.

The interpreter shown in Listing 3 implements the big-step semantics of the PCC Agent. For each of the big-step relations, that is, for variables, expressions and commands, there is a correspondent interpretation function. The map between abstract functions and internal functions is defined in Listing 4.

Finally, the function that runs the interpreter with a given set of arguments is shown in Listing 5.