Determine and document the distinction between I/O safety and regular safety on unsafe stdlib APIs

[Manishearth]

Previously: rust-lang/rust#72175, rust-lang/rust#93562

The stdlib has a bunch of unsafe APIs (e.g. FromRawFd) that are primarily unsafe because they care about "I/O safety".

Rust libraries are free to expand the scope of what they consider unsafe, but this is typically a crate-local decision. The stdlib due to its special status risks imposing this on other crates.

Basically, if a crate or project wishes to not consider I/O safety a problem (which is often necessary in more complicated I/O code! Exactly the kind of code that would wish to use these APIs) these APIs are not useful to them: it is currently unclear as to what usages of these APIs are undefined behavior vs a violation of I/O safety.

There is a valid optimization that could be performed here in the future which would be to use niches for -1 fds on Unix (etc), so there is a potential for this API being Actually UB, but that's actually something that can be checked (unlike "is a real owned FD").

It would be nice if we could settle on what is Actually UB in these APIs, and what is "a violation of I/O safety", and document it.

cc @thomcc

[Manishearth]

The API that triggered this question is the following:

https://github.com/google/fleetspeak-rs/blob/d031cfc8ee07aa0670e0040d24ab99dd689e4124/crates/fleetspeak/src/lib.rs#L264-L282

(constructing a file from an fd from an env var. Reasonable to do for IPC cases, but a violation of the API requirements, currently.

[bjorn3]

Violating I/O safety can trigger UB. For example if you have some code that has a userfaultfd open and then some other code violates I/O safety to close the userfaultfd fd (eg by creating a File from it which is then dropped) will unmap the memory backed by the userfaultfd, resulting in UB on the next access.

[ChrisDenton]

I think "I/O safety" is a red herring here. It has nothing to do with the reasons that from_raw_fd is unsafe (see above). It has been unsafe a long long time before the term "I/O safety" was coined.

[Manishearth]

@bjorn3 Okay, but isn't that analogous to the /proc/mem/self issue? There are lots of weird things you can do with specific kinds of fds that are UB in Rust already.

[the8472]

Not quite, opening /proc/mem/self is reaching outside Rust.
Using from_raw_fd is passing something around inside Rust, into a type that has preconditions or from a type that says "you can use this Fd only for specific operations".
You can make up any RawFd you want, they're inert, like invalid pointers. To actually use them you need to access them, so converting a RawFd to some type that could cause any kinds of effects depending on what that Fd is. It might even be one that's already open and in use for memory-mapped stuff.

[Manishearth]

It might even be one that's already open and in use for memory-mapped stuff.

Right but ... I can do that by opening the memory-mapped file directly with safe File APIs, too. That's kinda what I'm getting at: we do not seem to have a principled approach to this, it seems strange to single this out as potentially creating undefined behavior.

The annoying thing here is not just that this method has preconditions, it has preconditions that cannot be checked.

[the8472]

You can hide your memory-mapped files, unlink them (on unix) or make the directory non-traversible if you're paranoid. But again, it's basically reaching out to a system that has insufficient sandboxing. The OS offers you footguns, we can't do anything about that without shutting down all IO. Inside Rust we do care.

[the8472]

it has preconditions that cannot be checked.

You kind of can if you're main. No other threads are running yet, only FDs 0,1,2 should be open. So anything else was explicitly passed from the parent and you can take ownership of it. Once you have a raw fd you can probe whether it is valid then use it.
That still leaves the uncheckable condition that nothing else on the system is using it, but that does fall under the "insufficiently paranoid OS" problem.

[thomcc]

Yeah, I was kind of opposed to codifying I/O safety as a type of safety for these reasons. It is subtle, as has been discussed here, because there is real UB that can occur if I/O safety is violated.

I agree that it's not great that we have APIs with preconditions that cannot be checked (in practice anyway -- being early main is not an option most of the time).

[Manishearth]

You kind of can if you're main

And then you need to worry about other crates doing stuff; which you can control by not using other crates but it's still an action-at-a-distance thing.

(And yeah, even if you whittle this down to "you only call trusted APIs before doing this", your dependencies are free to link in life-before-main C code)

Yeah, I was kind of opposed to codifying I/O safety as a type of safety for these reasons. It is subtle, as has been discussed here, because there is real UB that can occur if I/O safety is violated.

I think now that this can of worms has been opened we need to either fully specify it or decide it is an additional library invariant that callers are not required to follow; the status quo does not make much sense.

[the8472]

your dependencies are free to link in life-before-main C code)

Well sure, but C is never safe. We can't do anything about that. C programs would also break if other threads start mucking around with random file descriptors they don't semantically own.

[thomcc]

Yeah, I think I lean towards the "decide it is an additional library invariant that callers are not required to follow", but with a long list of caveats, which definitely do need to be worked though.

I think it's worth CCing @sunfishcode, who was the author of the RFC, to see if they have a more nuanced take here, I suspect that they will.

[ChrisDenton]

Note that to the extent that "I/O safety" is documented, it's documented here: https://doc.rust-lang.org/std/os/unix/io/index.html

One problem with file_from_env_var is that it allows creating two std::fs::Files from the same fd, with both expecting to have exclusive access (e.g. they close on drop).

[Manishearth]

with both expecting to have exclusive access (e.g. they close on drop).

That's still a library invariant though, not UB

[the8472]

AsRawFd is safe, a Mmap type can implement it and it would be doing nothing wrong. Now you have a RawFd. This is analogous to vec.as_mut_ptr(). Both of them are inert. The UB only happens when you pass it to something else that does things with them they shouldn't. That's why that is unsafe.

We could have put the unsafe on the extraction instead. But neither did we do that for raw pointers.

The only difference is that there are some Fds which are harmless to use with some syscalls. But I guess you could do the same with pointers, like calling madvise on them or something.