The VerCors tool implements thread-modular static verification of concurrent programs, annotated with functional properties and heap access permissions. The tool supports both generic multithreaded and vector-based programming models. In particular, it can verify multithreaded programs written in Java, specified with JML extended with separation logic. It can also verify parallelizable programs written in a toy language that supports the characteristic features of OpenCL. The tool verifies programs by first encoding the specified program into a much simpler programming language and then applying the Chalice verifier to the simplified program. In this paper we discuss both the implementation of the tool and the features of its specification language

E. Cohen

K. Leino

L. Burdy

M. Barnett

M. Parkinson

Blom, Stefan

Huisman, Marieke

University of Twente Research Information

The VerCors Tool forVerification of Concurrent ProgramsStefan Blom and Marieke HuismanFormal Methods and Tools, University of Twente, The Netherlands{s.blom,m.huisman}@utwente.nlAbstract. The VerCors tool implements thread-modular static verifi-cation of concurrent programs, annotated with functional properties andheap access permissions. The tool supports both generic multithreadedand vector-based programming models. In particular, it can verify mul-tithreaded programs written in Java, specified with JML extended withseparation logic. It can also verify parallelizable programs written in atoy language that supports the characteristic features of OpenCL. Thetool verifies programs by first encoding the specified program into a muchsimpler programming language and then applying the Chalice verifier tothe simplified program. In this paper we discuss both the implementationof the tool and the features of its specification language.1 IntroductionIncreasing performance demands, application complexity and explicit multi-coreparallelism make concurrency omnipresent in software applications. However,due to the complex interferences between threads in an application, concurrentsoftware is also notoriously hard to get correct. Therefore, formal techniques areneeded to reason about the behavior of concurrent programs. Over the last years,program logics have proven themselves to be useful to reason about sequentialprograms. In particular, several powerful tools for JML have been developed [5].These techniques now are mature enough to lift them to concurrent programs.The VerCors tool supports the thread-modular verification of multithreadedprograms. Modularity is achieved by specifying for each thread which variableson the heap it can access, by means of access permissions, which can be dividedand combined, but not duplicated [8]. To read a location, any share of the accesspermission to that location suffices. To write a location a thread needs 100% ofthe access rights. Hence, if a thread has write permission to a location, no otherthread can read that location simultaneously. Moreover, if a thread has readpermission to a location, other threads can also only read this location. Thusspecifications that are sufficiently protected by permissions are interference-free.Moreover, verified programs cannot contain data races.Just as multi-core processors are ubiquitous, the same applies to GPU hard-ware. Therefore, the VerCors tool also provides the functionality to reason aboutkernels running on a GPU, where a large number of threads execute the sameinstructions, each on part of the data.2 Design of the VerCors ToolRather than building yet another verifier, the VerCors tool leverages existingverifiers. That is, it is designed as a compiler that translates specified programsto a simpler language. These simplified programs are then verified by a third-party verifier. If there are errors then the error messages are converted to referto the original input code.Chalice Boogie Z3Java PVLOpenCLCToolVerCorsback endsinput languagesCommon Object LanguageFig. 1. VerCors tool architecture.Figure 1 shows the overall architec-ture of the tool. Its main input lan-guage is Java. For prototyping, we usethe toy language PVL, which is a verysimple object-oriented language that canexpress specified GPU kernels too. TheC language family front-end is work-in-progress, but will support OpenCL inthe near future. We mainly use Chalice[10], a verifier for an idealized concur-rent programming language, as our back-end, but for sequential programs wealso use the intermediate program verification language Boogie [1].The implementation of the tool is highly modular. Everything is built aroundthe Common Object Language data structure for Abstract Syntax Trees. ForJava and C, parsing happens in two passes. In the first pass an existing ANTLR4[13] grammar is used to convert the program into an AST while keeping all com-ments. In the second pass those comments that contain specifications are parsedusing a separate grammar. This prevents us from having to maintain heavilymodified grammars and makes it much easier to support multiple specificationlanguages. The process of encoding programs consists of many simple passes. Ob-viously, this impacts performance, but it is good for reusability and checkabilityof the passes. Our back-end framework allows switching between different ver-sions, by setting up their command line execution using environment modules,a system for dynamic access to multiple versions of software modules [11].3 The VerCors Specification LanguageThe VerCors specification language has JML as a starting point, and adds fea-tures from Chalice, and from Hurlin’s permission-based separation logic for con-current Java [8], in order to be equally expressive as Hurlin’s logic.Using JML as a starting point allows to reuse existing JML specifications.However, JML’s support for framing (i.e., modifies clauses) is not precise enoughto be used in a concurrent setting. Instead we use access permissions Perm(e, π),where e is an expression denoting a location on the heap (a field in Java) and πis a percentage. To specify properties of the value stored at the location we justrefer to the location in our formulas. Thus, we are forced to check that everyexpression is self-framed, i.e., we need to check that only locations for which wehave access permission are accessed. This is different from classical separationlogic, which uses the PointsTo primitive, which has an additional argument thatdenotes the value of the location and cannot refer to the location otherwise. Weprefer the Perm primitive because it fits JML and Chalice best. The VerCorstool supports PointsTo as syntactic sugar, which can be extended to full support.Moreover, it is proven that the two logics are equivalent [12]. Another feature ofour logic is the notion of thread-local predicates, which are used to axiomatizethe lockset predicate that keeps track of the locks held by the current thread [8].Like Chalice, the VerCors tool disallows disjunction between resources. Itdoes so by distinguishing the type resource from the type boolean. Thus, booleanformulas allow all logical operators and quantifications, while resource formulasare limited to the separating conjunction, separating implication (magic wand),and universal quantification. In method contracts, pre- and postconditions areof type resource.VerCors’ specification language uses several features that are not nativelypresent in Chalice and thus have to be encoded. Resource predicates can havean arbitrary number of arguments, whereas Chalice only allows the implicit thisargument. This is encoded by (partially) translating the formulas to witness ob-jects. That is, instead of passing arguments to a predicate, we put the argumentsin an object and define a predicate (without arguments) on that object. Thistranslation also turns proof construction annotations into method calls. Magicwands are encoded using a similar strategy of defining witness objects [3]. Byencoding complex specifications as data structures with simple specifications,we gain the ability to verify complex specifications with existing tools. However,these existing tools have no specific support for our data structures. Therefore,we also have to provide proof scripts to guide the proof search in the encodedprogram.Below, we show a small example of a program in PVL that computes thefibonacci numbers by forking new threads instead of making recursive calls.class Fib { static int fib ( int n)=n<2?1:fib(n−1)+fib(n−2);2 int input , output;requires perm(input,50) ∗ perm(output,100);4 ensures perm(input,50) ∗ perm(output,100) ∗ output=fib(input);void run() { if (input<2) { output := 1; }6 else { Fib f1 := new Fib; f1 . input := input−1;Fib f2 := new Fib; f2 . input := input−2;8 fork f1 ; fork f2 ;assert f1 . input=input−1 ∗ f2.input=input−2;10 join f1 ; join f2 ;output := f1 .output + f2.output; }}}Note that we use Chalice notation for fractions: 50 means read-only and 100means write access. Also note how on line 9, we use an assert to remind theprover that because we can read the inputs to the threads, these inputs cannotchange. The Java version of this example is much longer and can be found onthe tool’s website [14].In addition to verification of Multiple Instruction Multiple Data programs,the VerCors tool also supports verification of Single Instruction Multiple Dataprograms. Specifically, it supports reasoning about GPU kernels written in PVL.The concept of a kernel is that a large number of threads, divided over one ormore working groups, all execute the same code, but each on part of the data.These computations cannot synchronize, except for barrier synchronization ofthe threads within a working group. Due to the lack of other synchronizationprimitives, the resources available for redistribution at a barrier are preciselythose available to a working group at the start of the computation. This isreflected by the fact that the required resources upon entering a barrier arededuced by our tool instead of being specified by the user. Moreover, it meansthat in future versions we can simplify the permission model to three values:no access, read access, full access. Our kernel logic imposes proof obligations toensure that all resources are always properly distributed [4]. The tool verifiesthese proof obligations by encoding them as specified methods and classes.Below, we show a small example of a kernel. It displays a typical case: firsteach of the gsize threads computes a value based on an unknown function f andits identifier tid. Then the threads synchronize using a barrier and add their ownresult to that of the preceding thread to get their final result:global int [gsize ] x, y;2 requires perm(x[tid],100) ∗ perm(y[tid ],100);ensures perm(x[tid],100) ∗ (0<tid & tid<gsize −> x[tid]=f(tid)+f(tid−1));4 void main(){y[ tid ] := f(tid );6 barrier (global){requires y[ tid]=f(tid );8 ensures perm(x[tid],100) ∗ perm(y[tid ],50) ∗ perm(y[(tid−1) mod gsize],50);ensures y[ tid]=f(tid) ∗ (tid>0 −> y[tid−1]=f(tid−1)); }10 if (tid>0) { x[tid ] := y[ tid]+y[tid−1]; } }4 ConclusionThis paper gives a brief overview of the VerCors tool set and its specificationlanguage. The main application areas of the tool are MIMD programs written inJava, using Java’s concurrency library, and SIMD applications, such as OpenCLkernels. The tool website [14] contains additional information such as our col-lection of verified examples, which can be tested with the online version of thetool. These examples demonstrate reasoning about the fork/join pattern, reen-trant locks, and about magic wands in specifications. Additionally, there are alsoseveral verified kernel examples.There are several other static verifiers that support reasoning about MIMDprograms, such as VCC [6] for C, VeriFast [9] for C and Java, jStar [7] for Java,and Chalice [10] for an idealized concurrent language. The VCC tool has its ownpermission system and does not use separation logic. The VeriFast and jStartools both use classical separation logic, with jStar being more limited (e.g. nosupport for fractional permissions). The Chalice tool, like VerCors uses implicitdynamic frames, which can be seen as a variant of separation logic [12]. Thedistinguishing feature of the VerCors tool compared to the ones above is that itsupports specifications using the magic wand operator. Moreover, VerCors hassupport for other concurrency models, such as the SIMD model used for GPUkernels. Memory safety for kernels can also be checked with GPUVerify [2], butadditionally, VerCors can check functional correctness of kernels.At the moment, the tool requires a considerable amount of annotations toverify a program. To reduce this, we will work on automatic generation of spec-ifications and also on identifying and implementing useful default specificationsand syntactic sugar. To turn the tool into a full-fledged verification tool, we haveto add support for reasoning about e.g., exceptions. Moreover, we will continuethe work on the C parser, so the tool can verify OpenCL.Acknowledgement This work is supported by the ERC 258405 VerCors projectand by the EU FP7 STREP 287767 project CARP.References1. M. Barnett, B.-Y. E. Chang, R. DeLine, B. Jacobs, and K. R. M. Leino. Boogie:A modular reusable verifier for object-oriented programs. In Formal Methods forComponents and Objects, volume 4111 of LNCS, pages 364 – 387. Springer, 2005.2. A. Betts, N. Chong, A. Donaldson, S. Qadeer, and P. Thomson. GPUVerify: averifier for GPU kernels. In OOPSLA’12, pages 113–132. ACM, 2012.3. S. C. C. Blom and M. Huisman. Witnessing the elimination of magic wands. Tech-nical Report TR-CTIT-13-22, Centre for Telematics and Information Technology,University of Twente, Enschede, November 2013.4. S. C. C. Blom, M. Huisman, and M. Mihelcic. Specification and verification ofgpgpu programs. Technical Report TR-CTIT-13-21, Centre for Telematics andInformation Technology, University of Twente, Enschede, November 2013.5. L. Burdy, Y. Cheon, D. Cok, M. Ernst, J. Kiniry, G. Leavens, K. Leino, and E. Poll.An overview of JML tools and applications. STTT, 7(3):212–232, 2005.6. E. Cohen, M. Dahlweid, M. A. Hillebrand, D. Leinenbach, M. Moskal, T. Santen,W. Schulte, and S. Tobies. VCC: A practical system for verifying concurrent C.In S. Berghofer, T. Nipkow, C. Urban, and M. Wenzel, editors, TPHOLs, volume5674 of LNCS, pages 23–42. Springer, 2009.7. D. DiStefano and M. Parkinson. jStar: Towards practical verification for Java.In ACM Conference on Object-Oriented Programming Systems, Languages, andApplications, pages 213–226. ACM Press, 2008.8. C. Hurlin. Specification and Verification of Multithreaded Object-Oriented Pro-grams with Separation Logic. PhD thesis, Université Nice Sophia Antipolis, 2009.9. B. Jacobs and F. Piessens. The VeriFast program verifier. Technical ReportCW520, Katholieke Universiteit Leuven, 2008.10. K. Leino, P. Müller, and J. Smans. Verification of concurrent programs with Chal-ice. In Lecture notes of FOSAD, volume 5705 of LNCS, pages 195–222. Springer,2009.11. The environment modules project. http://modules.sourceforge.net.12. M. Parkinson and A. Summers. The relationship between separation logic andimplicit dynamic frames. Logical Methods in Computer Science, 8(3:01):1–54, 2012.13. T. Parr. The Definitive ANTLR 4 Reference. Pragmatic Bookshelf, 2013.14. The vercors tool online. http://www.utwente.nl/vercors/.

English

The VerCors Tool for Verification of Concurrent Programs

Stefan Blom

Marieke Huisman

Crossref

https://research.utwente.nl/en/publications/789e5710-6850-4757-998a-0a028fb6b9f1

The VerCors tool for verification of concurrent programs

The VerCors tool for verification of concurrent programs

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information

Crossref