The Future of Correct Software George Necula

2 Software Correctness is Important ► Where there is software, there are bugs ► It is estimated that software bugs cost the economy over $60B a year (1% of GDP)  Average cost of downtime can be $1M/hour ► Software bugs are responsible for over 50% of known security vulnerabilities

3 Software Correctness is Hard ► Social challenges  Customers still favor features and performance  Programmers notoriously overconfident ► Economic challenges  Correctness costs more than extra features ► Technical challenges  Impossible to build perfect software quality tools  False alarms and missed errors are facts of life

4 The Open Source Quality Group ► Members  Rastislav Bodik, George Necula, Sanjit Seshia  Collaborators at Stanford, Microsoft, IBM, Intel  And 15 graduate students ► Develop techniques and tools for building, deploying and monitoring quality software ► Use Open Source software as a test bed

5 1. Building Correct Software ► Tools can help only if we bring more information in the software process ► Find unobtrusive ways to get programmer assistance with correctness reasoning  Programs express “how” things must be done  Programmers know the “what” and “why” ! ► Example: Programming by sketching  by Rastislav Bodik, Sanjit Seshia

6 The Sketching Experience sketch implementation (completed sketch) spec specification +

7 Promising Properties Sketched programs are developed … rapidly: the low-level details are synthesized automatically correctly: implementation guaranteed to behave like the specification

8 Example: Sorting by hand int[] merge (int[] a, int b[], int n) { for (int i = 0; i < n; i++) if ( j<n && ( !(k<n) || a[j] < b[k]) ) { result[i] = a[j]; j++; } else { result[i] = b[k]; k++; }} return result; } ► The devil is in the details

9 int[] merge (int[] a, int b[], int n) { for (int i = 0; i < n; i++) if ( synthesize( ||, &&, <, !, [] ) ) { result[i] = a[j]; j++; } else { result[i] = b[k]; k++; }} return result; } ► Sketch compiler fills in the details correctly ► Sketches are programs with missing details ► Specifications can be slow/simple programs Sorting sketched hole

10 Experience with Sketching Ciphers User experiment:  goal: implement a mini-cipher  how: C programmer vs. sketching programmer Results:  sketching programmer was twice as fast  sketched cipher ran 50% faster Next: sketching for general purpose programs

11 2. Deploying Correct Software ► Today’s view of software:  Software is executable ► Future view of software:  Software is checkable and executable ► We need to redefine what software is: Software = Executable content Software = Executable content + Assurance support + Assurance support

12 Today: Digital Signatures CPU Code Consumer Signature Checking Trust the code producer Not a behavioral assurance Dangerous ! Does not scale well Good but not enough

13 Future: Semantic Assurance CPU Code Consumer Safety Proof Proof Checking Proof-carrying code Provides semantic assurance Producer does the hard work C ode producer “helps” the consumer to check the code

14 Challenges ► How small can you make the proofs?  Today about 25% of the code and shrinking ► How do you generate proofs ?  Certifying software synthesis tools (compilers)  Automatic today for memory safety, resource usage constraints ► Next: make more software tools certifying

15 3. When Everything Else Fails ► The future of correct software must include incorrect software ► We must deal with execution errors  Monitoring, recovery, restarting, … ► Example: Cooperative Bug Isolation

16 Post-Deployment Monitoring Cooperative Bug Isolation

17 Idea: Measure Reality ► Go beyond measuring crashes ► Monitor good and bad executions  Spread cost of monitoring over many users  Collect feedback data & mine for bug causes ► Actual user runs are a vast resource  Number of real runs >> number of testing runs  Real-world executions are most important

18 Bug Isolation Architecture Program Source Compiler Sampler Shipping Application Prole /  Statistical Debugging Top bugs with likely causes

19 Public Deployment in Progress ► Applications do have bugs ► Attract more users for statistical analysis

20 Conclusion ► Social factors will work in favor of software correctness ► Technology must provide affordable solutions for correctness  Bring more information into software process  Software synthesis from high-level specifications  Software distributions with assurance support ► Good error handling always important