Skip to content
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.

Sign up for GitHub

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

fix test_new_from_file_crafted_executable for m1 #26009

Merged
merged 2 commits into from
Jun 27, 2022
+9 −3
Merged

fix test_new_from_file_crafted_executable for m1 #26009

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bfced46
fix test_new_from_file_crafted_executable for m1
apfitzge Jun 16, 2022
cc53b85
re-add old assert/comment, but disable for aarch64
apfitzge Jun 22, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions runtime/src/append_vec.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -899,16 +899,16 @@ pub mod tests {
let accounts = av.accounts(0);
let account = accounts.first().unwrap();

// upper 7-bits are not 0, so sanitization should fail
assert!(!account.sanitize_executable());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

my memory is vague. but i think i tried to add this assertion, but i couldn't because the ub assertion below stopped working correctly back then. (welcome to UB land. lol)

if today's build toolchain doesn't negatively affect the UB detection code, please leave to assert! here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^passing CI with the assert left there.


// we can observe crafted value by ref
{
let executable_bool: &bool = &account.account_meta.executable;
// Depending on use, *executable_bool can be truthy or falsy due to direct memory manipulation
// assert_eq! thinks *executable_bool is equal to false but the if condition thinks it's not, contradictorily.
// Depending on use, *executable_bool can be truthy or falsy due to direct memory manipulation.
// Behavior is dependent on compiler.
// assert! thinks !*executable_bool is true, for all compilers
assert!(!*executable_bool);
const FALSE: bool = false; // keep clippy happy
if *executable_bool == FALSE {
panic!("This didn't occur if this test passed.");
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you restore this with #[cfg(!m1)]?

the intent isn't clear but this test is checking the existence of undefined behavior around bool inside rustc (or llvm): https://doc.rust-lang.org/reference/types/boolean.html:

An object with the boolean type has a size and alignment of 1 each. The value false has the bit pattern 0x00 and the value true has the bit pattern 0x01. It is undefined behavior for an object with the boolean type to have any other bit pattern.

as you know, we're not relying on the UB (bit pattern other than 0x00 and 0x01 for bool) in any production code. however, this assertion is needed to validate that this test is still exposing the UB to make sure we're not relaying on it accidentally. So, if possible, i want to the test to check the existence of UB at least for x64.

any ad-hoc cfg should be fine as long as our CI is happy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, re-added the if/panic, but disabled it for aarch64.

assert_eq!(*account.ref_executable_byte(), crafted_executable);
}

Expand Down