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.

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

Dereference pointers in shims as correct types #2661

Merged
merged 3 commits into from
Jun 15, 2023

Conversation

beepster4096
Copy link
Contributor

@beepster4096 beepster4096 commented Nov 10, 2022

Currently, shims will dereference pointers as the type written by the user. This can cause false positives, incorrect behavior such as #2136, and even ICEs if a field is not present.

This PR fixes this by having shims dereference pointers with types from std or libc that we can rely on the layout and field names of instead of with whatever the user passed in.

Fixes #1123

@oli-obk
Copy link
Contributor

oli-obk commented Nov 10, 2022

Do you have some concrete examples that failed before this PR? I have a hard time coming envisioning what this PR is actually doing.

@RalfJung
Copy link
Member

RalfJung commented Nov 11, 2022 via email

@oli-obk
Copy link
Contributor

oli-obk commented Nov 11, 2022

Instead of switching to using hardcoded types in miri, could we just verify the layout matches what we expect and keep the existing logic? Making wrong types an error instead of assuming types

@RalfJung
Copy link
Member

RalfJung commented Nov 11, 2022

For raw ptr functions, wrong types are not really an error. Conceptually we should just tell Miri to read/write things at a given fixed offset, but that quickly gets annoying -- so this PR essentially uses the libc/std types to determine that offset.

@oli-obk
Copy link
Contributor

oli-obk commented Nov 11, 2022

Hmm I guess that makes sense, but still sad. Would it maybe be good to nudge people with a warning?

@RalfJung
Copy link
Member

At least on Windows people can't use the exact std type as those are private (and indeed #2136 was caused by two different call sites using two different but equally valid types).

@beepster4096
Copy link
Contributor Author

Do you have some concrete examples that failed before this PR? I have a hard time coming envisioning what this PR is actually doing.

Here's one for windows. While I don't think anybody would actually do this, it still should work.

extern "system" {
    // this is completely legal, FILETIME has the same size and lower alignment than u64
    fn GetSystemTimeAsFileTime(out: *mut u64);
}

fn main() {
    unsafe {
        GetSystemTimeAsFileTime(&mut 0);
    }
}

src/helpers.rs Outdated Show resolved Hide resolved
@bors
Copy link
Contributor

bors commented Nov 13, 2022

☔ The latest upstream changes (presumably #2663) made this pull request unmergeable. Please resolve the merge conflicts.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 14, 2022
…=oli-obk

interpret: make check_mplace public

This helps avoid code duplication in rust-lang/miri#2661.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Nov 14, 2022
…=oli-obk

interpret: make check_mplace public

This helps avoid code duplication in rust-lang/miri#2661.
@RalfJung
Copy link
Member

@drmeepster could you rebase? Now check_mplace is a public function which you can call to avoid most of the code duplication.

@beepster4096 beepster4096 changed the title Do field projections on known types Dereference pointers in shims as correct types Nov 16, 2022
@beepster4096
Copy link
Contributor Author

I noticed that almost every use of deref_operand is problematic, not just field accesses. While just reading from a pointer won't ice, it can cause false positives if the pointee type is wrong. I've changed these to use deref_operand_as too.

src/shims/time.rs Outdated Show resolved Hide resolved
@bors
Copy link
Contributor

bors commented Nov 17, 2022

☔ The latest upstream changes (presumably 3162b7a) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung
Copy link
Member

We unfortunately had to force-push to Miri. Could you rebase this to new master? Let me know if you need help wrestling with git.

@beepster4096
Copy link
Contributor Author

Rebase done, review comments not addressed yet.

@RalfJung
Copy link
Member

@rustbot author

@rustbot rustbot added the S-waiting-on-author Status: Waiting for the PR author to address review comments label Nov 23, 2022
@RalfJung
Copy link
Member

FYI I have cherry-picked the first commit from this PR into #2696, to avoid conflicts. Please rebase once #2696 lands.

@bors
Copy link
Contributor

bors commented Nov 26, 2022

☔ The latest upstream changes (presumably #2696) made this pull request unmergeable. Please resolve the merge conflicts.

@beepster4096
Copy link
Contributor Author

Its been a while, sorry. Rebased and comments addressed.

@RalfJung
Copy link
Member

RalfJung commented Jun 3, 2023

Just trying something here, please ignore.
@bors delegate+

@oli-obk oli-obk self-assigned this Jun 4, 2023
@oli-obk oli-obk added S-waiting-on-review Status: Waiting for a review to complete and removed S-waiting-on-author Status: Waiting for the PR author to address review comments labels Jun 4, 2023
@RalfJung
Copy link
Member

RalfJung commented Jun 5, 2023

@bors delegate-

@oli-obk
Copy link
Contributor

oli-obk commented Jun 15, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Jun 15, 2023

📌 Commit d537ab9 has been approved by oli-obk

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jun 15, 2023

⌛ Testing commit d537ab9 with merge 71312d6...

@bors
Copy link
Contributor

bors commented Jun 15, 2023

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 71312d6 to master...

1 similar comment
@bors
Copy link
Contributor

bors commented Jun 15, 2023

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 71312d6 to master...

@bors bors merged commit 71312d6 into rust-lang:master Jun 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Waiting for a review to complete
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Figure out a way to do name resolution in value vs type namespace
5 participants