WASM error handling in SubtleCrypto through web worker

@radical

The work to enable WASM to use SubtleCrypto, #65966, had some follow ups on how to handle error cases. Specifically, the communication channel with the web worker could be hardened to convey more errors/failures. This could be accomplished through throwing an exception or the web worker communicating a failure case explicitly.

Source hints:

crypto-worker.ts
- see read_response and consider throwing an error.
dotnet-crypto-worker.js
- The reading in of a request could be including in the try/catch in await_request.
- The await_request function could return a bespoke "error occurred" message instead of an exception string.

See #69741

/cc @radical @ericstj @layomia

Another suggestion would be for the tests to confirm when running on browser that it did actually use the worker implementation.

Another suggestion would be for the tests to confirm when running on browser that it did actually use the worker implementation.

I think this is being done. See src/tests/BuildWasmApps/Wasm.Build.Tests/NativeLibraryTests.cs. There is a check for console output. I commented on this in the JavaScript file.

I think this is being done. See src/tests/BuildWasmApps/Wasm.Build.Tests/NativeLibraryTests.cs. There is a check for console output. I commented on this in the JavaScript file.

Yes, but the xharness webserver is setup in two different places for Wasm.Build.Tests, and the library tests. I was just suggesting that we add some kinda confirmation for the library tests also, so it doesn't accidentally start using the fallback, and we don't find out.

Note: when fixing this, we also need to ensure that the "lock" added in #70185 is cleared on error.

Better error handling in SubtleCrypto workers

Better error handling in SubtleCrypto workers (#71693)

What is left to do here?

@eerhardt

I think this is being done. See src/tests/BuildWasmApps/Wasm.Build.Tests/NativeLibraryTests.cs. There is a check for console output. I commented on this in the JavaScript file.

Yes, but the xharness webserver is setup in two different places for Wasm.Build.Tests, and the library tests. I was just suggesting that we add some kinda confirmation for the library tests also, so it doesn't accidentally start using the fallback, and we don't find out.

Only this, if @eerhardt thinks we should do it.

@radical

that we add some kinda confirmation for the library tests

@radical - do you know how we would do this in the libraries tests?

@radical

@radical - do you know how we would do this in the libraries tests?

One simple check would be to call Interop.BrowserCrypto.CanUseSubtleCrypto via reflection, and compare it against an environment variable which indicates whether we are expecting to use subtlecrypto. We can do this as:

Add a separate test that does this
Or do this is all the relevant test class' .ctor . This would catch the case where some tests do use subtlecrypto, then one causes an error, and the subsequent tests would end up using the managed implementation. This can work because, once we hit an error which disables the use of subtlecrypto, Interop.BrowserCrypto.CanUseSubtleCrypto should return false.

runtime/src/mono/wasm/runtime/crypto-worker.ts

Lines 120 to 123 in ed2a5a1

    
           worker.onerror = event => { 
        
               console.warn(`MONO_WASM: Error in Crypto WebWorker. Cryptography digest calls will fallback to managed implementation. Error: ${event.message}`); 
        
               mono_wasm_crypto = null; 
        
           };

This can work because, once we hit an error which disables the use of subtlecrypto, Interop.BrowserCrypto.CanUseSubtleCrypto should return false.

This is actually a problem in the current code, because of the following C# code:

runtime/src/libraries/Common/src/Interop/Browser/System.Security.Cryptography.Native.Browser/Interop.SubtleCrypto.cs

Line 21 in 8f75cc9

    
           internal static readonly bool CanUseSubtleCrypto = CanUseSubtleCryptoImpl() == 1;

This only gets called once, and then cached in the field. So if an error happens subsequently, we don't P/Invoke back into JS code to see if mono_wasm_crypto is null or not.

How fast is the P/Invokes in WASM? Should this CanUseSubtleCrypto always call into the JS code every time it is invoked?

This can work because, once we hit an error which disables the use of subtlecrypto, Interop.BrowserCrypto.CanUseSubtleCrypto should return false.

I dunno. I think (in all sincerity) we should just let all crypto operations blow up.

Add a test that ensures we are using SubtleCrypto in WASM crypto tests

Navigation Menu

Repository navigation

WASM error handling in SubtleCrypto through web worker #69740

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	worker.onerror = event => {
	console.warn(`MONO_WASM: Error in Crypto WebWorker. Cryptography digest calls will fallback to managed implementation. Error: ${event.message}`);
	mono_wasm_crypto = null;
	};

WASM error handling in SubtleCrypto through web worker #69740

Description

Activity

radical commented on May 24, 2022

AaronRobinsonMSFT commented on May 24, 2022

radical commented on May 24, 2022

eerhardt commented on Jun 7, 2022

lewing commented on Jul 25, 2022

radical commented on Jul 25, 2022

eerhardt commented on Jul 26, 2022

radical commented on Jul 26, 2022

eerhardt commented on Jul 26, 2022

bartonjs commented on Jul 26, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions