feat(quinn-udp): add opt-in Apple fast UDP datapath

[larseggert]

Add runtime dispatch between Apple's private sendmsg_x/recvmsg_x APIs (fast path) and standard sendmsg/recvmsg (slow path). The fast path is disabled by default and must be explicitly enabled by callers.

These private APIs may crash on unsupported OS versions, so callers must verify availability before enabling. A C ABI function is provided for embedders (e.g., Firefox) to enable the fast path after probing externally.

Key changes:

• Add set_apple_fast_path_available() to enable fast path at runtime
• Add C ABI quinn_udp_set_apple_fast_path_available() for FFI callers
• Split send/recv into fast path (send_via_sendmsg_x, recv_via_recvmsg_x)
  and slow path (send_single, recv_single) variants
• Add prepare_msg_x/prepare_recv_x for msghdr_x preparation
• Update gso::max_gso_segments() to return 1 when fast path is disabled

[larseggert]

@mxinden thinking about this some more, I wonder if we need to pass in the sockets from Gecko (due to Rust code limitations around socket creation), or if we should even do this probe entirely in Gecko and simply runtime-configure which Apple datapath quinn-udp should use?

[djc]

(due to Rust code limitations around socket creation)

What do you mean?

[djc]

I think each of this should be a separate commit:

• Extract decode_cmsg helper to reduce duplication in recv decoding
• Make decode_recv generic over MsgHdr trait

It probably also makes sense to split some of this out:

• Split fast path (send_via_sendmsg_x/recv_via_recvmsg_x) from slow path (send_single/recv_single) for runtime dispatch

[larseggert]

(due to Rust code limitations around socket creation)

What do you mean?

Gecko is sandboxing all Rust code (and other third-party code) so it cannot open sockets.

[larseggert]

@djc I'll do some refactoring on this next week per your suggestions.

[larseggert]

Gecko is sandboxing all Rust code (and other third-party code) so it cannot open sockets.

FWIW, I just build Firefox with this PR and it does run (and detect the fast Apple datapath after the probe), so something has changed related to the sandbox 🎉

[mxinden]

Concerning the usage of quinn-udp in Firefox only:

Gecko is sandboxing all Rust code (and other third-party code) so it cannot open sockets.

FWIW, I just build Firefox with this PR and it does run (and detect the fast Apple datapath after the probe), so something has changed related to the sandbox 🎉

Referencing a discussion out-of-band. The "sandboxing" is happening at compile time.

https://github.com/mozilla-firefox/firefox/blob/43c97a062976252bce5968555060136810099ac2/python/mozbuild/mozbuild/action/check_binary.py#L209-L278

There is also the runtime sandboxing of the process. Though as far as I am aware, that isn't enabled by default.

https://github.com/mozilla-firefox/firefox/blob/main/security/sandbox/linux/SandboxFilter.cpp

[larseggert]

ACK. I will revamp this once back from vacation.

[Ralith]

These APIs may crash on unsupported OS versions

What sort of crash, specifically? I hope we're not invoking UB or risking a collision with application signal handlers or something.

[larseggert]

The concern is that Apple would eliminate or change the signature of the syscalls.

[Ralith]

That would make a call UB, right? Can we rely on the exit code we get from the subprocess in that case?

[larseggert]

I'll investigate if we can move the probe function into neqo/Gecko, and instead have some sort of flag in quinn for whether the fast datapath should be used. Marking this PR as draft until then.

[larseggert]

OK, I revamped this and moved the entire logic for deciding whether the fast datapath should be used out of quinn-udp.

[larseggert]

@mxinden please check the current revision.