-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
transmute_unchecked contracts and harnesses #185
base: main
Are you sure you want to change the base?
Changes from 5 commits
38b1ccc
55d6634
2c4de37
126f945
afa7318
c903885
a822c98
c089914
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4642,6 +4642,113 @@ mod verify { | |
let dst = if kani::any() { gen_any_ptr(&mut buffer2) } else { gen_any_ptr(&mut buffer1) }; | ||
unsafe { copy_nonoverlapping(src, dst, kani::any()) } | ||
} | ||
|
||
//We need this wrapper because transmute_unchecked is an intrinsic, for which Kani does not currently support contracts | ||
#[requires(crate::mem::size_of::<T>() == crate::mem::size_of::<U>())] //T and U have same size (transmute_unchecked does not guarantee this) | ||
#[requires(ub_checks::can_dereference(&input as *const T as *const U))] //output can be deref'd as value of type U | ||
#[allow(dead_code)] | ||
unsafe fn transmute_unchecked_wrapper<T,U>(input: T) -> U { | ||
unsafe { transmute_unchecked(input) } | ||
} | ||
|
||
#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
fn transmute_zero_size() { | ||
let empty_arr: [u8;0] = []; | ||
let unit_val: () = unsafe { transmute_unchecked_wrapper(empty_arr) }; | ||
assert!(unit_val == ()); | ||
} | ||
|
||
#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
fn transmute_u32_to_char() { | ||
let num: u32 = kani::any(); | ||
let c: char = unsafe {transmute_unchecked_wrapper(num)}; | ||
} | ||
|
||
#[kani::proof] | ||
#[kani::stub_verified(transmute_unchecked_wrapper)] | ||
#[kani::should_panic] | ||
fn transmute_invalid_u32_to_char() { | ||
let num: u32 = kani::any(); | ||
let c: char = unsafe {transmute_unchecked_wrapper(num)}; | ||
} | ||
|
||
#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
fn transmute_u8_to_bool() { | ||
let num: u8 = kani::any(); | ||
let b: bool = unsafe {transmute_unchecked_wrapper(num)}; | ||
} | ||
|
||
#[kani::proof] | ||
#[kani::stub_verified(transmute_unchecked_wrapper)] | ||
#[kani::should_panic] | ||
fn transmute_invalid_u8_to_bool() { | ||
let num: u8 = kani::any(); | ||
let b: bool = unsafe {transmute_unchecked_wrapper(num)}; | ||
} | ||
|
||
#[repr(C)] | ||
struct A { | ||
x: u8, | ||
y: u16, | ||
z: u8, | ||
} | ||
|
||
#[repr(C)] | ||
struct B { | ||
x: u8, | ||
y: u8, | ||
z: u16, | ||
} | ||
|
||
#[repr(C)] | ||
struct C { | ||
x: u16, | ||
Comment on lines
+4689
to
+4705
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you add some documentation explaining why do you need to define these particular structs with these particular types in order to verify this function? Looking at the harness below might give clues, but it'd be nice to add a bit more context to these Kani harnesses. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi Felipe, thanks for the review! That's a good point about the documentation, I'll try to add some more. To clarify, in this case, we were just trying to create structs with different types of layouts (A which has padding, B which has padding but a different size from A, and C which has no padding and is the same size as A)., and then we'd write harnesses that would succeed and some that would fail. To have an actual Kani proof though, we'd need to check all possible structs (possibly up to a bound since this is BMC). It's not clear to us however if Kani has some way to generate these structs. I was wondering if you had any thoughts on this. Thanks! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Kani doesn't have a generator for these kinds of structs. The non-determinism in Kani would come from the values that you store in the struct, but not from the internal types or layout. You could just use macros to make these cases cleaner, tho. |
||
y: u16, | ||
z: u16, | ||
} | ||
|
||
//this doesn't compile, A and B have different sizes due to padding | ||
/*#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
feliperodri marked this conversation as resolved.
Show resolved
Hide resolved
|
||
fn transmute_unchecked_padding() { | ||
let a = A {x: kani::any(), y: kani::any(), z: kani::any()}; | ||
let x = a.x; | ||
|
||
let b: B = unsafe { transmute_unchecked_wrapper(a) }; | ||
assert!(b.x == x); | ||
}*/ | ||
|
||
#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
fn transmute_unchecked_padding() { | ||
let a = A {x: kani::any(), y: kani::any(), z: kani::any()}; | ||
let x = a.x; | ||
|
||
let c: C = unsafe { transmute_unchecked_wrapper(a) }; | ||
assert!(c.x as u8 == x); | ||
} | ||
|
||
#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
fn transmute_unchecked_2ways_i64_u64() { | ||
let a: i64 = kani::any(); | ||
let b: u64 = unsafe { transmute_unchecked_wrapper(a) }; | ||
let c: i64 = unsafe { transmute_unchecked_wrapper(b) }; | ||
assert_eq!(a,c); | ||
} | ||
|
||
#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
fn transmute_unchecked_2ways_i32_u32() { | ||
let a: i32 = kani::any(); | ||
let b: u32 = unsafe { transmute_unchecked_wrapper(a) }; | ||
let c: i32 = unsafe { transmute_unchecked_wrapper(b) }; | ||
assert_eq!(a,c); | ||
} | ||
|
||
#[kani::proof_for_contract(transmute_unchecked_wrapper)] | ||
fn transmute_unchecked_2ways_i8_u8() { | ||
let a: i8 = kani::any(); | ||
let b: u8 = unsafe { transmute_unchecked_wrapper(a) }; | ||
let c: i8 = unsafe { transmute_unchecked_wrapper(b) }; | ||
assert_eq!(a,c); | ||
} | ||
|
||
// FIXME: Enable this harness once <https://github.com/model-checking/kani/issues/90> is fixed. | ||
// Harness triggers a spurious failure when writing 0 bytes to an invalid memory location, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you able to catch issues where the structure representation is not
C
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sort of -- only in cases where one struct predictably ends up larger than the other, triggering the
transmute_unchecked
Kani bug discussed in the other comment (e.g., structs A and C userepr(packed)
and we try totransmute_unchecked
A to C). In other words, withC
and the other representations tested (the default rust one,packed
,align
), the padding always seems to work as expected, but if the two structs differ in size after padding, then compiling the invocation oftransmute_unchecked
doesn't work (just like with any two variables of different size, in general).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just wondering if there is any way we can ensure that transmuting will not expose padding values if the layout changes when at least one of the inputs representation is not stable. We could turn on randomizing layouts, but that wouldn't be a proof. Any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see what you mean -- from our understanding though, there don't seem to be any guarantees about the padding/layouts in the Rust representation (i.e., anything is allowed), so we don't see a way that Kani (or any tool) could reason about the arbitrary layouts permissible under today's Rust specification. I guess to do something like that, we'd need to have at least some guarantees about the possible layouts.