Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?
transmute_unchecked contracts and harnesses #185
Changes from 3 commits
38b1ccc
55d6634
2c4de37
126f945
afa7318
c903885
a822c98
c089914
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
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.
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 comment
The 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 comment
The 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.