Symbolic Execution Engine for Haskell
G2 is a symbolic execution engine for Haskell, a non-strict, functional programming language. Symbolic execution is a technique that runs a program with symbolic variables as inputs, and gives output in terms of expressions and constraints involving those symbolic variables. By using SMT solvers to solve the constraints, G2 can find concrete inputs to Haskell programs that satisfy assumptions or violate assertions.
G2 has been applied to generate concrete and counterfactual counterexamples for errors from the LiquidHaskell modular verification tool. Concrete counterexamples identify actual errors in the users code, while counterfactual counterexamples identify output specifications that must be strengthened to enable verification.
People involved in the project:
William T. Hallahan
Recent Publications:
William T. Hallahan, Anton Xue, Maxwell Troy Bland, Ranjit Jhala and Ruzica Piskac.
Lazy counterfactual symbolic execution.
In Proceedings of the 40th ACM SIGPLAN Conference on Programming
Language Design and Implementation, PLDI 2019, Phoenix, AZ, USA,
June 22-26, 2019., 2019.
William T. Hallahan, Anton Xue and Ruzica Piskac.
G2Q: Haskell constraint solving.
In Proceedings of the 12th ACM SIGPLAN International Symposium on Haskell. 2019.
Privacy Preserving Formal Methods
potential to allow auditors and regulators -- such as Apple and Google in their roles as app store maintainers -- to verify programs without the developer needing to expose their valuable software. Another component of PPFM is privacy preserving satisfiability solving (PPSat). Boolean satisfiability is an essential problem in verification, and in computer science more generally. Our work allows multiple parties to check a conjunction of logical formulae. An example application is to allow two network routers to coordinate traffic while maintaining privacy of their configurations.
People involved in the project:
Timos Antonopoulos, Ning Luo, Samuel Judson
Functional Reactive Synthesis
People involved in the project:
Mark Santolucito, William T. Hallahan
Mark Santolucito, William T. Hallahan, and Ruzica Piskac.
Live programming by example.
In Extended Abstracts of the 2019 CHI Conference on Human
Factors in Computing Systems, CHI 2019, Glasgow, Scotland, UK, May 04-09,
2019., 2019.
Verifications for Configuration Files
Modern verification technologies inherently depend on the availability of formal specifications, yet they are extremely labor intensive to create and maintain. This is especially the case for configuration files, which rarely have any documentation, even in written English form. Configurations are the values of system parameter settings; Incorrect configurations often lead to system misbehaviours such as exceptions, error code return, crashing or even core dump.
We have developed ConfigV, which is the first tool that can automatically detect complex errors involving multiple variables, and learn over a training set of partially incorrect configuration files. Since configuration files lack helpful semantic information to infer types, we use a probabilistic inference method to learn likely types for keywords based on their values from the training set. We combined this new type of information with a generalization of association rule learning that handles not just association rules, but arbitrary, typed predicates. We evaluated ConfigV by verifying public configuration files on GitHub, and we showed that ConfigV can successfully detect configuration errors in these files.
People involved in the project:
Mark Santolucito, Jialu Zhang
Recent Publications:
Mark Santolucito, Ennan Zhai, Rahul Dhodapkar, Aaron Shim, and Ruzica Piskac.
Synthesizing configuration file specifications with association rule
learning.
PACMPL, 1(OOPSLA):64:1--64:20, 2017.
Software updates and configuration files
Software updates are important to apply, because they often solve security issues, improve the performance of the software or add new interesting features. However, when a software is updated, such as a server software, its execution changes in a way that system administrators are not necessarily aware of. Since configuration space is very big, not all configurations can be tested before a release. A perfectly fine configuration for a previous version of the software can become problematic as the meaning of the configuration changes.
We propose to use the behavior of the previous version of the software under the existing configuration as a specification of the intended behavior. Our goal is to check the new version for potential violation of this specification, under the same or modified configuration.
People involved in the project:
Julien Lepiller