Challenge 6: Safety of `NonNull`

[tautschnig]

Challenge 6: Safety of NonNull

[zhassan-aws]

Continuing the discussion from #84.

I found that without supplying the --harness option, both proofs in unique.rs and non_null.rs are not run.

This sounds like a bug. Can you:

1. Post the full log from Kani including the command you used to run it
2. Point to a branch on which I can reproduce this issue

?

I ended up changing the harness function name to a unique one(--harness non_null_check_new_unchecked) and that was successful(the fully-qualified name still has an error).

Can you post the harness name printed in the Kani output? The name is included in a line of the form:

Checking harness <harness-name>

[zhassan-aws]

A second question is if the contract has specified a pre-condition(e.g. !ptr.is_null()), does that mean in the harness we don't need to make the assumption that xptr is not null? In other words, the ensures clause acts like an assume statement?

Correct. When verifying a contract (using proof_for_contract), a requires clause acts as an assumption, and the ensures clause acts like an assertion. When stubbing a function using its contract (using stub_verified), a requires clause acts as an assertion, and the ensures clause acts like an assumption.

[QinyuanWu]

@zhassan-aws I realized I didn't find these proofs being run was because kani has not finished running proofs in the other modules yet, I will let it run for longer to get the complete result for all proofs in the library.

I found that without supplying the --harness option, both proofs in unique.rs and non_null.rs are not run.

This sounds like a bug. Can you:

1. Post the full log from Kani including the command you used to run it
2. Point to a branch on which I can reproduce this issue

I found the correct full name to be ptr::non_null::verify instead of core::ptr::non_null::verify for all proofs in non_null.rs. Thank you so much!

?

I ended up changing the harness function name to a unique one(--harness non_null_check_new_unchecked) and that was successful(the fully-qualified name still has an error).

Can you post the harness name printed in the Kani output? The name is included in a line of the form:

Checking harness <harness-name>

[QinyuanWu]

@zhassan-aws Following up on our meeting just now, would you please give us a rundown on Kani's capability to verify the four undefined behaviors for challenge 6? You mentioned that Kani can verify property 1,2, and 4(partially) and we also want to know which flags are verifying these properties. For property 3 is there a timeline on when the check would be released?

1. Accessing (loading from or storing to) a place that is dangling or based on a misaligned pointer.
2. Reading from uninitialized memory.
3. Mutating immutable bytes.
4. Producing an invalid value.

[gracemqz]

@feliperodri Hi Felipe, this is Grace from CMU III, I'm the project manager of Team 4. Could you please assign me to the issue as well?

[zhassan-aws]

You mentioned that Kani can verify property 1,2, and 4(partially) and we also want to know which flags are verifying these properties.

Correct. No flags are needed for 1 and 2 (the checks are ON by default). For 4, the -Z valid-value-checks flag needs to be passed to Kani. The currently supported cases are outlined in model-checking/kani#3085.

For property 3 is there a timeline on when the check would be released?

For 3, the timeline is not clear at the moment. There is experimental support added in a branch of the Kani repository (i.e. it's not included in the Kani releases): https://github.com/model-checking/kani/tree/features/aliasing-checks. We can perhaps experiment with the current support and see if it's sufficient.

[QinyuanWu]

@zhassan-aws How should we interpret unreachable code results? For one of the checks for new_unchecked, it showed the following:

Check 14: ptr::non_null::NonNull::<i32>::new_unchecked::{closure#1}.unreachable.1
	 - Status: SUCCESS
	 - Description: "unreachable code"
	 - Location: library/core/src/ptr/non_null.rs:200:5 in function ptr::non_null::NonNull::<i32>::new_unchecked::{closure#1}

What does this mean? Is this normal or does that indicate we need to modify the harness? Thanks!

[zhassan-aws]

Hi @QinyuanWu. This indicates that some code that should be unreachable (as indicated by the check name) was indeed proven to be unreachable (as indicated by the SUCCESS status). So, nothing to be alarmed about.

[QinyuanWu]

Thank you @zhassan-aws. Is it possible to view the source coverage as well? I added -Z source-coverage, but I didn't see any coverage report in the output. The entire command I used was: kani verify-std -Z unstable-options "path/to/library" -Z function-contracts -Z mem-predicates -Z source-coverage --harness ptr::non_null::verify::non_null_check_new which verifies both non_null_check_new and non_null_check_new_unchecked.

[zhassan-aws]

For instance, this program:

#[kani::proof]
fn foo() {
    let x: i8 = kani::any();
    let y: i8 = kani::any();
    let z = (x as i16).checked_add(y as i16);
    // unwrap the result using a match
    let z = match z {
        Some(z) => z,
        None => unreachable!(),
    };
}

calls unreachable in the None arm because the addition is not expected to overflow. When we run Kani, it produces:

RESULTS:
Check 1: foo.unreachable.1
         - Status: SUCCESS
         - Description: "unreachable code"
         - Location: test.rs:7:19 in function foo

Check 2: foo.assertion.1
         - Status: SUCCESS
         - Description: "internal error: entered unreachable code: "
         - Location: test.rs:9:17 in function foo


SUMMARY:
 ** 0 of 2 failed

VERIFICATION:- SUCCESSFUL

and thus it proved the None case is indeed unreachable.