Why tokio::io::unix::AsyncFd::new is safe?

[vi]

tokio::fs::File::from_raw_fd is unsafe, but tokio::io::unix::AsyncFd::new is safe.

Is it intentional or an oversight? It may be safe because of just polling around isn't expected to affect file descriptors too much. It may be unsafe because of typically things that allow specifying arbitrary file descriptor number are unsafe.

Either way safety should somehow be mentioned in documentation.

[Darksonn]

There was some discussion of this here: #2728 (comment)

I don't think it needs to be unsafe. I don't believe there is any actual unsafety w.r.t working with an FD. I believe it is left over from early rust days when "unsafe" was used for things that were not strictly memory unsafe.

[hgomersall]

On this point, my current understanding is unsafe is more about undefined behaviour than memory safety per se. I raised this on reddit and the replies were quite informative.

[Darksonn]

Yes, but the point is that, in the past, unsafe was used for things that had defined behavior, but was dangerous. See e.g. the forget function. You will notice that I am one of the people who replied to that reddit post.

[hgomersall]

Yes you did, and it was an excellent reply! My point was less for you and more for other readers of this question (the quote from #2728 sort of implies that unsafe is only about memory safety).

[vi]

unsafe is also needed for things breaking invariants that other unsafe code assumes, including invariant about operating system (and maybe important C function) behaviour. That's why fork analogue in std was also made unsafe (although initially it was safe).

There are mutually exclusive things (especially relying on some global resource implemented in C) that are safe in isolation, but are unsound when used together. It may be the source of many "needless" unsafes.

[vi]

left over from early rust days when "unsafe" was used for things that were not strictly memory unsafe.

I expected that Rust standard library (and maybe custom libraries) relies on OS behaving sane, with memory safety at stake

(e.g. using UNIX socket for synchronisation - receive cannot happen before send). Or using memory-mapped files internally.

FromRawFd allows accessing those "private" file descriptors. Either all file descriptors-based things should be considered untrustworthy and ineligible to be used for protecting safety (e.g. we cannot pass memory addresses over local sockets) or file descriptors are part of "safety zone" and certain operations regarding them should be marked unsafe, but we can rely that e.g. a socketpair we created stays as a socket pair at the end of the day, not being randomly replaced by something else entirely.

[MikailBag]

@vi I think this is a kind of grey zone (and also rabbit hole).

For example, you can do File::create("/proc/self/fd/42").write("hi there") to write any data to any fd.

In general, any interaction with OS can lead to OS or other processes breaking our process in arbitrary way. For example imagine that user has following "program" running in background:

loop {
    if let Some(p) = find_process_by_author(vi) {
       let mem = open_process_memory(p);
       for _ in 0..1000 {
            mem[rand()] = rand();
       }
    }
}

It seems that rust spec should contain some list of assumptions that the environment is not too cruel (CPU doesn't have bugs, OS returns nonoverlapping chunks of memory in response to mmap, nobody will break our FDs and so on) to us and state that otherwise program behavior is undefined.

[carllerche]

I'm not sure why AsyncFd::new and File::from_raw_fd are being compared, they are completely different types. AsyncFd decorates a type that has an FD. It does not take ownership of the Fd. File owns an Fd and is implemented in a way that assumes that.

[vi]

Imagine a third-party library providing a safe wrapper to some tricky vendor-specific type of a file descriptor. It provides safe AsRawFd, allowing users to use raw FFI for unimplemented things.

But kernel implementation (also vendor-specific and unupstreamed) of polling such file descriptors is buggy and causes information passed to or from that FD being distorted (e.g. they tried to implement poll/select support, but never really gotten it to work, so they just left the half-baked thing there for better times). And the kernel module also deals with memory mappings and hardware IO (with memory addresses passed though read/write to special file descriptor).

The wrapper library carefully tries to work around (using strategic sleeps and so on) all the kernel bugs to make semblance of something safe-ish, but adding another syscall (epoll) to the mix completely throws it off the rails. It prefers that private fragile FD to be really private.

[carllerche]

That would be a question for mio. I also don't think mio would attempt to support such a buggy kernel.

[vi]

mio supports Linux. Linux can have third-party kernel modules. Third-party kernel modules can be buggy, requiring a wrapper to make it sane.

I don't mean that AsyncFd should be unsafe, but something may be mentioned in documentation.

[MikailBag]

But there can be another bug in a third-party kernel: e.g. with some probability write syscall corrupts 5 random bytes in the process memory. Should File::write be marked unsafe?

[hgomersall]

Given syscalls can do literally anything, it seems pretty much impossible to ever guarantee safety when interacting with an OS if we don't trust the OS to be safe. IMO the unsafe boundary is at the point the syscall is made and the contract is imposed by the OS. The requirement for the rust to be safe, therefore, is that it enforces that OS contract through safe code. The corollary to that is if the OS imposes a contract on the caller, and that contract is exposed through the API without enforcement then it should be marked unsafe.

For the most part, this is not an issue. Assuming the OS is not buggy, most syscalls are safe. Buggy code is a potential problem, but no different in principle to any other buggy code one needs to interact with. The place it gets tricky is when a driver exposes potentially dangerous interactions. I'm doing some development now on a UIO driver written in rust in which there are plenty of ways to cause undefined behaviour at the OS level, with no bugs involved (really, in my case, this highlights the fearsome security pit which is an FPGA on the system bus).