1

I am currently trying to evaluate a test suite with Frama-C and it's plugin Eva. To do this I run Frama-C with the following flags:

frama-c -eva -cpp-extra-args="-DINCLUDEMAIN -I .../<headerfile folder>" <some c file>.c

Frama-C (24.0) was installed via Opam. When running eva one ouput is:

[eva] using spcification for function strcpy

and

[eva] FRAMAC_SHARE/libc/string.h:373:cannot evaluate ACSL term, unsupported ACSL construct: logic function strcmp

as you can see here: Eva states unsupported ACSL construct.

When looking into the string.h (~/.opam/default/share/frama-c/libc) file I was able to find the strcpy function:

/*@
...
@ ensures equal_contents: strcmp(dest,src) == 0;
@ ensures result_ptr: \result == dest;
@*/
extern char *strcpy(char *restrict dest, const char *restrict src);

And the strcmp function:

/*@ requires valid_string_s1: valid_read_string(s1);
                       `@ requires valid_string_s2: valid_read_string(s2);
@ assigns \result \from indirect:s1[0..], indirect:s2[0..];
              @ ensures acsl_c_equiv: \result == strcmp(s1,s2);
 @*/
extern int strcmp (const char *s1, const char *s2);

As I understand Eva uses this file with ACSL contracts to know what exactly needs to be checked and the ACSL contract is given for strcmp.

Does somebody know why this error message occurs and how to fix this?
Much thanks in advance!!!

Obsidian
  • 3,719
  • 8
  • 17
  • 30
Gerry
  • 13
  • 4
  • Note: the message is *not* an error message; it is simply a *result* message, which is neither a warning, nor an alarm, not an error. It is simply stating the fact that the *logical* function `strcmp` (and not the C function `strcmp`) is unsupported. But then why is it in the specification of `strcpy`? Because, long ago, most functions in `string.h` had proofs related to the Jessie plugin, which used such specifications. And other plugins such as WP may still want them. For Eva, this generates a message that can be safely ignored (correctness is checked by other means). – anol Feb 13 '22 at 18:55
  • In practice, in this case, Eva might decide to do nothing and silently ignore the specification (it does not affect the correctness of its analysis). But the user might wonder why the result is imprecise; hence why the message is there. As Virgile said, if you want more precision for the function, you need to include `string.c`, and use Frama-C's provided implementation, or provide your own. – anol Feb 13 '22 at 18:57
  • Hey thank you for the explanation, what exactly do you mean by Frama-C's provided implementation? Are there some additional provided implementations I didn't mention?@anol – Gerry Feb 18 '22 at 01:43
  • If you explicitly include a `.c` file from Frama-C's libc (with something like `$(frama-c-config -print-share-path)/libc/string.c` along with the other sources in the command line, e.g. after the `.c` in your example), then Eva will have function definitions that it can use, for functions like `strcmp`. If your program is sufficiently small and you have enough of `-eva-precision` or `-eva-slevel` for the states to be split, that can improve precision of the analysis. – anol Feb 18 '22 at 07:46

1 Answers1

1

Eva does not support all ACSL constructions. Notably, strcmp is defined by an axiom (see __fc_string_axiomatics.h), which is good for the WP plugin, but very bad for Eva. There are a few things that you can do:

  • decide that you don't care. If the fact that the result of strcmp is imprecise is not important for your analysis, then it's not important that this post-condition can't be evaluated by Eva.
  • include string.c from Frama-C's libc in the list of files that you parse: this will provide a definition of strcmp that Eva will analyze. Note that since this definition is basically the for loop that you'd expect, you might need to tweak Eva's precision options if you want a precise result. Basically, for that, just add $(frama-c -print-share-path)/libc/string.c on the command line.
  • provide your own definition of the function.
Virgile
  • 9,724
  • 18
  • 42
  • Hey, unfortunately the flaw I want it to find is actually in the `strcpy` command, therefore the post-condition is pretty important. I have also the same issue for `memcmp` and it is not included in the bultins-list. The memcmp error is triggered by `[eva] using specification for function printLine`, which again results in `unsupported ACSL construct`. Also kernel outputs a warning `[kernel:annot:missing-spec] ... Warning: Neither code nor specification for function printLine, generating default assigns from the prototype` – Gerry Feb 11 '22 at 17:38
  • yes, sorry, `memcmp` is not a builtin, so that I guess that using the definitions from `string.c` is the best way. I'll edit the answer accordingly. The message about a missing-spec is very different: `printLine` has no ACSL contract at all (and no body either): you have to provide one at some point (if it's only an output function, it can be as simple as `assigns \nothing;`). – Virgile Feb 11 '22 at 17:49
  • Hey could you explain how I can use the definitions from string.c for eva? I am not actually sure how and wher eva uses definitions. – Gerry Feb 11 '22 at 19:00
  • You just have to put the path on Frama-C's command line, together with all the source files you want to consider (of course, since it resides in Frama-C 's share path, you usually have to provide a complete path, hence the `$(frama-c -print-share-path)` prefix in my answer). If a function has a definition, Eva will automatically use it, unless specifically instructed otherwise with `-eva-use-spec `. However, it will also try to evaluate the contract afterwards, so you will still see the warning about unsupported ACSL construct. – Virgile Feb 12 '22 at 09:12
  • Hey, I tried it with parsing the string.c file. Following output is now occurring instead of the ``[eva] using specification for function strcpy`` and the following unsupported ACSL statement: ``[eva] FRAMAC_SHARE/libc/string.c:223: starting to merge loop iterations`` and ``[eva:alarm] FRAMAC_SHARE/libc/string.c:223: Warning: out of bounds read. assert \valid_read(src + i);``. The mentioned line 223 is just a strcpy definition. What exactly does this mean now? Does this mean that the strcpy of the investigated file is getting out of bound and therfore we found the vulnerability? @Virgile – Gerry Feb 18 '22 at 01:54
  • the first message is merely informative. The second message indicates that Eva is not able to check that accessing `src[i]` is safe, thus it emits an alarm and proceeds with the analysis under the assumption that no error occurred (trying to reduce its state accordingly). This may or may not be the vulnerability you're after, but if you have questions about how to interpret Eva's output, open a new question, it can't really be answered in a comment. – Virgile Feb 18 '22 at 11:32