Temporal-Logic Constraints in

Feature-Oriented VerificationKathi Fisler (WPI)

joint work with Shriram Krishnamurthi (Brown)

Colin Blundell (Brown; now at UPenn)Pascal Van Hentenryck (Brown)

An Email Product Line

Base Encrypt Decrypt Sign Auth

Base Encrypt DecryptSign Auth

Base Sign Auth

A Desired Product Property

Signed emails can always be authenticated

Base Encrypt DecryptSign Auth

Decrypting mangles the

signature

Mix-and-Match Systems

F1 F2 F4Sign

Sign F2 F4F1

F4 F3 F2F1

F3 F4 SignF2

There is nosingle “program”!

The number ofconfigurations is

enormous…

Model Checking Product Lines

• Features unaware of other features and their requirements by design

• Products often contain bugs as a result– “feature interaction problem”

• Modular reasoning essential to cope with design space (not product size)

Modeling Features and Products

Points of entry (s0) and exit (s2)

signs1

s0 s2Sign

Base Sign Auth

Product: a sequential composition of features

Feature:

Verification Problem (1)

• Have a set of features and a property that should hold of all products

• Verify property against each feature separately

• Combine results to show property holds of product

Try Model Checking

Problems:• Sign feature has no knowledge of

encrypted• Property must hold globally

– but there is no temporal information at s2

What value to return?

signs1

s0 s2

AG(encrypted AF decrypt)

Model Checking’s Limitation

• Model checking designed to give a yes/no answer about a closed system

• Features are inherently open systems

Model Checking’s Limitation

Two sources of openness:• values of (some) propositions• behavior along paths from exit

signs1

s0 s2

AG(encrypted AF decrypt)

Verification Problem (2)

• Have a set of features and a property that should hold of all products

• Derive constraint on each feature that is sufficient to preserve property – expensive verification should happen here

• Check constraints when form product– this step should be lightweight

Feature Constraints

• Where does value of encrypted come from?– from an earlier feature (enter at s0)

• Where do rest of control paths come from?– from the subsequent features (exit at s2)

Want a constraint parameterized on these values

signs1

s0 s2

AG(encrypted AF decrypt)

Constraint Contents

If encrypted is true at s0, what is required at s2?

AF decrypt What must hold at s2 regardless of

encrypted? AG(encrypted AF decrypt)

signs1

s0 s2

AG(encrypted AF decrypt)

The Computed Constraint

[AG(encrypted AF decrypt)]s2

encrypted v [AF decrypt]s2

signs1

s0 s2

AG(encrypted AF decrypt)

constraint parameterized over both data and control values

Computing Constraints

[AG(encrypted AF decrypt)]s2 encrypted v [AF decrypt]s2

signs1

s0 s2

AG(encrypted AF decrypt)

Modification of basic model checker:• Propositions: return name if value unknown• Terminal states: return annotated formula

Discharging Constraints

SignBase Encrypt Decrypt Auth

[AG(encrypted AF decrypt)]s2

encrypted v [AF decrypt]s2

encrypted

[AG(encrypted AF decrypt)]s2 ,

[AF decrypt]s2

effectivelypropositional

Verification Given Property P

F3F1 F2 F4 F5

C3PC1P C2P C4P C5P

D3 D1 D2 D4 D5

D1 D1 o D2 … …

C5(D1-5)… … …

Undiscussed Details

• Dataflow computation for data values

• Propositional reasoning actually 3-valued– handles data values across different

paths

• Can use simpler reasoning about individual features in some cases

Case Study

• Conducted on an email suite that exhibits many property violations (previously discovered manually by Robert Hall [FITS 00])

• Tested 9 properties; detected all violations successfully (each one a feature interaction)

• Detected violations without traversing features at composition time

Limitations

• Current algorithm cannot handle cyclic feature compositions (DAGs fine)– supports pipe-and-filter architecture– have other work (heavier checks) supporting

cyclic compositions and liveness properties [Fisler/Krishnamurthi FSE2001, FSE2004]

• Cycles within individual features cannot set data propositions used in properties

Perspective

A non-trivial class of systems needs• openness due to design considerations• sequential composition• looser forms of modular verification

Traditional modular verification seems mismatched with these demands

Our property-driven constraint generation targets these systems