Benchmarking C Software Verifiers With LDV Tools¶

The core component of Linux Driver Verification tools is a verification tool for C language. Static analysis of driver sources, instrumented with environment models and rules, are eventually passed to such verifier, which performs the most important part of the whole work.

No wonder that the speed and quality of the overall analysis heavily depends on how well and fast the verifier performs. But the best verifier is yet to be found! There are several static C verifiers, which perform differently, and without experimenting it's not clear which one is the best for our purpose. Moreover, verifiers usually contain a number of tweaks and configuration opportunities, which also are to explore.

So one of the goals of LDV program is to build a framework that helps us in answering such questions, as:

• Which configuration of a verifier works faster on a test driver set?
• Which verifier checks more drivers within a given time limit?
• How would it affect verification, if we supply verifier with more memory?

We developed special components that gather, analyze, visualize and compare statistics of verification of a lot of different drivers. The drivers can either be automatically fetched from a pre-assembled test set, or could be automatically extracted from the Linux Kernel.

Visualization and comparison¶

Let us consider a sample experiment aimed to compare single-block encoding (SBE) and large-block encoding (LBE) implementation within CPAchecker. We have run CPAchecker on a so-called general test set (including fixed and unfixed versions of those drivers, in which we used to find bugs) with 3 minutes time limit and default memory limit per driver. Here are the results:

From this table we could see that LBE is generally faster than SBE. LBE verified more drivers (Ok columnt), and nevertheless it spent less time to do it (see Time OK column). Also you can see that SBE version ran out of memory more often.

Now let's see the improvements of LBE over SBE in detail. We click radio button to set the task we compare against (we pick the "worse" one), and check box near the task we want to compare, and press the "Compare tasks" button at the top of the page.

We get to a comparison page. We see that some drivers that were Unknown to SBE, are detected as Safe or Unsafe in LBE, so LBE surpasses SBE. However, we notice, that there were degradations: a driver with an error in it is detected by SBE, but is not by LBE (see the red circle):

We click the number to see what the driver was that:

Then we click the "left-hand" (LBE) ellipsis to see what the problem there is:

So it seems that LBE verification of that particular driver exceeds the memory limit for CPAchecker. We searched in the logs for a "message.ko", that had numbers "68_1" and 2.6.31.6 near it (see file test_logs in your working dir), and found the command line for CPAchecker verifying this driver.

We could also click the ellipsis at the other side and then proceed to error trace, which would show us where SBE CPAchecker found the bug. This would help in debugging.

How to use LDV for benchmarking¶

To use this benchmarking system you should first download sources of LDV tools (we recommend downloading the master branch). After downloading we recommend you to refer to file VerifierDevelopersHowTo (see source:VerifierDevelopersHowTo). It will tell you how you should install and use LDV tools in order to specifically address benchmarking verification tools. You will be able to easily change command line options, configuration files, vary time and memory limits.

For BLAST and CPAchecker verifiers, the preset wrappers with a number of configuration opportunities are shipped.