If(BC,i1)=compilestmt(m,S,i0), and ASin[m,i0]=², then 1. IR=BC2IRrng(BC,m, [i0,i1[)exists, and
2. ASin[m,i1]=².
The main lemma of the second part of the proof shows that for every high-level typing judgement, there is a corresponding IR type mapping.
Lemma 5.14 Let(BC,i1)=compilestmt(m,S,i0), and IR=BC2IRrng(BC,m, [i0,i1[. Let
∆be a confluence point stack that does not contain any variable or field modified by S.
IfΓ,pc `{Q}S {Q0}, then there exists a temporary variable type environmentΓt and a type mappingΛderivable for IR,Γ, andΓtsuch that
1. Λ(i0)=(pc,∆,Q), and 2. Λ(i1)=(pc,∆,Q0).
The main type preservation theorem follows as a corollary by unfolding the defini-tions of well-typedness.
5.6 Putting It All Together
I have now presented almost all parts that constitute the DSD verification framework.
Figure 5.5 on the next page is a repetition of the overview diagram from the introduction (see page 12), with all parts annotated with the numbers of the sections where I have presented the respective definitions (boxes in the figure), algorithms (solid arrows), or theorems (dotted arrows).
For the actual implementation, there are still two parts missing — namely the type check algorithms that fully automatically determine whether a given high-level or IR program is well-typed. So far, I have only declaratively described what constitutes a valid type derivation, leaving open the task of finding such derivations.
In the next chapter, I therefore show how to transform the presented type systems into a type check algorithm, before I present the implementation of the verification framework.
DSD program with flow checks(2.1)
DSD type derivation
(3.1–3.4)
type check
(6.1–6.2)
bytecode program with flow checks(4.1)
compile
(4.2)
IR version of bytecode program(5.1)
translate(5.3)
IR type derivation
(5.4)
type check(6.3)
DSD program is universally noninterferent(2.3)
soundness
(3.5)
IR program is
universally noninterferent(5.2)
soundness(5.4)
bytecode program is universally noninterferent(4.3)
semantic correspondence between BC and IR(5.3)
typability is preserved
(5.5)
Figure 5.5: The verfication framework, and the corresponding sections
Automatic Type Inference and 6
Implementation
The type systems presented in the preceding chapters declaratively describe which typing judgements are valid. For an actual implementation, I have not yet explained howto automatically determine whether a given program has a valid typing judge-ment. This chapter presents an automatictype inferencefor high-level DSD and for IR programs, and presents several aspects of the implementation I have developed.
The task that usually constitutes a type inference – determining the types of expres-sions – is comparatively easy. Moreover, as all method signatures have to be provided by the programmer, the type inference for DSD is a purely intra-procedural mecha-nism. The main difficulties lie in solving the label order side conditions (Section 6.1), in computing the pre- and post-conditions for each statement (Section 6.2), and, for IR code, in finding a suitable, consistent type mapping (Section 6.3). These aspects come together in the prototypical implementation of the entire framework, described in Section 6.4.
6.1 Solving Label Order Conditions
The type systems for the high-level DSD language and the intermediate representation contain numerous side conditions on the order of labels. Therefore, any implemen-tation of an automatic type inference repeatedly has to solve side conditions on the order of labels. More precisely, given a constraint setQand two labels`1and`2, the algorithm has to decide whether`1vQ`2can be derived or not.
`vQ` ⊥ vQ` `vQ> `vQ`t`0 (`1,`2)∈Q
`1vQ`2
`1vQ`3 `2vQ`4
`1t`2vQ`3t`4
`1vQ`2 `2vQ`3
`1vQ`3
`≡Q`t` `1t`2≡Q`2t`1 `1t(`2t`3)≡Q(`1t`2)t`3
`1≡Q`2
`1vQ`2
`1≡Q`2
`2vQ`1
`1vQ`2 `2vQ`1
`1≡Q`2
Figure 6.1: Rules for label order equality (repeated)
The solution is not obvious from the rules for label order and label equalities defined in Section 3.2 on page 33. For reference, they are presented here again in Figure 6.1.
It is difficult to follow the rules in a bottom-up fashion to determine whether a given label order is justified, because the rules are not syntax-directed: for one thing, it is not always clear which rule to apply; for another thing, the instantiations may be not unique, for example when the correct label`2has to be chosen in the transitivity rule.
On the other hand, one cannot generate all possible label order pairs from a given set Qand check whether the given flow is contained, because the first four rules generate an infinite set of such pairs for arbitrary syntactic labels`∈Lab.
Fortunately, many of the rules are in fact independent of the constraint setQ. For example, the first four rules describe basic lattice properties, and the label equality rules in the third row describe the properties of the least upper bound operatort.
The rules which do depend onQ, in contrast, can be used to generate a hull ofQthat remains finite. The solution is thus to split the inference into two parts.
To simplify the algorithm, all labels that occur during the inference are first trans-formed into a normalized, canonical form. For this, I take the algebraic definition of a complete semi-lattice, which is given by the following equations:
`1t`2 = `2t`1 (commutativity) (`1t`2)t`3 = `1t(`2t`3) (associativity)
`t` = ` (idempotence)
`t ⊥ = ` (neutral element)
`t > = > (top element)
The label normalization algorithm essentially understands these rules as left-to-right rewrite rules. Each label is treated as a list of operator-free atomic labels that are connected by the least upper bound operatort. A label is normalized by ordering all its
6.1 Solving Label Order Conditions atomic labels with respect to some fixed and previously defined order on atomic labels, by removing duplicate atomic labels, by removing the atomic label⊥, by removing all other atomic labels if the entire label contains>, and by structuring the least upper bound list right-associatively.
The following rule expresses the correspondence between the algebraic definition of a lattice to its definition as a partially ordered set:
`1t`2=`2
`1vB`2
It can be shown that the defined relations are derivable in the original system.
Lemma 6.1 The relations=andvB are sound with respect to the label equality and label order relation over an empty constraint set:
1. `1vB`2 ⇒ `1v;`2and 2. `1=`2 ⇒ `1≡;`2.
It turns out that two labels are equal with respect to≡; if they are structurally equal. Also, the rule above conveniently links the label normalization algorithm to the inference of arbitrary tautologies, that is, label order judgements over an empty constraint set.
PROOF The second implication follows from the definitions. All equalities shown above can be derived as label equalities≡;in the original rules. This fact can be used in the first implication: we get`1t`2≡;`2, thus we can derive`1t`2v;`2. Together with
`1v;`1t`2, we get by the transitivity rule`1v;`2. I define another relationvQHusing the rules that do depend onQ. They only generate order information for labels that are inQ. In the algorithm, all labels generated by the rules are immediately normalized. This way, the number of derivedvH judgements is always finite, and can be used in the implementation to precompute a closure or
“hull”.
(`1,`2)∈Q
`1vQH`2
`1vQH`3 `2vHQ`4
`1t`2vHQ`3t`4
`1vHQ`2 `2vB`02 `02vQH`3
`1vQH`3
Finally, the relationvQAis defined in terms ofvQH andvBto determine whether a given flow follows from a constraint setQ:
`1vB`2
`1vQA`2
`1vB`2 `2vQH`3 `3vB`4
`1vQA`4
I use this relation in the algorithmic definition of constraint set implication:
Q ⇒A Q0 if and only if ∀(`1,`2)∈Q.`1vQA`2
The algorithmic relation vQA and the algorithmic constraint set implication are correct with respect to the label order relationvQ, and the original constraint set implication. This is formalized in the following lemma.
Lemma 6.2 The algorithmic label order and the algorithmic constraint set implication are correct with respect to their original definitions, that is,
1. If`1vQA`2then`1vQ`2. 2. If Q ⇒A Q0then Q ⇒Q0.
PROOF For the first implication, it is easy to see that all the rules above can be derived from the original rules, if one takes into account Lemma 6.1. The second implica-tion follows from the first one and the definiimplica-tion of the original and the algorithmic
constraint set implication.