Predicate abstractions memory modeling Method with Separation into disjoint regions Текст научной статьи по специальности «Компьютерные и информационные науки»

Predicate Abstractions Memory Modeling Method with Separation into Disjoint Regions

1 A. Volkov <[email protected]> 2M. Mandrykin <[email protected]> 1 Lomonosov Moscow State University, GSP-1, Leninskie Gory, Moscow, 119991, Russia 2 Institute for System Programming of the Russian Academy of Sciences, 25, Alexander Solzhenitsyn st., Moscow, 109004, Russia.

Abstract. Software verification is a type of activity focused on software quality control and detection of errors in software. Static verification is verification without the execution of software source code. Special software - tools for static verification - often work with program's source code. One of the tools that can be used for static verification is a tool called CPAchecker. The problem of the current memory model used by the tool is that if a function returning a pointer to program's memory lacks a body, arbitrary assumptions can be made about this function return value in the process of verification. Although possible, the assumptions are often also practically very improbable. Their usage may lead to a false alarm. In this paper we give an overview of the approach capable of resolving this issue and its formal specification in terms of path formulas based on the uninterpreted functions used by the tool for memory modeling. We also present results of benchmarking the corresponding implementation against existing memory model.

Keywords: memory model; predicate abstractions; static verification

DOI: 10.15514/ISPRAS-2017-29(4)-13

For citation: Volkov A., Mandrykin M. Predicate Abstractions Memory Modeling Method with Separation into Disjoint Regions. Trudy ISP RAN/Proc. ISP RAS, vol. 29, issue 4, 2017, pp. 203-216. DOI: 10.15514/ISPRAS-2017-29(4)-13

1. Introduction

Software verification is a type of activity focused on software quality control and detection of errors in software [1]. Static verification is a verification without the execution of software source code.

Special software - tools for static verification - often work with program's source code. Depending on the tools used for static verification it is possible to conduct analysis of the source code to search for errors in program's behavior. One of the tools that can be used for static verification is a tool called CPAchecker. It takes program's source code as an input, creates a CFA (control-flow automaton) and uses it to run the analysis. One of the analyses the instrument is capable of is a reachability analysis. In this paper we consider reachability properties that can be expressed as checking if the call to an error function is reachable. Its strong side is that the CPA (configurable program analysis) [2] concept allows to use a composition of several analyses for program verification. The tandem of Value Analysis and Predicate Analysis produces good results in terms of verification precision / verification time ratio.

2. Definitions and notations

We will call a model of program's memory or just a memory model a strategy of organization and representation of program's memory. By region we will refer to the set of lvalues with the following restriction: if two lvalues are taken from two different regions they necessarily reference disjoint memory locations [3]. For example, different regions may be safely assigned to the lvalues referring distinct structure fields under the following conditions:

• the fields do not occur as an argument to the address taking operator (&);

• the fields do not become targets of some pointers by the usage of pointer type conversion or address arithmetic.

The situation when a program's error state is reachable due to the imprecisions of abstraction employed in the analysis is called a false alarm.

3. CPAchecker's memory model

Existing memory model employed by Predicate Analysis of the CPAchecker tool uses uninterpreted functions. Each of those functions has only a name and a number of arguments. If f (x) is an uninterpreted function, a and b are any of its arguments for which a = b is true then f (a) = f (b)[4]. Uninterpreted functions in the CPAchecker tool are used to establish a correspondence between a memory location and the value stored at this memory location. Depending on the type of the expression different uninterpreted functions should be used. Existing memory model of the CPAchecker tool uses typed regions. This means that all lvalues of the same type exist in the same region. However, a large number of lvalues of the same type is present in any big enough program written in the C programming language. This leads to the addition of a big number of logical constraints for each event of a pointer's memory update. The constraints express checks for potential equality of the updated lvalue to each memory location in the region. Those checks allow to determine precisely what memory should also be updated but noticeably increase the length of path formulas.

The problem of the current memory model used by the tool is that if a function returning a pointer to program's memory lacks a body, arbitrary assumptions can be made about its return value in the process of verification. In other words, it is considered possible for this pointer to point at any lvalue in the region. Although possible, this situation is also practically very improbable. In those cases it is hard to determine if a path leading to an error label really does or doesn't exist. One of the approaches capable of resolving this issue suggests the introduction of smaller regions that divide a bigger typed region.

4. B&B memory model

4.1 Memory model overview

B&B memory model was proposed by Richard Bornat and had been based on the work of Rod Burstall [5], [6]. It is used in Frama-C verification tool in Jessie plugin which is capable of performing verification of the C programs. In its foundation are assumptions that can introduce regions of smaller sizes instead of having very big one for a type. These assumptions state that if struct data type fields never occur as arguments to the address taking operator (&) in program's source code then those fields can be placed to separate regions. Otherwise they must belong to the same region as the normal pointers of the same type.

This memory model has some flaws. It does not take into account that the struct fields can be accessed through address arithmetic and pointer conversions. It also needs mentioning that some overhead costs are required for region support. Taking into account the pros and cons of the model it is possible to say that the B&B memory model looks promising.

4.2 Formal specification

For ease of specification we will assume the following:

• variables can only be of struct s * types;

• struct s fields can only be of int type;

• struct s has n fields: struct s { int f1, f2, ..., fn; };

Program's memory location can be represented by an lvalue expression like pointer dereference. To model changes to the program's state when assignments to lvalues arise the CPAchecker tool uses uninterpreted functions [4].

We assume absence of pointer arithmetic and restrict pointer dereferences to the applications of the arrow operator (p ^ fa), where p is a pointer to the struct type and fa is one of the struct fields).

Let Y be a set of uninterpreted functions. It consists of the uninterpreted function G that is used for accessing a memory location in global region, a finite number of uninterpreted functions F¿, where each function F¿ represents the state of the memory region corresponding to lvalues of the form b ^ f¿,i = 1,n and the

uninterpreted function undef_ptr with zero arity that models the usage of the program's functions returning an unknown pointer.

Let B(e) be an uninterpreted function used for global memory location modeling and Bj(e), i = 1,n — a finite set of uninterpreted functions used for memory location modeling in regions corresponding to Ft uninterpreted functions. For address representation it is suggested to use expressions like a, where a is a variable. The axioms of the memory model (positivity of addresses and their non-intersection within one region) can be represented as follows:

• a > 0 ;

• B (a) = k , where k is a unique number for each such variable.

The tool uses SSA representation to model the varying state of program variables and memory regions. In this representation usage of a name splits into usages of its versions. Each time an assignment happens to a program variable or a memory region represented by the corresponding variable or uninterpreted function in the path formula, the version number (index) of that variable or an uninterpreted function increases.

Let Index : Y ^ M be a mapping of a set of uninterpreted functions Y to a numerical set of their indices.

Let Alloc: Y ^ Addrs be a mapping of a set of uninterpreted functions Y to the set of subsets of memory locations Addr: Addrs = 2Addr. We will use a supplementary function mem_upd:

mem_upd(p,f,m',m) = A ((p = a) V (fm'(a) = fm(a)))

aEAlloc(f)

that defines a check for address equality for all of the lvalues in the same region as pointer p (locations in the Alloc(f) region are modeled by the uninterpreted function f, m = Index(f) is a current version off and m ' = m + 1 is a new version). We define w(s,f) as a constant offset of a field f from the base address of struct type variable s. Because we assume that there is only one structure type struct s in our programs, M(s,f) can be made just w(f0.

In B&B memory model implemented on top of CPAchecker's existing memory model the operator of a strongest post-condition is defined as SP(op(<)) = < A r(op), where < is a symbolic abstract state and constraints r(op) are defined by table 1.

4.3 Example

The following program will be considered correct if we use either of the memory models. r constraints in terms of B&B memory model for the program are shown in table 2. Path formula can be made as a conjunction of all formulas in r column of the table 2. It is unsat in terms of either of the memory models. This means that the tool cannot go by this path (i.e. won't consider it as a potential error trace candidate).

struct s { int f1, f2; };

struct s * p1;

struct s * p2;

p1 = alloc();

p2 = alloc();

p1 -> f1 = 6;

p2 -> f2 = 5;

assume(p1 -> f1 == p2 -> f2);

Table 1. Г constraints creation rules

Operation (op) Index Alloc Base address index k' Г constraints

Variable allocation on stack struct s * p; No changes A' - new variable, Alloc'(G) = A' U Alloc(G) k' -new index p = A' A A' > 0 A B(A') = k'

Heap variable allocation p = alloc() I' - new index for G, l = Index(G), Index ' = Index \ A', A' - new variables, Alloc'(G) = A U Alloc(G) Alloc'(F ') = A'U Alloc(Fl),i = Tn k',k' - new indices, i = 1,n Gt'(p) = A A A >0 AB(A') = к' A mem upd(p,G,l, l') Л i=TJi((Gl,(p)+co(fi)) =A'i A A'> 0A Bl(A')=k')

p=undef_ptr() I' - new index for G, l = Index(G), m' - new index for undefptr, m = Index(undef_ptr), Index ' = Index \ ({G ^ l}J {undef_ptr ^m})J No changes No changes Gi'(p) = undef_ptrm A mem upd(p,G,l, l')

{G ^ 1'} u {undef_ptr ^ m'}

P^ fi = e m' - new index for Fi, m= Index(F i ), Inde x' = Index \ {Fi ^m}u {F i ^ m'} No changes No changes F^'(Gl(p) + ^(fi)) = T(e) A mem_upd( Gl(p) + te(fi),Fl,m',m), where l = Index(G) and T(e) can be computed using the following rules: r(const) : const; r(p2 ^ f) : Ft(Gi(p2) + w(f )), where k=Index(Fj), l = Index(G); r(ei op e2), op £ {'+', '-', r(ei) op r( e2).

assume(p) No changes No changes No changes r(p) for predicate p can be computed as following: r(const) : const; r(s) : Gl (s), where l = Index(G); r(s ^ fi): Fm(Gi(s) + co(fi)), where m = Index(F 1), l = Index(G); r(p1 == p2) : r(p1) == r(p2); r(p1 < p2) : r(p1) < r(p2); r(p1 <= p2) : r(p1) < r(p2); r(p1 || p2) : r(p1) V r(p2); r(p1 && p2) : r(p1) A r(p2); f(!p) : -r(p).

Table 2. Example build of path formula for the correct program

Path instruction Index Alloc k' Г

struct s * p1; (G^1, F1 ^1, F2 ^1} Alloc(G)=(A1} 1 p1 = A1A A1> 0 Л B(A1) = 1

struct s * p2; (G^1, F1 ^1, F2 ^1} Alloc(G)=(A1, A2} 2 p2 = A2Л A2> 0 Л B(A2) = 2

pi = alloc(); (G^2, F1 ^1, F2 ^1} Alloc(G)=(A1, A2, A3} Alloc(F1) = (A4} Alloc(F2) = {A5} 3,4,5 G2(p1) = A3 Л A3> 0 Л B(A3) = 3 Л ( G2(p1)+ш(Гд) = A4 Л A4 > 0 Л B(A4) = 4 Л ( G2(p1)+Ufa)) = As Л As > 0 Л B(A5) = 5

p2 = alloc(); (G^3, F1 ^1, F2 ^1} Alloc(G)=(A1, A2, A3,A6} Alloc(F1) = (A4, A7} Alloc(F2) = (As,A8} 6,7,8 G3 (p2) = A6 Л A6> 0 Л B(A6) = 6 Л ( G3 (p2)+<o(f1)) = A7 Л A7 > 0 Л B(A7) = 7 Л ( G3 (p2)+vfo)) = A8 Л A8 > 0 Л B(A8) = 8

pi^fi = 6; (G^3, F1 ^2, F2 ^1} Alloc(G)=(A1, A2, AJA} Alloc(F1) = (A4, A7} Alloc(F2) = (As,A8} 8 F21( G3(p1)+U(f1)) = 6 Л mem upd(G3(p 1)+u(f1), F1,2,1)

p2^f2 = 5; (G^3, F1 ^2, F2 ^2} Alloc(G)=(A1, A2, AsA} Alloc(F1) = (A4, A7} Alloc(F2) = (As,A8} 8 F2( G3(p2)+u(f2)) = 6 Л mem upd(G3 (p2)+u (f2 ), F2,2,1)

assume(p1^f1 == p2f (G^3, F1 ^2, F2 ^2} Alloc(G)=(A1, A2, AsA} Alloc(F1) = (A4, A7} Alloc(F2) = (As,A8} 8 F1( G3(p1)+U(f1)) = F2(G3(p2)+u(f2))

Why the conjunction is unsat?

1) In the existing memory model memory allocated for pointers pi andp2 cannot

intersect because it was allocated using the known alloc () function (the corresponding path formula is not given).

2) In the given r constraints for this path (using the B&B model) the following contradicting elements are present:

. F2(G3(p1) + a(f1)) = F^(G3(p2) + ^(/2)); . F2(G3(p1) + w(/1)) = 5; . F2(G3(p2) + w(/2)) = 6. Let's take a look at the example program below. In the program's source code there are calls to the function undef_ptr() that returns an unknown pointer. The pointer p2 is initialized using this function. r constraints in terms of B&B memory model for the program are shown in table 3. Path formula can be made as conjunction of all formulas in r column of the table 3.

void * undef_ptr(); struct s { int f1, f2; }; struct s * p1; struct s * p2; p1 = alloc(); p2 = undef_ptr(); p1 -> f1 = 6; p2 -> f2 = 5;

assume(p1 -> f1 == p2 -> f2);

In B&B memory model pi ^ /1 and p2 ^ /2 exist in the separate memory regions. In r constraints for this path the same contradicting elements as for the previous example are present. Thus, the update of one of them wouldn't affect the other one. Because of that the result of verification would be that the error state is unreachable (path formula is still unsat).

However, in the existing memory model fields /1 and /2 of struct s exist in the same memory region and it uses only one uninterpreted function for them (see table 2 in [4]). Memory for their base pointers pi and p2 was allocated using known alloc() function and function undef_ptr() returning unknown pointer respectively. It cannot be confirmed that an update to a field /2 of the p2 wouldn't affect the access to the /1 struct field of pi. In the formula the location for field /2 of the p2 is (G3(p2) + m(/2)) which is unde/_ptr1 + w(/2). Locations (G3(pi) + w(/1)) and ( G3 (p2) + m(/2)) exist in the same region and may be equal. Thus the formula is satisfiable. It means that the result of verification with existing memory model will be a reachable path to the program's error state.

Usually such situations in practice are false alarms because different fields of different structures do not normally intersect. Thus, the assumptions related to this behavior in the existing memory model aren't really incorrect but they are quite improbable in practice. Usage of the B&B memory model will be able to reduce the number of false alarms caused by these assumptions (continued in section 6).

Table 3. Example build ofpath formula for the program with unknown memory function

Path instruction Index Alloc k' Г

struct s * p1; {G^i, F1 ^i, F2 ^i, undef_ptr^ i} Alloc(G) ={A1} i pi = A1 Л A1> 0 Л B(A1) = i

struct s * p2; (G^i, F1 ^i, F2 ^i, undef_ptr^ i} Alloc(G) ={A1, A2} 2 p2 = A2Л A2> 0 Л B(A2) = 2

pi = alloc(); (G^2, F1 ^i, F2 ^i, undef_ptr^ i} Alloc(G) ={A1, A2, A3} Alloc(F1) = {A4} Alloc(F2) = {A5} 3,4,5 G2(pi) = A3 Л A3> 0 Л B(A3) = 3 Л ( G2(pi)+u(h)) = A4 Л A4 > 0 Л B(A4) = 4 Л ( G2(pi)+<u(/2)) = A5 Л A5>0AB(As) = 5

p2=undef_ptr (); (G^3, F1 ^i, F2 ^i, undef_ptr^2} Alloc(G) ={A1, A2, A3} Alloc(F1) = {A4} Alloc(F2) = {A5} 5 G3(p2) = und e/_p tr-t Л mem upd(p2,G,3,2)

pi^fi = 6; (G^3, F1 ^2, F2 ^i, undef_ptr^2} Alloc(G) ={A1, A2, A3} Alloc(F1) = {A4} Alloc(F2) = {A5} 5 F21(G3(pi)+w(/1)) = 6 Л mem upd(G3(p\)+co(/1), F1,2,i)

p2f = 5; (G^3, F1 ^2, F2 ^2, undef_ptr^2} Alloc(G) ={A1, A2, A3} Alloc(F1) = {A4} Alloc(F2) = {A5} 5 F (G3 (p2')+(0 (/2 )) = 6 Л mem upd(G3(p2)+co(/2), F2,2,i)

assume(pi^fi == p2f (G^3, F1 ^2, F2 ^2, undef_ptr ^2} Alloc(G) ={A1, A2, A3} Alloc(F1) = {A4} Alloc(F2) = {A5} 5 F (G3(pi)+w(/1)) = F2(G3(p2)+co(/2))

5. Implementation notes

The creation of memory regions is an automated process. In CPAchecker verification tool CFA (control-flow automaton) is used as an inner representation of the program. It is sufficient to go through it and find in it all of the struct field

211

accesses. This allows to distinguish those fields that don't have their address taken somewhere in the program.

In the implementation we do not take into consideration the possibility of field accesses through pointer arithmetic and through the usage of pointer conversions because of the high improbability of such field accesses in program's source code.

6. Experiments

To determine the efficiency of B&B memory model implementation in comparison to existing memory model of the CPAchecker tool a number of launches were performed on the predefined sets of Linux kernel modules. To use the implemented memory model one must have:

• CPAchecker verification tool with revision number 23271 or higher from the branch trunk;

• option cpa.predicate.useMemoryRegions should be set to 'true'.

• The following experiments were made using the revision trunk:23271 of the tool.

6.1 False alarm set

The review of error traces obtained during the verification of Linux kernel 3.14 allowed to determine situations when reachability of error state was present due to updates to same-typed pointers' memory. This set consists of those 26 kernel modules that caused false alarms due to the updates to pointer's memory. The goal of this experiment was to find out what effect the usage of B&B memory model will have on the tools precision. Tables 4 and 5 hold information about changes of the tool's verdicts.

Table 4. B&B applicability

B&B could help B&B could not help

B&B helped 10 0

B&B did not help 0 16

Table 5. Verdict changes

False alarm ^ Safe False alarm ^ Unsafe False alarm ^ False alarm*

3 5 2

* - different error trace and cause of Unsafe

6.2 Linux 4.2-rc1 kernel modules

A set of Linux kernel drives (version 4.2-rc1) was selected to study the efficiency of B&B memory model implementation in comparison to the existing memory model of the CPAchecker tool.

The launch was performed for rule that checks correctness of functions working with usb_get_* and usb_put_* functions of usb-system. Launch results can be found in tables 6, 7. Launch configuration:

• time limit - 15 minutes;

• memory limit - 15 Gb;

• number of CPU cores - 4;

The differences in the regions the models have led to the difference in program's paths that are covered by the tool. This explains Unsafe ^ Unknown, Unknown ^ Safe and Unknown ^ Unsafe transitions, where Safe means that program's error state is unreachable, Unsafe - error state is reachable, Unknown - timeout or runtime error. This experiment's results show that the improvement to the tool's precision is present while the verification speed remains competitive.

Table 6. Linux 4.2-rc1 statistics

Existing model B&B

Verification time 35.8 hours 35.3 hours

Safe 4245 4241

Unsafe 69 68

Unknown 161 166

Table 7. Transitions

Existing model \ B&B model Safe Unsafe Unknown

Safe 4240 0 5

Unsafe 0 67 2

Unknown 1 1 159

6.3 SV-COMP'17 DeviceDrivers64

This set contains files from the DeviceDrivers64 set of the international competition on software verification SV-COMP'17. It consists of 2795 modules of different Linux kernel versions. Launch results can be found in tables 8, 9, 10. Launch configuration:

• time limit - 15 minutes;

• memory limit - 15 Gb;

• number of CPU cores - 4; Several of the transitions from the incorrect results can be explained by the difference in models' choice of pointer's may-aliases. The same modules were present in the earlier mentioned False alarm set. Several transitions to Unknown can be explained by the additional overhead costs required for B&B usage to the verification tasks on the verge of timeout.

Table 8. DeviceDrivers64 statistics

Memory models Existing B&B

Total number of files 2795 2795

Correct results 1791 1780

Error state unreachable 1524 1522

Error state reachable 267 258

Incorrect results 7 5

Missed errors 4 4

False alarms 3 1

Unknown 997 1010

Table 9. Time for DeviceDrivers64 set

Memory models Existing B&B

Total time 143.6 hours 143.1 hours

Time for correct results 14.9 hours 14.1 hours

SMT solver time 10500 sec (2.9 hours) 12400 sec (3.4 hours)

SMT solver time for correct results 660 sec 605 sec

Table 10. Transitions

Existing model \ B&B model Correct results Incorrect results Unknown

Correct results 1775 0 16

Incorrect results 2 5 0

Unknown 3 0 994

7. Conclusion

This paper proposes the specification of B&B memory model and its region-based reasoning in terms of uninterpreted functions. Its implementation on top of existing memory model of the CPAchecker verification tool provides better verification

precision while the verification speed remains competitive. The implementation was included in the official repository of the CPAchecker static verification tool.

References

1. V. Kuliamin, "Software verification methods," Vserossiiskii konkursnyi otbor obzornoanaliticheskikh statei po prioritetnomu napravleniyu "Informatsionnotelekommunikatsionnye sistemy" [Russian national competitive selection of review and analytical articles in priority direction "Information and telecommunication systems"], 117 p., 2008 (in Russian).

2. D. Beyer, T. A. Henzinger, and G. Theoduloz, "Configurable Software Verification: Concretizing the Convergence of Model Checking and Program Analysis," in Computer Aided Verification, ser. Lecture Notes in Computer Science, W. Damm and H. Hermanns, Eds., vol. 4590. Berlin, Heidelberg: Springer Berlin Heidelberg, 2006, pp. 504-518.

3. M. Mandrykin and A. Khoroshilov, "A memory model for deductively verifying Linux kernel modules," A.P. Ershov Informatics Conference, the PSI Conference Series, 11th edition, 2017 (to appear).

4. M. Mandrykin and V. Mutilin, "Modeling Memory with Uninterpreted Functions for Predicate Abstractions," Trudy ISP RAN/Proc. ISP RAS, vol. 27, issue 5, 2015, pp. 117-142 (in Russian). DOI: 10.15514/ISPRAS-2015-27(5)-7

5. R. Bornat, "Proving pointer programs in Hoare Logic," in Mathematics of Program Construction: 5th International Conference, MPC 2000, ser. Lecture Notes in Computer Science, R. Backhouse and J. N. Oliveira, Eds., vol. 1837. Berlin, Heidelberg: Springer Berlin Heidelberg, 2000, pp. 102-126.

6. R. Burstall, "Some techniques for proving correctness of programs which alter data structures," Machine Intelligence, vol. 7, pp. 23-50, 1972.

Метод моделирования памяти в предикатных абстракциях с разделением на непересекающиеся

области

1 А.Р. Волков <[email protected]> 2М.У. Мандрыкин <[email protected]> 1 Московский государственный университет имени М.В. Ломоносова, 119991, Россия, Москва, Ленинские горы, д. 1.

2 Институт системного программирования РАН, 109004, Россия, г. Москва, ул. А. Солженицына, д. 25.

Аннотация. Верификация программного обеспечения — вид деятельности, направленный на контроль качества программного обеспечения и обнаружения ошибок в нем. Статическая верификация - это один из способов верификации, который производится без выполнения исходного кода программы. Для статической верификации используется специальное программное обеспечение: инструменты статической верификации, которые часто работают с исходным кодом программы. Одним из таких инструментов является инструмент под названием CPAchecker. Проблема его текущей модели памяти заключается в том, что при встрече функции,

возвращающей указатель на область памяти, у которой отсутствует тело, в процессе верификации о ее возвращаемом значении могут быть сделаны произвольные предположения. Несмотря на то, что они теоретически допустимы, вероятность их выполнения на практике очень низка. Использование этих предположений может привести к ложному предупреждению в качестве результата верификации. В данной статье мы делаем обзор на один из подходов, благодаря которому можно избавиться от такой проблемы, а также предлагаем формальное описание данного подхода в терминах формул путей, содержащих неинтерпретируемые функции, которые инструмент использует для моделирования памяти программы. Также мы приводим результаты сравнительного анализа эффективности предложенной реализации относительно существующей модели памяти.

Ключевые слова: модель памяти; предикатные абстракции; статическая верификация. DOI: 10.15514/ISPRAS-2017-29(4)-13

Для цитирования: Волков А.Р., Мандрыкин М.У. Метод моделирования памяти в предикаты абстракциях с разделением на непересекающиеся области. Труды ИСП РАН, том 29, вып. 4, 2017 г., стр. 203-216 (на английском языке). DOI: 10.15514/ISPRAS-2017-29(4)-13

Список литературы

1. В.В. Кулямин, "Методы верификации программного обеспечения" Всероссийский конкурсный отбор обзорно-аналитических статей по приоритетному направлению "Информационно-телекоммуникационные системы", 117 стр., 2008.

2. D. Beyer, T. A. Henzinger, and G. Theoduloz, "Configurable Software Verification: Concretizing the Convergence of Model Checking and Program Analysis," in Computer Aided Verification, ser. Lecture Notes in Computer Science, W. Damm and H. Hermanns, Eds., vol. 4590. Berlin, Heidelberg: Springer Berlin Heidelberg, 2006, pp. 504-518.

3. M. Mandrykin and A. Khoroshilov, "A memory model for deductively verifying Linux kernel modules," A.P. Ershov Informatics Conference, the PSI Conference Series, 11th edition, 2017 (to appear).

4. Мандрыкин М.У. и Мутилин В.С., "Моделирование памяти с использованием неинтерпретируемых функций в предикатных абстракциях" Труды ИСП РАН, том 27, вып. 5, 2015, стр. 117-142. DOI: 10.15514/ISPRAS-2015-27(5)-7

5. R. Bornat, "Proving pointer programs in Hoare Logic," in Mathematics of Program Construction: 5th International Conference, MPC 2000, ser. Lecture Notes in Computer Science, R. Backhouse and J. N. Oliveira, Eds., vol. 1837. Berlin, Heidelberg: Springer Berlin Heidelberg, 2000, pp. 102-126.

6. R. Burstall, "Some techniques for proving correctness of programs which alter data structures," Machine Intelligence, vol. 7, pp. 23-50, 1972.