Verification Modulo Versions: Towards Usable Verification

Explore the challenges and solutions in compile-time verification with CodeContracts in Visual Studio. Delve into addressing warnings, improving analysis precision, and managing syntactic baselines for a more reliable verification process.

• Verification
• Compile-time
• CodeContracts
• Analysis
• Precision

ekha Follow

Uploaded on Sep 28, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. Verification Modulo Versions Towards usable verification F. Logozzo, S. K. Lahiri, Microsoft Research, Redmond M. Fahndrich, now at Google S. Blackshear, Univ. Colorado, Boulder

2. Background

3. CodeContracts in VS Compile-time verification 100% Abstract interpretation Used internally at MSFT > 120K external downloads Failed precondition

4. Too many warnings

5. Too many warnings: Now what? False myth: Analysis too imprecise, let s improve the analysis In practice, the analysis is precise enough Problem: It lacks information on external libraries, environment, physical world Academic solution: Address each warning Add assumes, out-of-bands contracts Practice: No one is going to do it Too expensive Pragmatic: Syntactic baseline Unsound and unreliable

6. Disclaimer: over-simplified schema Syntactic baseline New version (k Renamed) Base version /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var k = c + 273.15; /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var kelv = c + 273.15; mask assertion at line 3 1: 2: 1: 2: 3: Contract.Assert(k >= 0); 3: Contract.Assert(kelv >= 0); 4: return k; 4: return kelv; } } Valid, but can t prove assertion Masked: No alarm

7. Syntactic baseline: Fail to spot regression New version (wrong constant) Base version /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var k = c + 273.15; /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var k = c + 273.0; mask assertion at line 3 1: 2: 1: 2: 3: Contract.Assert(k >= 0); 3: Contract.Assert(k >= 0); 4: return k; 4: return k; } } Masked regression!

8. Syntactic baseline: Resurrect alarm New version (value rounded) Base version /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var k = c + 273.15; /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var k = c + 273.15; mask assertion at line 3 1: 2: 1: 2: 3: Contract.Assert(k >= 0); 3: var round = Math.Round(k, 2); 4: Contract.Assert(round >= 0); 4: return k; } 5: return round; } Alarm Resurrected

9. Straw man? Of course, we can refine the former syntactic baseline technique Add the assertion name, have a window instead of line number However, they are always brittle, and provide no guarantee Suppress too little Is the alarm resurrected from the old one? Suppress too much Is the masked alarm a new alarm?

10. Verification Modulo Versions Intuition

11. VMV: Verification modulo versions Analyze Instrument P P P +C New version Base version Instrumented Analyzer is a black box Reduce alarms up to 70% With semantic guarantees!!!

12. VMV(S): Finding regressions Instrumented new version Base version /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var k = c + 273.15; /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); Contract.Assume(c >= -273.15); Result(ReadTemperature) -273.15 1: 2: 1: 3: Contract.Assert(k >= 0); 2: var k = c + 273.0; 4: return k; 3: Contract.Assert(k >= 0); Correct c -273.15 } 4: return k; } Report regression!

13. VMV(N): Relative proofs Instrumented new version Base version /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); var k = c + 273.15; /// Get temperature in Kelvin double GetCurrTemperature() { // In Celsius var c = ReadTemperature(); Contract.Assume(c >= -273.15); Result(ReadTemperature) -273.15 1: 2: 1: 3: Contract.Assert(k >= 0); 2: 3: var round = Math.Round(k, 2); 4: Contract.Assert(round >= 0); var k = c + 273.15; 4: return k; Correct c -273.15 } 5: return round; } Relative correctness

14. Questions 2. How do we inject them? Analyze Instrument P P P +C New version Base version Instrumented 3. What guarantees? 1. What conditions?

15. Verification Modulo Versions Formalization

16. Q1. What conditions? Critical to distinguish between sufficient and necessary conditions A sufficient condition S implies the program correctness S program has no bad runs S can be under-approximated At worst false A necessary condition N holds in all correct runs If R is a good program run, then R N N can be over-approximated At worst true

17. Example: Sufficient vs. Necessary public void Foo() { int ret, x; if(*) { ret = API(); x = ret + 1; } else { ret = API(); x = ret - 1; } Property of good runs Strongest Necessary for API ret > 99 ret >101 = ret > 99 ret > 99 Removes all bad runs Weakest Sufficient for API ret > 99 ret >101 = ret > 101 ret > 101 Contract.Assert(x > 100); }

18. Q2: Matching and injection public void Foo() { int ret, x; if(*) { ret = API(); x = ret + 1; } else { ret = API(); x = ret - 1; } public void Foo() { int x; x = API(); Contract.Assert( ); } Match method calls Other matching solutions: Program points, Sequences of method calls, See paper In general More refined matching more precision More refined matching more brittle Contract.Assert(x > 100); }

19. Q3: What semantic guarantees for P? Using sufficient conditions Short VMV(S) Theorem: All warnings in P + S are new alarms S was sufficient to shut off all alarms in P Each new alarm in P +S is either 1. in new code or 2. S is not strong enough Nothing can be said on the verified assertions E.g., S can be too strong VMV(S) useful for bug finding

20. Example of VMV(S) public void Foo() { int ret, x; if(*) { ret = API(); x = ret + 1; } else { ret = API(); x = ret - 1; } public void Foo() { int x; x = SomeAPI(); Contract.Assume(x > 101); Recall Suff. condition: Result(API) > 101 Contract.Assert(x > 105); } Regression: Ask more to API Contract.Assert(x > 100); }

21. Q3: What semantic guarantees for P? Using necessary conditions Short VMV(N) Theorem: All proven assertions in P + N are correct w.r.t. P N holds in all good runs of P Each proven assertion in P + N is either 1. because of an assume from N, or 2. absolute, i.e., without assumptions from P Alarms may be new or old ones E.g. N can be too weak VMV(N) is useful for relative verification

22. Example of VMV(N) public void Foo() { int ret, x; if(*) { ret = API(); x = ret + 1; } else { ret = API(); x = ret - 1; } public void Foo() { int x; x = SomeAPI(); Contract.Assume(x > 99); Contract.Assert(x > 0); Recall Nec. condition: Result(API) > 99 } Relative verification: Holds for good runs of P Contract.Assert(x > 100); }

23. Experiments

24. Experimental setting Match method calls cccheck.exe Instrument P P P +N New version Base version Instrumented Necessary relative verification Cccheck.exe checks safety properties Contracts and runtime exceptions null-pointers, division by zero, buffer overruns, arithmetic overflow, enums

25. Windows Azure ActorFX framework Three months between P and P VMV(N) dramatically reduces the number of alarms (roughly by 70%) Eliminated great majority of the warnings from external non-annotated API Added annotations to P + N to go to 0 warnings, i.e., relative correct Less than 3 hours overall Found bugs, reported to the developers

26. Conclusions

27. More in the paper Scenarios Greek letters Numbers Abstraction of necessary/sufficient Role of imprecision in the analyzer Abstract regressions in VMV(S) Impact of non-monotonic analyzers i.e., all tools out there Self application Analyze P+N Related work

28. Conclusions Match method calls Analyze Instrument P P P +C New version Base version Instrumented Sufficient bug finding Necessary Sufficient or Necessary relative verification

29. Backup slides

30. Comparison with syntactic baseline Our starting point: Syntactic baseline in cccheck.exe Problems: Suppresses too much No semantic guarantee VMV addresses those problems In practice: Both options available to users

31. Related work Industrial tools: Coverity, Polyspace, Abductor They: Tool-specific syntactic matching and/or hashing VMV: General, rigorous framework, semantic-based Differential Assertion Checking [Lahiri et al. FSE 13] They: Construct and analyze product program VMV: Framework for augmenting any static analysis, lightweight(pre+post processing) Differential symbolic execution methods [Person et al. FSE 08, Ramos et al. CAV 11] They: Special analyzers for finding differences, no semantic relative guarantees

32. Related work Enhanced Diff tools: Smart strategies to find syntactic changes among versions Orthogonal to our work, can only enhance VMV Annotation inference: Our framework is independent of the inference technique We consider both sufficient and necessary

33. Experimental setting Implemented VMV(N) in Clousot/cccheck Developed for 7+ years at Microsoft Research Used by .NET programmers, free download, VS integration Internal and external adoption Abstract interpretation-based Analyze program to infer invariants at each program point Use invariants to discharge proof obligations Contracts, null-pointers, division by zero, buffer overruns, arithmetic overflow, enums . Infer necessary conditions Run on very large code bases Internal and open source