Abstract
This paper describes Kratos2, a tool for the verification of imperative programs. Kratos2 operates on an intermediate verification language called K2, with a formally-specified semantics based on smt, allowing the specification of both reachability and liveness properties. It integrates several state-of-the-art verification engines based on sat and smt. Moreover, it provides additional functionalities such as a flexible Python api, a customizable C front-end, generation of counterexamples, support for simulation and symbolic execution, and translation into multiple low-level verification formalisms. Our experimental analysis shows that Kratos2 is competitive with state-of-the-art software verifiers on a large range of programs. Thanks to its flexibility, Kratos2 has already been used in various industrial projects and academic publications, both as a verification back-end and as a benchmark generator.
A. Griggio has been partly supported by the project “AI@TN” funded by the Autonomous Province of Trento and by the PNRR project FAIR - Future AI Research (PE00000013), under the NRRP MUR program funded by the NextGenerationEU. M. Jonáš has been partly supported by the Czech Science Foundation grant GA23-06506S.
You have full access to this open access chapter, Download conference paper PDF
Similar content being viewed by others
1 Introduction
We present Kratos2, a tool for the verification of real-world imperative programs. Kratos2 is a complete rewrite and redesign of Kratos [17], improving and extending it in multiple directions. First, Kratos2 introduces a simple yet expressive intermediate language called K2, with a formally-specified semantics based on Satisfiability Modulo Theories (smt), which is parametric on the underlying smt theory. K2 is expressive enough to capture most of the features of real-world C programs, such as pointers, dynamic memory allocation, floating-point data types, and bit-precise semantics of bounded integers, which the old version of the tool could not handle (being limited to C programs without pointers and recursion, and in which C integers were interpreted as mathematical integers). Kratos2 comes with a separate C front-end c2Kratos that can translate C programs to K2. Second, Kratos2 includes a variety of state-of-the-art verification back-ends based on either symbolic model checking or symbolic execution with sat and smt solvers. Besides reachability properties, Kratos2 also supports various forms of liveness properties, which can be used to encode termination and more complex linear-time temporal properties. Third, Kratos2 implements an interactive interpreter, which can simulate K2 programs using non-deterministic inputs provided either by the user or by external oracles. Kratos2 also supports counterexample reconstruction, another feature not available in the original Kratos.
The new intermediate language K2 enables modular translation of C programs into various verification languages. Namely, Kratos2 can be used for translating C programs into nuXmv [14], vmt [20], aiger [9], Btor2 [31], Constrained Horn Clauses (chcs) [11], or Boogie [29] formats. Additionally, Kratos2 comes with a Python api for construction and manipulation of K2 programs, which the users can leverage to implement custom front-ends and generators of K2 programs and also additional translators from K2 to other formalisms.
Although Kratos2 has not been described in a publication until now, it has already been successfully used in several research and industrial projects. In particular, Kratos2 has been used as a back-end for the verification of automotive software in the context of the autosar platform [15, 16]; of C code automatically generated from aadl specifications by the taste development environment [12]; and for verification of C code for railway interlocking systems automatically generated from the specifications in a controlled natural language [1]. Kratos2 has also been used as a benchmark generator to produce symbolic transition systems from C programs [30].
The rest of the paper is structured as follows. The functionalities offered by Kratos2 from the user perspective are described in Sect. 2; Sect. 3 introduces K2, describing its syntax and formal semantics. The internal architecture of Kratos2, with details about its main components, is presented in Sect. 4; implementation notes and experimental evaluation on C programs from the annual software verification competition sv-comp are provided in Sect. 5. Finally, Sect. 6 concludes the paper and presents directions for future developments.
2 Functional View
In this section we provide a high-level overview of the functionalities available in Kratos2. More details will then be provided in the following sections.
An Intermediate Language for Imperative Programs. The core of Kratos2 is built around an idealized language for imperative programs called K2. Unlike common high-level real-world programming languages, K2 has a simple and clean semantics based on first-order logic modulo theories that is fully formally specified. The K2 language, similar in spirit to other intermediate verification languages proposed in the literature such as Boogie [29] or Why3 [26] (although less feature rich than the two), is at the same time simple enough to be easily manipulated and translated into formalisms used by sat-based and smt-based verification back-ends on one hand, and expressive enough to efficiently capture a significant subset of C on the other, as demonstrated also by our experimental results on standard sv-comp benchmarks (see Sect. 5).
Verification of Safety and Liveness with Multiple Back-Ends. Kratos2 implements multiple state-of-the-art verification algorithms based on sat and smt, supporting both bit-precise reasoning over machine integers and floating-point numbers as well as higher-level reasoning based on, e.g., mathematical integers, real numbers, and uninterpreted functions, depending on the combinations of theories used in the input K2 program under analysis. Moreover, Kratos2 supports not only the verification of safety properties (via a reduction to reachability of designated “error” program locations), but it also supports liveness properties such as proving that a specific program location is reached a finite number of times in all executions, or that it is always visited infinitely often in all infinite executions.
A Python api for Program Manipulations. Kratos2 provides a rich and flexible Python api for parsing, printing, and manipulating K2 programs and expressions, which can be used to implement converters from high-level languages to K2 or to directly generate K2 programs from user-specific applications.
A Customizable C Front-End. Kratos2 comes with a front-end for C programs which supports a wide range of customization options for controlling the translation from C to K2. These range from the choice of theories to use to encode C data types (e.g., bit-vectors or unbounded integers), to the use of customized program transformations or the injection of new built-in functions with special meaning (such as special assume, malloc, or memset built-ins). Thanks to its plug-in architecture, the front-end can be easily customized for domain-specific subsets of C, for example to implement special optimization passes that are safe only in the given context, or to automatically inject properties to the code based on specification files (as is, e.g., the case in sv-comp [3]).
Encoding into Multiple Formalisms. Kratos2 can be used as an encoder or benchmark generator because it can translate imperative programs written in C or in K2 into other formalisms, including symbolic transition systems in nuXmv [14], vmt [20], aiger [9] or Btor2 [31] formats, Constrained Horn Clauses (chcs) [11], or other intermediate verification languages like Boogie [29].
Simulation and Symbolic Execution. Finally, Kratos2 can be used as an interpreter, allowing an (interactive) simulation of K2 programs and their symbolic execution, as an alternative to the verification back-ends based on model checking.
3 The K2 Language
In this section we introduce K2, the intermediate verification language used by Kratos2. We present its abstract syntax, formally define its semantics, and discuss its support for safety and liveness properties.
Abstract Syntax. We denote lists of elements with an overbar, i.e., \(\overline{\cdot }\). If \(\overline{a}\) is a list, \(|\overline{a}|\) is its length, and if i is a natural number, \(\overline{a}_i\) is the i-th element of \(\overline{a}\). If e is an element, \(\overline{a} \cdot e\) is the list obtained by appending e at the end of \(\overline{a}\).
Definition 1
(Variables and Functions). A variable is a symbol with an associated sort, as in the multi-sorted first-order logic. A function is a tuple \(\langle f,\overline{a},\overline{r},\overline{l},\overline{\sigma }\rangle \), where:
-
f, a symbol, is the name of the function;
-
\(\overline{a}\), a list of variables, are the formal parameters;
-
\(\overline{r}\), a list of variables, are the return variables;
-
\(\overline{l}\), a list of variables, are the local variables;
-
\(\overline{\sigma }\), a list of statements generated by the grammar of Fig. 1, are the body.
Given a list of variables \(\overline{v}\), we define \(\textsf{syms}(\overline{v}) \) as the corresponding set of symbols. Given a function \(\langle f, \overline{a}, \overline{r}, \overline{l}, \overline{\sigma }\rangle \), we denote with \(\textsf{syms}(f) \) the set \(\textsf{syms}(\overline{a}) \cup \textsf{syms}(\overline{r}) \cup \textsf{syms}(\overline{l}) \). We extend the definition to lists of statements \(\overline{\sigma }\) in the natural way. We now describe K2 programs, whose abstract syntax is shown in Fig. 2.
Definition 2
(Programs). A program P is a tuple \(\langle \overline{g},F,\iota ,e\rangle \), where:
-
\(\overline{g}\), a list of variables, are the global variables;
-
F is a partial mapping from symbols to functions;
-
\(\iota \), a formula, is the constraint on initial states;
-
e, a symbol in \(\textrm{dom}(F)\), is the entry point.
Semantics. We use the standard notions of theory, interpretation, model, and satisfaction from many-sorted first-order logic and smt [2]. In the following, we assume that we have fixed a theory T with equality that contains at least the sort Bool. Given an interpretation \(\mu \) that is a model for T, we define the evaluation of an expression e (generated by the grammar of Fig. 1) under \(\mu \), denoted \(\mu [e]\), as \(\mu [e] = \mu (v)\) for \(e = {\textbf {var~}} v\) and \(\mu [e] = \mu (o)(\mu [\overline{p}_1], \ldots , \mu [\overline{p}_n])\) for \(e = {\textbf {op~}} o~\overline{p}\) and \(n = |\overline{p}|\).
We denote with \(\mu [v \mapsto e]\) the interpretation that maps v to e, and that agrees with \(\mu \) everywhere else, and with \(\mu [\setminus v]\) any interpretation that agrees with \(\mu \) on all the symbols except v. Finally, if e is of sort Bool, we write \(\mu \models e\) to denote that e evaluates to true under \(\mu \).
Definition 3
(Program states). Pairs \(\langle f, i\rangle \) where f is a function name and i is a natural number are called program locations. A state of a program P is a pair \(s = \langle G, \overline{C}\rangle \) where:
-
G is an interpretation for the global variables of P;
-
\(\overline{C}\) is the current call stack, a list of triples \(\langle f,i,L\rangle \), where \(\langle f, i\rangle \) is a program location and L is an interpretation of \(\textsf{syms}(f) \), i.e., of parameters, return variables, and local variables of F(f).
A state s is initial if and only if \(G \models \iota \), \(|\overline{C}| = 1\) and \(\overline{C}_1 = \langle e,1,L\rangle \) for some L. Given a state s with \(\overline{C}_{|\overline{C}|} = \langle f,i,L\rangle \), we define the current interpretation \(\mu \) for s as \(\mu (v) = G(v)\) for \(v \in \textsf{syms}(\overline{g}) \) and as \(\mu (v) = L(v)\) otherwise.
We define the semantics for programs as a set of transition rules of the form \(s \xrightarrow {\sigma } s'\), where \(s, s'\) are states and \(\sigma \) is a statement. We then call a path of a program P any sequence of transitions (possibly infinite) \(s_0 \xrightarrow {\sigma _0} \ldots \xrightarrow {\sigma _i} s_{i+1} \ldots \) that complies with the transition rules and where \(s_0\) is an initial state.
The rules are shown in Fig. 3. In the definitions, we fix a program \(P=\langle \overline{g}, F, \iota , e\rangle \) and use the following convenience functions, where f is a function name and i a natural number: \(\textsf{arg}(f,i) \) returns the variable \(\overline{a}_i\) of the function F(f); \(\textsf{ret}(f,i) \) returns the variable \(\overline{r}_i\) of the function F(f); \(\textsf{stmt}(f,i) \) returns the statement \(\overline{\sigma }_i\) of F(f); \(\textsf{stmts}(f) \) returns the list of statements \(\overline{\sigma }\) of F(f).
Reachability and Liveness. We then say that a state s is reachable in P iff there exists a finite path \(s_0 \xrightarrow {\sigma _0} \ldots \xrightarrow {\sigma _n} s\) that ends in s. Similarly, a program location \(\langle f,i\rangle \) is reachable iff there exists a path as above in which \(\sigma _n = \textsf{stmt}(f,i) \)Footnote 1. Conversely, if no such path exists, then \(\langle f,i\rangle \) is unreachable. The location \(\langle f,i\rangle \) is infinitely-often reachable iff there exists an infinite path \(s_0 \xrightarrow {\sigma _0} \ldots \xrightarrow {\sigma _i} s_{i+1} \ldots \) in which for all indices j there exists an index \(k > j\) such that \(\sigma _k = \textsf{stmt}(f,i) \). If no such path exists, then \(\langle f,i\rangle \) is eventually unreachable. Finally, we say that \(\langle f,i\rangle \) is live iff it is infinitely-often reachable in all infinite paths of P.
In K2, queries about reachability or liveness of program locations are expressed via annotations of label statements. Annotations are metadata that are attached to statements, in the form of key-value pairs, which do not affect the semantics of the program, but are meant to provide additional information that can be used by tools that manipulate the K2 program. Specifically, Kratos2 uses the following annotations to define properties:
- error <id>::
-
holds iff all labels annotated with the same <id> are unreachable;
- notlive <id>::
-
holds iff all labels annotated with the same <id> are eventually unreachable;
- live <id>::
-
holds iff all labels annotated with the same <id> are live.
These basic properties can be easily used to represent more common higher-level properties of programs, such as assertions and termination. For example, assertions can be reduced to reachability with a combination of assume and jump statements, whereas termination can be checked by adding a final self loop over a label with an attached live annotation. Finally, eventual unreachability can be used to encode arbitrary ltl properties using the standard automata-theoretic approach combined with a symbolic encoding of the accepting automaton such as [22].Footnote 2
3.1 Example
We conclude this section with a simple example of a C program and its equivalent formulation in K2. Both versions are shown in Fig. 4. Most of the code is translated in a fairly direct way (with conditional statements and structured loops translated into nondeterministic jumps constrained by assumptions). However, since in K2, unlike in C, global variables are uninitialized by default, the K2 program contains an additional setup function (called init_and_main in the example) that sets glbl to zero before calling the original main. Another point to highlight is the use of the :error annotation (highlighted in bold) to model the C assertion.
4 Architectural View
This section describes the main components of Kratos2 and the flow of information among them. From the high-level point of view, Kratos2 is composed of the front-end c2Kratos, which converts the input C program to the K2 language, and of the core Kratos2, which is responsible for parsing, simplifications, transformations, and verification of K2 code. This separation helps to keep the core Kratos2 simple, as it does not have to handle the complex semantic nuances of C. Moreover, it makes it easy to add front-ends for new languages by writing a separate translator from the language in question to K2.
The front-end c2Kratos reads the input C file, builds its abstract syntax tree (ast) and then builds the corresponding K2 code in two passes. In the first pass, it converts the ast to an extended K2. Compared to the standard K2, the extended K2 also has primitives for pointers, records, complex loops, and compound instructions. These are removed in the second pass, by converting pointers to operations over maps, records to multiple variables, complex loops to sequences of assignments, jump instructions, and assumptions, and compound instructions to sequences of basic assignments to auxiliary variables.
The core Kratos2 consists of several components, whose relationships are visualized in Fig. 5:
cfg builder and simplifier reads the input K2 file and builds the corresponding interprocedural control flow graph (cfg). It then performs several simplifications of the cfg, such as constant propagation and lightweight slicing. The result can be used either by the interpreter, symbolic executor, or one of the encoders. The simplified cfg can also be converted back into a K2 representation.
Interpreter interprets the cfg using the externally provided inputs to guide the execution. The inputs contain new values for all havoc commands and also destination labels for all nondeterministic jump commands. The inputs can be provided by the user, a random generator, or by one of the verification engines. The last option is used for counterexample reconstruction and validation.
Transition system encoder encodes the cfg to a symbolic transition system over a suitable theory. The encoder first inlines all function calls in the program. It then encodes the resulting inlined program using large block encoding [4], which allows encoding larger acyclic subgraphs of the cfg by a single transition formula. The resulting transition system can be verified by one of the available verification back-ends, or converted to a textual representation in one of the available output formats (vmt [20], nuXmv [14], Btor2 [31], or aiger [9]).Footnote 3
chc encoder converts the cfg to a set of Constrained Horn Clauses [11]. In contrast to the transition system encoder, the chc encoder supports interprocedural analysis and recursive functions, encoded as a set of non-linear chc s as described, e.g., in [28].
Symbolic executor implements a classical symbolic execution algorithm with iterative deepening to avoid getting stuck in long uninteresting branches. It supports (possibly recursive) K2 programs over arbitrary combinations of integers, reals, bit-vectors, floats, and arrays.
smt-based engines encompass several smt-based verification algorithms of symbolic transition systems. For reachability properties, Kratos2 implements standard bounded model checking (bmc) [7], k-induction [32], and IC3 with implicit predicate abstraction [18]. For liveness properties, we use a procedure combining liveness-to-safety reduction with ranking functions synthesis [23].
sat-based engines encompass several verification algorithms of finite-state symbolic transition systems. Namely, for transition systems over the theory of bit-vectors and floats, Kratos2 offers bmc, k-induction, and different variants of IC3 [13], working over the bit-blasted Boolean transition system, for both reachability and liveness properties. Additionally, Kratos2 implements a dedicated engine for reachability properties in transition systems over the theory of bit-vectors, floats, and arrays similar to [10, 30].
5 Implementation and Experimental Evaluation
Implementation. Core Kratos2 is implemented in C++ on top of the MathSAT5 [19] smt solver and the nuXmv [14] symbolic model checker. The sat-based verification engine additionally makes use of the MiniSat [25] and CaDiCaL [8] sat solvers. The front-end c2Kratos is implemented in Python and relies on pycparser for parsing of the input C program. Kratos2 is freely available for non-commercial purposes from https://kratos.fbk.eu.
Experimental Setup. We performed an experimental evaluation to answer two research questions: Is the K2 language expressive enough to efficiently represent realistic C programs? Do the engines implemented in Kratos2 offer reasonable performance on realistic verification tasks? To this end, we considered all the C programs from the ReachSafety category of the 2022 edition of the annual software verification competition sv-comp [3].The category consists of 5400 C programs divided into 12 benchmark families. We compared Kratos2 with VeriAbs 1.4.2 [24] and CPAchecker 2.2 [5], respectively the winner and runner-up of the ReachSafety category of sv-comp 2022. Similarly to the approach used by CPAchecker, we executed Kratos2 in sequential portfolio mode, which successively runs symbolic execution, smt-based IC3, sat-based IC3, and smt-based bmc with predetermined time-outs for each of the engines.
The experiments were performed on several identical pcs equipped with Intel Core i7-8700 cpu @ 3.20 GHz and 32 GiB of ram. Each execution was limited to use a single cpu core, 15 min of cpu time, and 8 GiB of ram. For reliable benchmarking, all experiments were executed using BenchExec [6]. A replication package describing the details of the setup is available at https://doi.org/10.5281/zenodo.7890411.
Results. To answer the first research question, we observe that from the total 5400 benchmarks, only 56 were not converted to K2 by c2Kratos due to unsupported floating point built-ins or features such as variable length arrays.
To answer the second research question, Table 1 shows the numbers of solved benchmarks by the individual tools and quantile plots in Fig. 6 show their running times. The results show that Kratos2 is competitive with CPAchecker on all benchmark families except for eca. It is also competitive with VeriAbs on most benchmark families. There are 23 benchmarks uniquely solved by Kratos2, 48 by CPAchecker, and 1039 by VeriAbs. Moreover, both Kratos2 and VeriAbs produced no wrong results, unlike most other participants of sv-comp.
We remark that CPAchecker is an established and optimized software verifier that regularly scores high in software verification competitions, and that VeriAbs implements algorithm selection heuristics, using both its own custom engines and external state-of-the-art verifiers. As such, it is not surprising that it performs much better than Kratos2 and CPAchecker on some of the families.
We conclude that the K2 language is expressive enough to efficiently capture a significant subset of C used in realistic programs. Furthermore, the verification engines implemented in Kratos2 mostly offer a performance comparable with state-of-the-art software verifiers.
6 Conclusions and Future Work
We have described Kratos2, a mature software verifier for imperative programs written in K2, a new intermediate verification language with a formal semantics based on smt. Kratos2 is a complete rewrite of the original Kratos tool, offering significant extensions in functionalities and performance. The tool has already been successfully applied in various contexts, both industrial and academic.
As future work, we will consolidate the (currently alpha-quality) implementation of the esst algorithm of the original Kratos [21] to handle multithreaded programs with cooperative scheduling. We will also investigate a tighter integration with chc solvers to better handle recursive programs, as well as improved techniques to handle arrays and pointers such as [27, 33]. On the language side, we plan to add support for contracts and pre-/post-conditions via annotations.
Notes
- 1.
Note that here we assume w.l.o.g. that all statements in a program are different, even when they are structurally equal, so the above definition is unambiguous.
- 2.
In the case of ltl properties, the question arises as to what to consider as an atomic step of the program. This is both crucial and application-dependent: for example, in embedded software consisting of a “transition function” that is executed periodically, it might make sense to consider each call to such function as one step, whereas in other contexts a more fine-grained notion of step might be needed. K2 (and Kratos2) makes no commitment about this, providing only the support for eventual unreachability of label statements, which can always be defined unambiguously.
- 3.
Depending on the features of the input K2 program, some of the verification back-ends or output formats might not be available. E.g., sat-based engines are not available if the K2 program contains some infinite-state variables.
References
Amendola, A., et al.: A model-based approach to the design, verification and deployment of railway interlocking system. In: Margaria, T., Steffen, B. (eds.) ISoLA 2020. LNCS, vol. 12478, pp. 240–254. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-61467-6_16
Barrett, C.W., Sebastiani, R., Seshia, S.A., Tinelli, C.: Satisfiability modulo theories. In: Handbook of Satisfiability. Frontiers in Artificial Intelligence and Applications, vol. 336, pp. 1267–1329. IOS Press (2021)
Beyer, D.: Progress on software verification: SV-COMP 2022. In: Beyer, D. (ed.) TACAS 2022. LNCS, vol. 13244, pp. 375–402. Springer, Cham (2022). https://doi.org/10.1007/978-3-030-99527-0_20
Beyer, D., Cimatti, A., Griggio, A., Keremoglu, M.E., Sebastiani, R.: Software model checking via large-block encoding. In: FMCAD, pp. 25–32. IEEE (2009)
Beyer, D., Keremoglu, M.E.: CPAchecker: A tool for configurable software verification. In: Gopalakrishnan, G., Qadeer, S. (eds.) CAV 2011. LNCS, vol. 6806, pp. 184–190. Springer, Heidelberg (2011). https://doi.org/10.1007/978-3-642-22110-1_16
Beyer, D., Löwe, S., Wendler, P.: Reliable benchmarking: requirements and solutions. Int. J. Softw. Tools Technol. Transf. 21(1), 1–29 (2019)
Biere, A., Cimatti, A., Clarke, E., Zhu, Y.: Symbolic model checking without BDDs. In: Cleaveland, W.R. (ed.) TACAS 1999. LNCS, vol. 1579, pp. 193–207. Springer, Heidelberg (1999). https://doi.org/10.1007/3-540-49059-0_14
Biere, A., Fleury, M., Heisinger, M.: CaDiCaL, Kissat, Paracooba entering the SAT Competition 2021. In: Proceedings of SAT Competition 2021 - Solver and Benchmark Descriptions, volume B-2021-1 of Department of Computer Science Report Series B, pp. 10–13. University of Helsinki (2021)
Biere, A., Heljanko, K., Wieringa, S.: AIGER 1.9 and beyond. Technical report 11/2, Institute for Formal Models and Verification, Johannes Kepler University (2011)
Bjesse, P.: Word-level sequential memory abstraction for model checking. In: Cimatti, A., Jones, R.B. (eds.) Formal Methods in Computer-Aided Design, FMCAD 2008, Portland, Oregon, USA, 17–20 November 2008, pp. 1–9. IEEE (2008)
Bjørner, N., Gurfinkel, A., McMillan, K., Rybalchenko, A.: Horn clause solvers for program verification. In: Beklemishev, L.D., Blass, A., Dershowitz, N., Finkbeiner, B., Schulte, W. (eds.) Fields of Logic and Computation II. LNCS, vol. 9300, pp. 24–51. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-23534-9_2
Bombardelli, A., et al.: COMPASTA: extending TASTE with formal design and verification functionality. In: Seguin, C., Zeller, M., Prosvirnova, T. (eds.) IMBSA 2022. LNCS, vol. 13525, pp. 21–27. Springer, Cham (2022). https://doi.org/10.1007/978-3-031-15842-1_2
Bradley, A.R.: SAT-based model checking without unrolling. In: Jhala, R., Schmidt, D. (eds.) VMCAI 2011. LNCS, vol. 6538, pp. 70–87. Springer, Heidelberg (2011). https://doi.org/10.1007/978-3-642-18275-4_7
Cavada, R., et al.: The nuXmv symbolic model checker. In: Biere, A., Bloem, R. (eds.) CAV 2014. LNCS, vol. 8559, pp. 334–342. Springer, Cham (2014). https://doi.org/10.1007/978-3-319-08867-9_22
Cimatti, A., et al.: A comprehensive framework for the analysis of automotive systems. In: MoDELS, pp. 379–389. ACM (2022)
Cimatti, A., et al.: EVA: a tool for the compositional verification of AUTOSAR models. In: Sankaranarayanan, S., Sharygina, N. (eds.) TACAS 2023. LNCS, vol. 13994, pp. 3–10. Springer, Cham (2023). https://doi.org/10.1007/978-3-031-30820-8_1
Cimatti, A., Griggio, A., Micheli, A., Narasamdya, I., Roveri, M.: Kratos – a software model checker for SystemC. In: Gopalakrishnan, G., Qadeer, S. (eds.) CAV 2011. LNCS, vol. 6806, pp. 310–316. Springer, Heidelberg (2011). https://doi.org/10.1007/978-3-642-22110-1_24
Cimatti, A., Griggio, A., Mover, S., Tonetta, S.: Infinite-state invariant checking with IC3 and predicate abstraction. Formal Methods Syst. Des. 49(3), 190–218 (2016). https://doi.org/10.1007/s10703-016-0257-4
Cimatti, A., Griggio, A., Schaafsma, B.J., Sebastiani, R.: The MathSAT5 SMT solver. In: Piterman, N., Smolka, S.A. (eds.) TACAS 2013. LNCS, vol. 7795, pp. 93–107. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-36742-7_7
Cimatti, A., Griggio, A., Tonetta, S.: The VMT-LIB language and tools. In: SMT. CEUR Workshop Proceedings, vol. 3185, pp. 80–89. CEUR-WS.org (2022)
Cimatti, A., Narasamdya, I., Roveri, M.: Software model checking with explicit scheduler and symbolic threads. Log. Methods Comput. Sci. 8(2) (2012)
Clarke, E.M., Grumberg, O., Hamaguchi, K.: Another look at LTL model checking. Formal Methods Syst. Des. 10(1), 47–71 (1997)
Daniel, J., Cimatti, A., Griggio, A., Tonetta, S., Mover, S.: Infinite-state liveness-to-safety via implicit abstraction and well-founded relations. In: Chaudhuri, S., Farzan, A. (eds.) CAV 2016. LNCS, vol. 9779, pp. 271–291. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-41528-4_15
Darke, P., Agrawal, S., Venkatesh, R.: VeriAbs: a tool for scalable verification by abstraction (competition contribution). In: TACAS 2021. LNCS, vol. 12652, pp. 458–462. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-72013-1_32
Eén, N., Sörensson, N.: An extensible SAT-solver. In: Giunchiglia, E., Tacchella, A. (eds.) SAT 2003. LNCS, vol. 2919, pp. 502–518. Springer, Heidelberg (2004). https://doi.org/10.1007/978-3-540-24605-3_37
Filliâtre, J.-C., Paskevich, A.: Why3—where programs meet provers. In: Felleisen, M., Gardner, P. (eds.) ESOP 2013. LNCS, vol. 7792, pp. 125–128. Springer, Heidelberg (2013). https://doi.org/10.1007/978-3-642-37036-6_8
Garcia-Contreras, I., Gurfinkel, A., Navas, J.A.: Efficient modular SMT-based model checking of pointer programs. In: SAS 2022. LNCS, vol. 13790, pp. 227–246. Springer, Cham (2022). https://doi.org/10.1007/978-3-031-22308-2_11
Grebenshchikov, S., Lopes, N.P., Popeea, C., Rybalchenko, A.: Synthesizing software verifiers from proof rules. In: PLDI, pp. 405–416. ACM (2012)
Leino, K.R.M., Rümmer, P.: A polymorphic intermediate verification language: design and logical encoding. In: Esparza, J., Majumdar, R. (eds.) TACAS 2010. LNCS, vol. 6015, pp. 312–327. Springer, Heidelberg (2010). https://doi.org/10.1007/978-3-642-12002-2_26
Mann, M., Irfan, A., Griggio, A., Padon, O., Barrett, C.W.: Counterexample-guided prophecy for model checking modulo the theory of arrays. Log. Methods Comput. Sci. 18(3) (2022)
Niemetz, A., Preiner, M., Wolf, C., Biere, A.: Btor2, BtorMC and Boolector 3.0. In: Chockler, H., Weissenbacher, G. (eds.) CAV 2018. LNCS, vol. 10981, pp. 587–595. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-96145-3_32
Sheeran, M., Singh, S., Stålmarck, G.: Checking safety properties using induction and a SAT-solver. In: Hunt, W.A., Johnson, S.D. (eds.) FMCAD 2000. LNCS, vol. 1954, pp. 127–144. Springer, Heidelberg (2000). https://doi.org/10.1007/3-540-40922-X_8
Vick, C., McMillan, K.L.: Synthesizing history and prophecy variables for symbolic model checking. In: Dragoi, C., Emmi, M., Wang, J. (eds.) VMCAI 2023. LNCS, vol. 13881, pp. 320–340. Springer, Cham (2023). https://doi.org/10.1007/978-3-031-24950-1_15
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Copyright information
© 2023 The Author(s)
About this paper
Cite this paper
Griggio, A., Jonáš, M. (2023). Kratos2: An SMT-Based Model Checker for Imperative Programs. In: Enea, C., Lal, A. (eds) Computer Aided Verification. CAV 2023. Lecture Notes in Computer Science, vol 13966. Springer, Cham. https://doi.org/10.1007/978-3-031-37709-9_20
Download citation
DOI: https://doi.org/10.1007/978-3-031-37709-9_20
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-031-37708-2
Online ISBN: 978-3-031-37709-9
eBook Packages: Computer ScienceComputer Science (R0)