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

Add debug assertions to raw pointer methods testing for unaligned/NULL pointers #53871

Closed
RalfJung opened this issue Aug 31, 2018 · 8 comments · Fixed by #69509
Closed

Add debug assertions to raw pointer methods testing for unaligned/NULL pointers #53871

RalfJung opened this issue Aug 31, 2018 · 8 comments · Fixed by #69509
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@RalfJung
Copy link
Member

RalfJung commented Aug 31, 2018

In #53783, we document more precisely the rules for the various methods that can be used to access memory through raw pointers. In particular, we clarify that the pointer must be non-NULL and aligned even when the access has size 0.

This issue is about helping people find bugs in libstd by adding a debug_assert! to all these methods testing that condition, similar to what I did for from_raw_parts. I suggest to add a helper method to raw pointers to test this, and also use that for from_raw_parts and from_raw_parts_mut.

This may uncover issues in libstd, uncovering misuses of these methods. Those should then be fixed.

@RalfJung RalfJung added the E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. label Aug 31, 2018
@RalfJung RalfJung added the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label Nov 28, 2018
@nitnelave
Copy link
Contributor

I might be interested in working on that. Could you help me with a starting point for that?

@RalfJung
Copy link
Member Author

You might want to start with https://doc.rust-lang.org/nightly/std/ptr/fn.write_bytes.html. It could get a check similar to

debug_assert!(data as usize % mem::align_of::<T>() == 0, "attempt to create unaligned slice");

To avoid code duplication, consider adding a (private) helper method in ptr.rs for this purpose, and using it in both the old places (from_raw_parts{,_mut}) and write_bytes.

Other candidates besides write_bytes are copy and copy_nonoverlapping. We could also go further, but maybe we should involve the libs team there... so let's get started with these 3.

@nitnelave
Copy link
Contributor

Sorry for the delay, it took me a while to free up some time. Quick questions:

  • I found write_bytes in libcore/ptr.rs. However, one is just a delegation to the intrinsic, and the other one is for *const T, which is just a call to the previous one. Should I hunt the intrinsic in the C code, or provide a rust wrapper that will check the assumptions and call the intrinsic?
  • I couldn't find a from_raw_parts in ptr.rs. The only ones I could find were for vec, string, slice and in libstd/sys/sgx/abi/usercalls/alloc.rs. Am I missing something?

@nitnelave
Copy link
Contributor

Ah, intrinsics are still written in Rust, but as code generation functions. Well, I guess adding debug assertions everywhere in the intrinsics would be counter-productive, so we're going for the wrapper? Although, I'm not sure how to cleanly hijack the interface: I have to keep using the same function name for the callers, so that I don't have to change their code, but unless I don't understand how it works, I also need to have the same signature including the function name for the code generation. How should I proceed?

@RalfJung
Copy link
Member Author

RalfJung commented Jan 29, 2019

Ah good point, I forgot about these reexports.

I think the right way forward is to replace this line by a wrapper function that just calls the intrinsic. The docs should be moved from intrinsics.rs to ptr.rs. That move should be a total NOP.

The, in the 2nd step, you can add the debug_assert! in the delegating wrapper you just added.

couldn't find a from_raw_parts in ptr.rs

Sorry, I meant the one in slice.rs. It already has a debug_assert!, but that does not test as much as it could (i.e., it accepts NULL).

bors added a commit that referenced this issue Jan 30, 2019
Wrap write_bytes in a function. Move docs

This will allow us to add debug assertions.
See issue #53871.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Feb 17, 2019
Wrap write_bytes in a function. Move docs

This will allow us to add debug assertions.
See issue rust-lang#53871.
Centril added a commit to Centril/rust that referenced this issue Feb 20, 2019
Wrap write_bytes in a function. Move docs

This will allow us to add debug assertions.
See issue rust-lang#53871.
bors added a commit that referenced this issue Feb 22, 2019
Wrap write_bytes in a function. Move docs

This will allow us to add debug assertions.
See issue #53871.
@RalfJung
Copy link
Member Author

RalfJung commented Feb 26, 2019

@nitnelave Congrats, your patch landed. :) So with the preparation out of the way, let me know if you need any help with adding the debug assertions.

@nitnelave
Copy link
Contributor

nitnelave commented Feb 26, 2019 via email

@RalfJung
Copy link
Member Author

Cc #51713

Centril added a commit to Centril/rust that referenced this issue Jun 10, 2019
get rid of real_intrinsics module

instead import intrinsics locally in their wrapper functions.

(These functions are wrapper functions as a preparation to fixing rust-lang#53871.)
Centril added a commit to Centril/rust that referenced this issue Jun 26, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Centril added a commit to Centril/rust that referenced this issue Jun 27, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Centril added a commit to Centril/rust that referenced this issue Jun 27, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Manishearth added a commit to Manishearth/rust that referenced this issue Jul 2, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jul 3, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Centril added a commit to Centril/rust that referenced this issue Jul 4, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jul 4, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jul 4, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jul 15, 2019
Add debug assertions to write_bytes and copy*

Looks like @nitnelave  went MIA in rust-lang#58783, so I am re-submitting their PR, tweaked just a bit. I took care to preserve commit authorship.

Cc rust-lang#53871
@jonas-schievink jonas-schievink added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 29, 2019
JohnTitor added a commit to JohnTitor/rust that referenced this issue Feb 16, 2020
…acrum

debug_assert a few more raw pointer methods

Fixes rust-lang#53871
JohnTitor added a commit to JohnTitor/rust that referenced this issue Feb 16, 2020
…acrum

debug_assert a few more raw pointer methods

Fixes rust-lang#53871
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 16, 2020
…acrum

debug_assert a few more raw pointer methods

Fixes rust-lang#53871
Centril added a commit to Centril/rust that referenced this issue Feb 17, 2020
…acrum

debug_assert a few more raw pointer methods

Fixes rust-lang#53871
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Feb 25, 2020
…acrum

debug_assert a few more raw pointer methods

Fixes rust-lang#53871
bors added a commit that referenced this issue Feb 26, 2020
debug_assert a few more raw pointer methods

Fixes #53871
bors added a commit that referenced this issue Feb 29, 2020
debug_assert a few more raw pointer methods

Makes progress for #53871
@bors bors closed this as completed in 1057dc9 Mar 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants