Skip to content

test(kani): cover short frames in ethernet from_bytes harnesses - #6367

Open
feliperodri wants to merge 1 commit into
firecracker-microvm:mainfrom
feliperodri:kani-ethernet-variable-length
Open

feliperodri wants to merge 1 commit into
firecracker-microvm:mainfrom
feliperodri:kani-ethernet-variable-length

Conversation

@feliperodri

Copy link
Copy Markdown
Contributor

Changes

verify_from_bytes and verify_from_bytes_unchecked now take a nondeterministic prefix of the MAX_FRAME_SIZE buffer (kani::slice::any_slice_of_array_mut), so they check every frame length from 0 to 1514 bytes, and they gain kani::cover!s for the short-frame and valid-frame paths.

Reason

Both harnesses built their input as [u8; MAX_FRAME_SIZE] and passed the whole array, so the length was always 1514 despite the "up to MAX_FRAME_SIZE" comment. The path for frames shorter than the Ethernet header (from_bytes returning an error, from_bytes_unchecked producing an invalid frame) was never reached. On main, adding kani::cover!(slice_length < PAYLOAD_OFFSET, "short frame") to verify_from_bytes gives:

 - Status: UNSATISFIABLE
 - Description: "short frame"
 ** 0 of 1 cover properties satisfied

With this change, with the flags from tests/integration_tests/test_kani.py (-Z unstable-options -Z stubbing -Z function-contracts -Z restrict-vtable), on Kani 0.68.0:

Checking harness dumbo::pdu::ethernet::kani_proofs::verify_from_bytes...
 ** 2 of 2 cover properties satisfied
VERIFICATION:- SUCCESSFUL
Verification Time: 0.52s
Checking harness dumbo::pdu::ethernet::kani_proofs::verify_from_bytes_unchecked...
 ** 2 of 2 cover properties satisfied
VERIFICATION:- SUCCESSFUL
Verification Time: 0.36s

The other ethernet harnesses also use a fixed-length buffer, but they assume or unwrap a valid frame, so a variable length would need extra assumptions; this PR leaves them unchanged.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.

PR Checklist

  • I have read and understand CONTRIBUTING.md.
  • I have run tools/devtool checkbuild --all to verify that the PR passes
    build checks on all supported architectures. (Not run: harness-only change under #[cfg(kani)]; verified with cargo kani on x86_64.)
  • I have run tools/devtool checkstyle --no-clippy to verify that the PR
    passes the automated style checks. (Not run; rustfmt --check with the repository's rustfmt.toml passes on the changed file.)
  • I have described what is done in these changes, why they are needed, and
    how they are solving the problem in a clear and encompassing way.
  • I have updated any relevant documentation (both in code and in the docs)
    in the PR.
  • I have mentioned all user-facing changes in CHANGELOG.md. (No user-facing changes.)
  • If a specific issue led to this PR, this PR closes the issue. (No issue.)
  • When making API changes, I have followed the
    Runbook for Firecracker API changes. (No API changes.)
  • I have tested all new and changed functionalities in unit tests and/or
    integration tests. (The changed harnesses run in test_kani.py.)
  • I have linked an issue to every new TODO. (No new TODOs.)

  • This functionality cannot be added in rust-vmm.

verify_from_bytes and verify_from_bytes_unchecked built their input as a
MAX_FRAME_SIZE array, so the frame length was always 1514 bytes despite
the "up to MAX_FRAME_SIZE" comment. The branch for frames shorter than
the Ethernet header (from_bytes returning an error, and
from_bytes_unchecked producing an invalid frame) was never reached:
kani::cover!(slice_length < PAYLOAD_OFFSET) is UNSATISFIABLE on main.

Take a nondeterministic prefix of the buffer with
kani::slice::any_slice_of_array_mut, so the harnesses check every length
from 0 to MAX_FRAME_SIZE, and add covers showing that both the short and
the valid frame paths are reached.

Signed-off-by: Felipe Monteiro <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants