1901295 - [meta] Fast UDP for Firefox - basic end-to-end integration (single-packet)

Status: RESOLVED FIXED

(Core :: Networking, task, P2)

Comment 1

[Max Inden]

Attachment: Bug 1901295 - Use quinn-udp instead of NSPR for QUIC UDP I/O r=kershaw,jesup

Comment 2

[Kershaw Chang [:kershaw]]

As the try run including this patch shows, this test fails because we disallow the use of networking functions from Rust. Unfortunately, this test failure has become a blocker for this project.

As @glandium mentioned, there seems to be no way to add neqo-udp to an exception list, so the only way forward seems to be to skip that test.

Since Tom, who originally introduced this check in bug 1376621, is on PTO, Freddy, do you know who can help?
Thanks.

Comment 3

[Frederik Braun [:freddy]]

Well, this is the first time I hear of this check. I am trying to find someone who can help find out.

Btw, how do you currently make neqo-udp proxy safe?

Comment 4

[Kershaw Chang [:kershaw]]

(In reply to Frederik Braun [:freddy] from comment #3)

Well, this is the first time I hear of this check. I am trying to find someone who can help find out.

Btw, how do you currently make neqo-udp proxy safe?

See the code here.
Currently, when proxy is used, we disable HTTP/3.

Comment 5

[Simon Friedberger (:simonf)]

I've asked in #tor-dev on OFTC and they do their own checks and also have a script for supporting audits here: https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/main/audits/code_audit.sh

IIUC getsockopt and getsockname don't even do any actual networking Tom just added them because they might suggest networking code (networking wizards, please correct me!).

So, go ahead and remove those from https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/action/check_binary.py#216

We still have https://bugzilla.mozilla.org/show_bug.cgi?id=1620045 open for follow-up work.

And just to clarify :kershaw, we're still disabling all of this when a proxy is used?

Comment 6

[Kershaw Chang [:kershaw]]

(In reply to Simon Friedberger (:simonf) from comment #5)

I've asked in #tor-dev on OFTC and they do their own checks and also have a script for supporting audits here: https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/main/audits/code_audit.sh

IIUC getsockopt and getsockname don't even do any actual networking Tom just added them because they might suggest networking code (networking wizards, please correct me!).

So, go ahead and remove those from https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/action/check_binary.py#216

Thanks for the clarification. I'll file another bug to remove getsockopt and getsockname.

We still have https://bugzilla.mozilla.org/show_bug.cgi?id=1620045 open for follow-up work.

And just to clarify :kershaw, we're still disabling all of this when a proxy is used?

Yes, correct. We currently disallow HTTP/3 when a proxy is used.

Comment 7

[Max Inden]

Thank you Frederik, Simon and Kershaw!

I have temporarily removed getsockname and getsockopt from check_binary.py in https://phabricator.services.mozilla.com/D212959. The check succeeds.

I'll file another bug to remove getsockopt and getsockname.

I am happy to extract the changes into a separate patch.

Comment 8

[Max Inden]

I submitted https://bugzilla.mozilla.org/show_bug.cgi?id=1903621 and https://phabricator.services.mozilla.com/D214291.

Comment 9

[Max Inden]

@petr following up on https://bugzilla.mozilla.org/show_bug.cgi?id=1898185. As part of this project quinn-udp will be used in Firefox itself. Thus simply disabling http3server on Solaris won't work once merged.

Do you have the capacity to work on an upstream fix, i.e. adding Solaris support to quinn-udp? This is tracked in https://github.com/quinn-rs/quinn/issues/1877.

I would assume, at least for a minimal fallback mode, that this won't involve much work.

Comment 10

[Petr Sumbera]

Ok, I thought that you finally will not use quinn-udp. I will have to look at it again. What is blocking me is:
https://github.com/rust-lang/libc/pull/3717
(any idea why simple pull request isn't getting anywhere?)

Comment 11

[Max Inden]

Ok, I thought that you finally will not use quinn-udp.

Sorry for the confusion Petr. We will continue using quinn-udp. The confusion likely stems from the discussion in https://github.com/quinn-rs/quinn/issues/1749. I posted a clarification comment there. See https://github.com/quinn-rs/quinn/issues/1749#issuecomment-2211004631.

(any idea why simple pull request isn't getting anywhere?)

I am not sure. Let's see whether someone follows up after your recent ping. Vendoring in quinn-udp for now, as proposed here sounds like a good intermediate plan.

Comment 12

[Max Inden]

Attachment: WIP: Bug 1901295 - introduce network.http.http3.use_nspr_for_io pref

Boolean about:config pref, whether to use NSPR or quinn-udp. NSPR by default.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9668b5b82c9d
Use quinn-udp instead of NSPR for QUIC UDP I/O r=necko-reviewers,jesup,supply-chain-reviewers,kershaw

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/9668b5b82c9d

Comment 15

[Max Inden]

Attachment: Bug 1901295 - use quinn-udp instead of NSPR for QUIC I/O on Nightly r=kershaw

https://phabricator.services.mozilla.com/D212959 adds optional support for QUIC
I/O via quinn-udp instead of NSPR. This is controlled via pref
network.http.http3.use_nspr_for_io. The default pref value was true, thus
not using quinn-udp, but NSPR as before.

This commit enables the use of quinn-udp on Firefox Nightly.

Comment 16

[Phabricator Automation]

Comment on attachment 9416315 [details]
Bug 1901295 - use quinn-udp instead of NSPR for QUIC I/O on Nightly r=kershaw

Revision D217830 was moved to bug 1910360. Setting attachment 9416315 [details] to obsolete.

Comment 17

[Max Inden]

Attachment: Bug 1901295 - allow sendmsg and recvmmsg in SocketProcessSandboxPolicy r=kershaw

https://bugzilla.mozilla.org/show_bug.cgi?id=1901295 introduced optional
HTTP3/QUIC UDP IO via quinn-udp instead of NSPR, see
network.http.http3.use_nspr_for_io pref. NSPR uses sendto and recvfrom
syscall, quinn-udp uses sendmsg and recvmmsg syscall.

With network.http.network_access_on_socket_process.enabled true and
network.http.http3.use_nspr_for_io false Firefox panics due to seccomp
disallowing a recvmmsg syscall.

This commit allows sendmsg and recvmmsg in the SocketProcessSandboxPolicy
EvaluateSocketCall function.

Comment 18

[Phabricator Automation]

Comment on attachment 9419001 [details]
Bug 1901295 - allow sendmsg and recvmmsg in SocketProcessSandboxPolicy r=kershaw

Revision D219110 was moved to bug 1912626. Setting attachment 9419001 [details] to obsolete.