UNIX thread safety check exemptions may not be sound about time

[jhpratt]

Agreed. macOS 12 looks like it was released just two years ago and is still maintained, so it's unquestionably a recent enough version to care about. Let's remove the exception.

[thomcc]

It's probably not sound on other unix either unless the hold this lock for the duration of the use of the pointers returned by getenv. E.g.

// inside getenv call
acquire_lock();
char *p = real_getenv();
release_lock();
// outside
use(p);

So just taking a lock around the duration of getenv/setenv is insufficient. It would need to be around the duration of whatever calls you're making into libc (or at least more of it than just getenv/setenv).

[jhpratt]

I'm not sure I understand what you're referring to — time doesn't use a lock for any of this. The only lock present is that in std, and the fact that it can't be relied upon is the underlying issue.

Specifically, there doesn't need to be a lock if

• the OS has thread-safe environment variables (which is this issue and at least one other)
• or the process is single-threaded.

The reason for the second is that it's inherently guaranteed that no one else can mutate the environment if there's no other code running.

[thomcc]

My point is that the internals of getenv/setenv taking a lock is insufficient for an OS to have a thread-safe environment.

[jhpratt]

Ah, I see what you're saying. For illumos, thread safety is ensured by the fact that setting env vars leaks memory. I believe the same is true for NetBSD, though I don't have time to check at the moment.

[thomcc]

Yeah, technically even that's not enough, assuming they only only leak on growth. In non-growth cases you'd still have a data race (as mentioned above by @BlackHoleFox), but it's probably fine in practice.

[jhpratt]

For clarity, it's the combination of leaking and locks.

it's probably fine in practice

I would have said that about the initial unsoundness. Even having the calls in a tight loop, it takes a couple seconds (tens of thousands of iterations) before anything happens. Even without the checks in place, it's very unlikely that unsoundness occurs. But apparently the original report was in fact found in the wild, not someone fuzzing. With that said, I have not the slightest clue what they were doing that would get anywhere near this.

Overall, as far as I am aware the current exemptions are sound. I only have access to my personal Linux machine (plus a Linux SSH machine from the Rust Foundation), so I am unable to verify any other OS. If someone wants to run the reproducer, they are free to do so and file an issue if it fails.

[thomcc]

A data race like that likely wouldn't show up in a a reproducer, unless you compiled libc and the rust code with a data race detector (like thread sanitizer).

[jhpratt]

That is true. Regardless, anyone is free to file an issue if they find that an exemption is wrong, regardless of how that's discovered.