Repository navigation
Tracking Issue for RFC 3128: I/O Safety #87074
Description
Feature gate: #![feature(io_safety)]
This is a tracking issue for RFC 3128: I/O Safety.
Raw OS handles such as RawFd and RawHandle have hazards similar to raw pointers; they may be bogus or may dangle, leading to broken encapsulation boundaries and code whose behavior is impossible to bound in general.
Introduce a concept of I/O safety, and introduce a new set of types and traits, led by OwnedFd and BorrowedFd, to support it.
Public API
The public API on UNIX platforms consists of the types OwnedFd and BorrowedFd, the trait AsFd, and implementations of AsFd, Into<OwnedFd>, and From<OwnedFd> for various types (such as files and sockets).
The public API on Windows platforms consists of two sets of parallel types and traits and impls for OwnedHandle, OwnedSocket, BorrowedHandle, BorrowedSocket, etc.
Steps / History
- Implementation (based on @sunfishcode's existing work outside of std)
- Final comment period (FCP)
- Because these include a new stable layout guarantee (Add rustc_nonnull_optimization_guaranteed to Owned/Borrowed Fd/Socket #96947), this should include T-lang (https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/rustc_nonnull_optimization_guaranteed.20oversight.3F)
- Stabilization PR
Unresolved Questions
- This RFC doesn't define a formal model for raw handle ownership and lifetimes. The rules for raw handles in this RFC are vague about their identity. What does it mean for a resource lifetime to be associated with a handle if the handle is just an integer type? Do all integer types with the same value share that association?
- The Rust reference defines undefined behavior for memory in terms of LLVM's pointer aliasing rules; I/O could conceivably need a similar concept of handle aliasing rules. This doesn't seem necessary for present practical needs, but it could be explored in the future.
Activity
sunfishcode commentedon Jul 21, 2021
I've now posted an initial PR implementing the proposal in the RFC: #87329
Assert validity on the raw socket in SockRef::from
Assert validity on the raw socket in SockRef::from
Assert validity on the raw socket in SockRef::from
Assert validity on the raw socket in SockRef::from
129 remaining items
sunfishcode commentedon Jun 7, 2022
I'm having difficulty translating these into specific areas in the documentation that could be modified, and specific points to make. Would anyone be able to suggest wording here?
I'm not aware of any system calls which behave like this. Does anyone have specific examples of this?
the8472 commentedon Jun 7, 2022
https://lore.kernel.org/lkml/1276525077-26347-1-git-send-email-tytso@mit.edu/
The ioctl 2 has different meanings for regular files and some character device drivers. That was about a kernel bug where the kernel misinterpreted it, but they fixed that which still means that it can cause different behavior (or error out because the ioctl is not supported) depending on what file descriptor you call it on.
sunfishcode commentedon Jun 8, 2022
APIs for
ioctls that have multiple meanings, where it's possible to get Undefined Behavior when the wrong meaning is invoked, should either useunsafeorfstatto ensure that they only operate on the types of descriptors they expect.From<OwnedFd>does not put any conditions on the types of file descriptors it can accept. To be sound, users ofFrom<OwnedFd>must not permit undefined behavior for any possible file descriptor type.sunfishcode commentedon Jun 9, 2022
The 2 remaining items in the Steps / History at the top are completed:
#[feature(io_safety)]. #95118The 2 Unresolved Questions are questions are questions for the future, and not questions that I expect need to be answered for this feature to proceed.
Implement stabilization of `#[feature(io_safety)]`.
Rollup merge of rust-lang#95118 - sunfishcode:sunfishcode/stabilize-i…
Rollup merge of rust-lang#95118 - sunfishcode:sunfishcode/stabilize-i…
sunfishcode commentedon Jun 22, 2022
Thanks to @RalfJung for helping me understand this space and @joshtriplett for mentoring and reviews, and many others for discussions and comments that helped shape this.
For the next chapter in the I/O safety story: once this feature reaches stable, the next step is to begin adding trait implementations for
AsFdetc. for types in popular crates, to pave the way for a gradual migration. I've filed a planning issue here with the full plan:sunfishcode/io-lifetimes#38
Migrate from libc to rustix.
Migrate from libc to rustix.
Migrate from libc to rustix.
Auto merge of #96195 - sunfishcode:sunfishcode/handle-or-error-type, …