Use futex-based synchronization on Apple platforms

[joboet]

Last week, Apple released macOS version 14.4, which introduced a public futex API called os_sync_wait_on_address (Apple has failed to include the documentation provided in the defining header os/os_sync_wait_on_address.h on its website). As the private API backing these functions has been around since macOS 10.12, our minimum supported version, it can be used as fallback without risking breakage in future versions.

This PR thus switches over Mutex to os_unfair_lock, which is movable and supports priority inheritance, and all other synchronization primitives (Condvar, RwLock, Once and thread parking) to the futex-based ones also used on Linux and Windows.

TODO: implement miri shims

[rustbot]

r? @m-ou-se

rustbot has assigned @m-ou-se.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[BlackHoleFox]

Mind explaining more what the thought process of these going undetected is? Seems like a risky chance that might require a hot fix if the MAS or iOS app store scanners see through this.

In reality I think this won't be enough and we need to call ulock things via syscall directly instead. This means that the "fallback" Apple futex implementation is only going to be usable on macOS.

I know Electron apps on the MAS use direct syscalls to emulate private functions, so this is probably what Rust should do too on macOS with precedence:

#define	SYS_ulock_wait     515
#define	SYS_ulock_wake     516
#define	SYS_ulock_wait2    544

For iOS, detect if the os_sync_ functions are available or fallback to the non-futex implementation :/ Calling a syscall directly is forbidden per the iOS headers so std can't do the same as macOS:

__WATCHOS_PROHIBITED __TVOS_PROHIBITED
__OS_AVAILABILITY_MSG(ios,deprecated=10.0,"syscall(2) is unsupported; "
    "please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost().")
__OS_AVAILABILITY_MSG(macosx,deprecated=10.12,"syscall(2) is unsupported; "
    "please switch to a supported interface. For SYS_kdebug_trace use kdebug_signpost().")
int	 syscall(int, ...);

[joboet]

This is a "spirit of the law" kind of situation. Apple understandably wants App Store software to continue working in newer versions, so they prohibit private API use, as they want to be able to remove or change that API at will. By only using the private API as fallback and not linking it directly, we fulfil this wish. If we directly linked the private API instead, we'd get dynamic linker errors if they remove it, so we can't do that.

On the other hand, we break the "letter of the law" as we are using private API. In my opinion, this is totally fine and justified, but of course, this is only my interpretation. It would be great if someone from Apple could look over this, just so that we know that they are aware of this. My past attempt at reaching out to them for this has been unsuccessful.

[Berrysoft]

Would you consider the solution of atomic-wait? They use libc++.

https://github.com/m-ou-se/atomic-wait/blob/main/src/macos.rs

[joboet]

But these only exist starting with macOS 11, which is way above our minimum of 10.12, so the ulock fallback would be needed regardless.

[madsmtm]

This sets precedent for using private APIs in the standard library (our current use of weak! is only used for symbols that are available in newer versions), which I think is a fairly big deal, and should perhaps be discussed more broadly (in a separate issue? (that could be FCP'ed?)).

Somewhat related is #114186. Tagging in particular @thomcc and @workingjubilee, as they seem to have been involved in this kind of stuff before?

---

At the very least, we should use the dlsym! macro explicitly here, to make it very clear that we're not weakly linking the symbol (which would be very visible in the binary), but actually loading it at runtime, and thereby evading the App Store's checks (dlsym itself seems to be allowed).

I believe this is sufficient such that we do not need to do raw syscalls (which I remember to have caused problems for Go in the past since as the ABI isn't stable (?)).

[thomcc]

Yeah, we shouldn't be calling this directly, it'll trip the app store static analysis.

[BlackHoleFox]

These panics also get to be deleted if raw syscalls are used :)

[madsmtm]

If we do keep the panics, I'd go for an abort here instead, this is not recoverable in any way and avoiding the overhead from unwind landing pads would be nice.

[bors]

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

[madsmtm]

In general, nice work, this will be a great perf improvement!

I know it is a draft, but once you're ready, it'd be nice to split the Mutex changes apart from the futex changes, if possible.

@rustbot label O-apple

[madsmtm]

Please use target_vendor = "apple", as that also includes visionOS. Also applies elsewhere.

[madsmtm]

movable

Could you provide some documentation for this claim? The comment on os_unfair_lock states:

In Swift, note that use of the & operator on an unfair lock can copy or move the lock memory, leading to misbehavior. Use an OSAllocatedUnfairLock to safely wrap access to the lock memory instead. If you use os_unfair_lock APIs directly, always make sure to store and use the lock in memory with a stable address.

Which seems to hint at the lock not being movable? Or am I misunderstanding?

[madsmtm]

I found rust-lang/miri#3859, rust-lang/miri#3745 (comment) and rust-lang/miri#3745 (comment), but is any of that documented, and can it be relied on?

Also discussed in #131005.

[RalfJung]

If std plans to actually move macOS locks then Miri should probably properly emulate whatever the macOS behavior is there -- but absent any documentation, it seems dubious to rely on them being movable? (Even more so if not even Swift relies on them being movable.)

[BlackHoleFox]

I'm pretty sure they are movable. You initialize the lock with a constant #DEFINE and the size of the lock isn't even large enough to store a pointer, so all the operations just read/write into the 32 bits available. There are no init/deinit operations either. Based on the header, seems like the time it cares about the address is when you've locked it.

[RalfJung]

The issue is that safe Rust can move a lock while it is held:

use std::mem;
use std::sync::Mutex;

fn main() {
    let m = Mutex::new(0);
    mem::forget(m.lock());
    // Move the lock while it is "held" (really: leaked)
    let m2 = m;
    // Now try to acquire the lock again.
    let _guard = m2.lock();
}

We better be sure that this deadlocks (and will deadlock in all future macOS versions) before committing to this implementation strategy.

[madsmtm]

I'd also link the design/decision document:
https://github.com/apple-oss-distributions/libplatform/blob/libplatform-316.100.10/docs/expose-futex-style-api.md

[madsmtm]

Hmm, are you sure this is correct? The implementation of os_sync_wake_by_address_any seems to just call __ulock_wake without a loop? So either we need to loop both places, or in none of them?

Same goes for futex_wake.

[the8472]

We discussed this during today's T-libs meeting (albeit with low attendance). We might be willing to go along with the changes on the theory that apps are validated on current OS versions and will use current stable APIs and so shouldn't cause issues and that the fallback APIs have been available for a long time and so won't suddenly disappear on older versions.

But in previous cases where we've started to rely on internal APIs we've leaned on platform experts and their investigations how risky that would be. So we'd like to do the same here. @rustbot ping apple

[rustbot]

Hey Apple notification group! This issue or PR could use some Apple-specific
guidance. Could one of you weigh in? Thanks <3

(In case it's useful, here are some instructions for tackling these sorts of
issues).

cc @BlackHoleFox @hkratz @inflation @madsmtm @nvzqz @shepmaster @thomcc

[the8472]

This sets precedent for using private APIs in the standard library (our current use of weak! is only used for symbols that are available in newer versions), which I think is a fairly big deal, and should perhaps be discussed more broadly (in a separate issue? (that could be FCP'ed?)).

We do use internal APIs on windows (NtCreateFile), but that became necessary to fix a CVE and was used after looking at the microsoft ecosystem official projects. And windows is a more open platform in a way (hah) since they don't review most software. So it's not fully comparable.

[madsmtm]

on the theory that apps are validated on current OS versions and will use current stable APIs and so shouldn't cause issues and that the fallback APIs have been available for a long time and so won't suddenly disappear on older versions.

Just to be clear, the problematic API here is not so much the newly added APIs (os_sync_wait_on_address etc.), but the fallback implementation for older OS'es (__ulock_wait) that might trip Apple's analysis, and make it very hard for Rust users to submit their application to the App Store.

---

It would be nice if someone could try to submit an application for review in the App Store that uses this branch of rustc, and see if Apple's review picks up on the usage of __ulock_wait via. dlsym or not, that would appease most of my worries here.

[ruihe774]

A blog from firefox states that os_unfair_lock has poor performance: https://hacks.mozilla.org/2022/10/improving-firefox-responsiveness-on-macos/

Is it still true?

(I do not deny that os_unfair_lock is better than current pthread implementation.)