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

Apply #![deny(unsafe_op_in_unsafe_fn)] to sys/windows #76676

Closed

Conversation

carbotaniuman
Copy link
Contributor

Put unsafe operations in unsafe blocks for sys/windows. Partial fix for #73904.

@rust-highfive
Copy link
Collaborator

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 13, 2020
@jyn514 jyn514 added C-cleanup Category: PRs that clean code up or issues documenting cleanup. F-unsafe-block-in-unsafe-fn RFC #2585 T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 13, 2020
library/std/src/sys/windows/alloc.rs Show resolved Hide resolved
library/std/src/sys/windows/alloc.rs Show resolved Hide resolved
library/std/src/sys/windows/alloc.rs Outdated Show resolved Hide resolved
library/std/src/sys/windows/alloc.rs Show resolved Hide resolved
library/std/src/sys/windows/alloc.rs Outdated Show resolved Hide resolved
library/std/src/sys/windows/args.rs Outdated Show resolved Hide resolved
}

/// # Safety
///
/// `ptr`, once aligned, must have space for a Header at `ptr.offset(-1)`.
Copy link
Member

Choose a reason for hiding this comment

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

This is not a sufficient condition. ptr must not only have space, but also be valid for writing. Consider borrowing from https://doc.rust-lang.org/nightly/std/ptr/fn.write.html#safety, for example.

It looks like regardless this function is wrong as it gets &mut access to uninitialized memory -- it would be worth fixing that before trying to document unsafety here, I think, likely in a separate PR. Or at least leaving a FIXME comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should I just inline the function and avoid the &mut?

Copy link
Member

Choose a reason for hiding this comment

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

Change get_header to return a *mut Header and change align_ptr to use ptr::write to write the header.

@bors

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Oct 2, 2020

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@LeSeulArtichaut LeSeulArtichaut added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 16, 2020
@LeSeulArtichaut
Copy link
Contributor

Ping from triage: @carbotaniuman could you resolve the merge conflicts and address the last review comment? Thanks!

@carbotaniuman
Copy link
Contributor Author

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 19, 2020
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 19, 2020
@JohnTitor
Copy link
Member

r? @Mark-Simulacrum as you left some reviews before.

}

#[inline]
unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 {
allocate_with_flags(layout, c::HEAP_ZERO_MEMORY)
// SAFETY: the safety contract for `allocate_with_flags must be upheld by the caller.
Copy link
Member

Choose a reason for hiding this comment

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

This is likely not sufficient. See e.g. #74477 for necessary commentary here; these comments should show that the function being called has preconditions equivalent to the trait.

There are several more cases in this PR where you assert that the preconditions/safety contract of X must be upheld by the caller, please take a look at those and try to adjust them too.

@Mark-Simulacrum
Copy link
Member

#76676 (comment) is also not yet resolved.

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 5, 2020
@crlf0710
Copy link
Member

@carbotaniuman Ping from triage, would you mind addressing the comments above? Thanks!

@JohnCSimon
Copy link
Member

@carbotaniuman Pinging again from triage, would you mind addressing the comments above? Thanks!

@Dylan-DPC-zz
Copy link

@carbotaniuman thanks for taking the time to contribute. I have to close this due to inactivity. If you wish and you have the time you can open a new PR with these changes and we'll take it from there. Thanks

@Dylan-DPC-zz Dylan-DPC-zz added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 8, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Apr 2, 2021
Rework `std::sys::windows::alloc`

I came across rust-lang#76676 (comment), which points out that there was unsound code in the Windows alloc code, creating a &mut to possibly uninitialized memory. I reworked the code so that that particular issue does not occur anymore, and started adding more documentation and safety comments.

Full list of changes:
 - moved and documented the relevant Windows Heap API functions
 - refactor `allocate_with_flags` to `allocate` (and remove the other helper functions), which now takes just a `bool` if the memory should be zeroed
 - add checks for if `GetProcessHeap` returned null
 - add a test that checks if the size and alignment of a `Header` are indeed <= `MIN_ALIGN`
 - add `#![deny(unsafe_op_in_unsafe_fn)]` and the necessary unsafe blocks with safety comments

I feel like I may have overdone the documenting, the unsoundness fix is the most important part; I could spit this PR up in separate parts.
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Apr 2, 2021
Rework `std::sys::windows::alloc`

I came across rust-lang#76676 (comment), which points out that there was unsound code in the Windows alloc code, creating a &mut to possibly uninitialized memory. I reworked the code so that that particular issue does not occur anymore, and started adding more documentation and safety comments.

Full list of changes:
 - moved and documented the relevant Windows Heap API functions
 - refactor `allocate_with_flags` to `allocate` (and remove the other helper functions), which now takes just a `bool` if the memory should be zeroed
 - add checks for if `GetProcessHeap` returned null
 - add a test that checks if the size and alignment of a `Header` are indeed <= `MIN_ALIGN`
 - add `#![deny(unsafe_op_in_unsafe_fn)]` and the necessary unsafe blocks with safety comments

I feel like I may have overdone the documenting, the unsoundness fix is the most important part; I could spit this PR up in separate parts.
@carbotaniuman carbotaniuman deleted the unsafe_op_in_unsafe_fn branch April 20, 2022 15:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-cleanup Category: PRs that clean code up or issues documenting cleanup. F-unsafe-block-in-unsafe-fn RFC #2585 S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.