Huge SMT file and slow proof for simple array function

[rod-chapman]

I am experienced a huge (1.5GB) SMT file resulting from attempt to verify what appears to be a very simple function. I will add a link below to a simple reproducer.

This is drawn from the mldsa-native project.

This issue is currently blocking progress on mldsa-native and mlkem-native, so high priority for me.

[rod-chapman]

The reproducible test case is here:
https://github.com/rod-chapman/cbmc-examples/tree/main/issues/8617

Using CBMC 6.5.0, go there and do

make final.goto

to generate the GOTO file.

Then

make smt

to generate SMT - warning - this takes about 30 minutes, and fills 1.5GB of disk.

[rod-chapman]

FWIW - I re-wrote this example in SPARK just to make sure it really does verify. The entire analysis and proof run succeeds and takes 2 seconds using 1 CPU core on my Mac...

[rod-chapman]

SPARK version: https://github.com/rod-chapman/cbmc-examples/tree/main/issues/8617/spark

[tautschnig]

It seems that the assigns-clause/write-set tracking is causing very large array update expressions. We need to review why we are using havoc_slice in a place where this may be avoidable. (havoc_slice will update a data structure byte-by-byte, which is turning into very large array update expressions.) Updates will follow in due course.

[tautschnig]

It turns out the havoc_slice were all as directed by the input, but that's the right thing to use in this input (at least mostly). We'll fix this internally; in the meantime here is a patch that you can use that will make Z3 solve the problem in a few seconds:

diff --git a/issues/8617/poly.h b/issues/8617/poly.h
index b65bbbb..8070d99 100644
--- a/issues/8617/poly.h
+++ b/issues/8617/poly.h
@@ -25,8 +25,10 @@ __contract__(
   requires(memory_no_alias(a0, sizeof(poly)))
   requires(memory_no_alias(a, sizeof(poly)))
   requires(array_bound(a->coeffs, 0, MLDSA_N, 0, MLDSA_Q))
-  assigns(memory_slice(a1, sizeof(poly)))
-  assigns(memory_slice(a0, sizeof(poly)))
+  // assigns(memory_slice(a1, sizeof(poly)))
+  // assigns(memory_slice(a0, sizeof(poly)))
+  assigns(object_whole(a1))
+  assigns(object_whole(a0))
   ensures(array_bound(a1->coeffs, 0, MLDSA_N, 0, (MLDSA_Q-1)/(2*MLDSA_GAMMA2)))
   ensures(array_abs_bound(a0->coeffs, 0, MLDSA_N, MLDSA_GAMMA2+1))
 );
diff --git a/issues/8617/polyvec.c b/issues/8617/polyvec.c
index 530743b..9bf7f7a 100644
--- a/issues/8617/polyvec.c
+++ b/issues/8617/polyvec.c
@@ -12,13 +12,20 @@ void polyveck_decompose(polyveck *v1, polyveck *v0, const polyveck *v)

   for (i = 0; i < MLDSA_K; ++i)
   __loop__(
-    assigns(i, memory_slice(v0, sizeof(polyveck)), memory_slice(v1, sizeof(polyveck)))
+    // assigns(i, memory_slice(v0, sizeof(polyveck)), memory_slice(v1, sizeof(polyveck)))
+    assigns(i, object_whole(v0), object_whole(v1))
     invariant(i <= MLDSA_K)
     invariant(forall(k1, 0, i,
                      array_bound(v1->vec[k1].coeffs, 0, MLDSA_N, 0, (MLDSA_Q-1)/(2*MLDSA_GAMMA2)) &&
                      array_abs_bound(v0->vec[k1].coeffs, 0, MLDSA_N, MLDSA_GAMMA2+1)))
   )
   {
-    poly_decompose(&v1->vec[i], &v0->vec[i], &v->vec[i]);
+    poly c1, c0;
+    c1 = v1->vec[i];
+    c0 = v0->vec[i];
+    // poly_decompose(&v1->vec[i], &v0->vec[i], &v->vec[i]);
+    poly_decompose(&c1, &c0, &v->vec[i]);
+    v1->vec[i] = c1;
+    v0->vec[i] = c0;
   }
 }

[rod-chapman]

Thanks. I probably need to apply the same to several other functions. What are the basic rules in play here? e.g. "Don't do X, but do Y"?

[rod-chapman]

Why are the first two assignments to c0 and c1 required then poly_decompose() re-initializes those object entirely?