-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't call user callbacks on MsQuic worker thread. #98361
Don't call user callbacks on MsQuic worker thread. #98361
Conversation
Tagging subscribers to this area: @dotnet/ncl |
For now, one test keeps failing due to microsoft/msquic#4132. We'll have to wait until that issue is fixed and new MsQuic bits flow to all CI images (or disable the test meanwhile) |
src/libraries/System.Net.Quic/src/System/Net/Quic/Internal/MsQuicApi.NativeMethods.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicListener.cs
Outdated
Show resolved
Hide resolved
Would we need to bump minimal expected msquic version? If not how would we expect it to work with current versions? |
I would prefer to bump the minimum required version. But we can alternatively do a version check and do the work inline as we did until now. |
Just a reminder, that Alpine Arm32 is pinned on an older msquic version due to a regression microsoft/msquic#3958 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, small nits and one last question.
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnection.SslConnectionOptions.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnection.SslConnectionOptions.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnection.SslConnectionOptions.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnection.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicListener.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/QuicConnection.SslConnectionOptions.cs
Outdated
Show resolved
Hide resolved
I think the PR is ready for the final round of review. However, we need to figure out how to deal with microsoft/msquic#4132. Given that some images are pinned on an older version due to microsoft/msquic#3958, I think we should add a version check and do the async cert validation inline on older version (with minimal code changes), and later bump minimum required MsQuic version and remove the version check. |
👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
There are some CI failures that might be relevant though. |
This is the failure caused by microsoft/msquic#4132. Once microsoft/msquic#4145 is merged I can add a version check which will make the test pass again.
|
Then we need to either create an issue on updating the version check after MsQuic is updated (I think it's not just a matter of merging the PR, we need a new release, right?), and disable the test; or we need to put this PR into draft and "do-not-merge" to block until we can address it here. UPD: Ah, I see that "no merge" is already here; but the label is not checked as part of CI, and it's not easy to notice it 🙈 |
@rzikm I'll go ahead and mark it as draft while it's blocked -- so that it will not appear in the stale PRs list (and will not get accidentally merged) |
Co-authored-by: Marie Píchová <11718369+ManickaP@users.noreply.github.com>
52cc33b
to
9fdb790
Compare
microsoft/msquic#4132 was fixed, targeting 2.4 release, so I added version check to do the asynchronous validation only on 2.4 and higher. We can remove the version check once we update minimum required MsQuic version. |
|
Interesting, the test should not be failing because it should be still running inline. I can't even reproduce the failures on my machine with the same msquic versions as in the test runs |
Looks like the failure condition is still there even if we invoke the callback synchronously, so we need to return the result directly from the handler function. |
var task = _sslConnectionOptions.StartAsyncCertificateValidation((IntPtr)data.Certificate, (IntPtr)data.Chain); | ||
if (task.IsCompletedSuccessfully) | ||
{ | ||
return _sslConnectionOptions.ValidateCertificate((QUIC_BUFFER*)data.Certificate, (QUIC_BUFFER*)data.Chain, out _remoteCertificate); | ||
} | ||
catch (Exception ex) | ||
{ | ||
_connectedTcs.TrySetException(ex); | ||
return QUIC_STATUS_HANDSHAKE_FAILURE; | ||
return task.Result ? QUIC_STATUS_SUCCESS : QUIC_STATUS_BAD_CERTIFICATE; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
once we update to 2.4, we can remove the if
and change the StartAsyncCertificateValidation
to async void
.
{ | ||
wrapException = false; | ||
if (_isClient) | ||
{ | ||
throw new AuthenticationException(SR.net_quic_cert_custom_validation); | ||
} | ||
|
||
status = QUIC_STATUS_USER_CANCELED; | ||
result = QUIC_TLS_ALERT_CODES.BAD_CERTIFICATE; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we losing now the specific errors we were returning? Like discerning user_cancelled? Does it matter (affects the other side and what info they get), or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MsQuic does not use the specific error code value, it only checks for PENDING for async validation, SUCCESS for accept, and any error simply means reject.
With the async validation, we will actually be able to select the right TLS alert code which will go out over the wire, If the user validation callback throws, this will default to USER_CANCELLED as before, but if the callback returns false then it becomes BAD_CERTIFICATE. We can perhaps be more specific when no custom validation is present (there are alerts for stuff like UNTRUSTED_CERTIFICATE and similar) but I don't think we do that even in SslStream on some platforms.
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
CI Failures are known and unrelated |
Closes #98039.
This should also help with #55979, as previously the callbacks were delaying MsQuic threads which led to MsQuic thinking the workers were overloaded.