-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
Convert our CryptoKit bindings to use Swift structs at the boundary #102583
Conversation
Also refactor our cryptokit bindings to reduce duplication.
Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones |
src/libraries/Common/src/Interop/OSX/Swift.Runtime/UnsafeBufferPointer.cs
Show resolved
Hide resolved
src/libraries/Common/src/Interop/OSX/System.Security.Cryptography.Native.Apple/Interop.Aead.cs
Outdated
Show resolved
Hide resolved
src/libraries/Common/src/Interop/OSX/System.Security.Cryptography.Native.Apple/Interop.Aead.cs
Outdated
Show resolved
Hide resolved
src/native/libs/System.Security.Cryptography.Native.Apple/entrypoints.c
Outdated
Show resolved
Hide resolved
src/libraries/Common/src/Interop/OSX/System.Security.Cryptography.Native.Apple/Interop.Aead.cs
Outdated
Show resolved
Hide resolved
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.
While I can see that the protocols and extensions do de-duplicate some code I feel like it has impacted the straight forwardness of what was there before. If the eventual end-game is to get rid of these bindings and just go straight to CryptoKit, I am not sure what this buys us since CryptoKit does not have a protocol between ChaCha and AES-GCM.
I don”t feel intensely strong either way about this, but I am curious what others think, or if there is a benefit I am overlooking.
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.
As I was making the changes, it was easier to (at least in the first pass) deduplicate. I can split it back out now that I've converted everything to the new shapes.
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.
Since we plan to deprecate this wrapper soon, I believe it is not necessary to revert the changes. My perspective is that for security-related use cases like this one, we should avoid adding layers that are not provided by design, as they may introduce complexity and lead to unintended usage patterns.
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!
src/libraries/Common/src/Interop/OSX/System.Security.Cryptography.Native.Apple/Interop.Aead.cs
Show resolved
Hide resolved
…ome assert for some reason I can't figure out.
src/native/libs/System.Security.Cryptography.Native.Apple/pal_swiftbindings.swift
Outdated
Show resolved
Hide resolved
After looking at the Mono failure, this looks like the remaining failure is a bug in the Mono MiniJIT support for the Swift calling convention on x64. @matouskozak can you take a look? I added a print statement in My LLDB is crashing locally, so I'm having trouble getting much further. |
The runtime/src/mono/mono/metadata/marshal.c Lines 6820 to 6827 in 1ded19e
The parameter is of type if (!(type->type == MONO_TYPE_GENERICINST && mono_type_generic_inst_is_valuetype (type))
&& type->type != MONO_TYPE_VALUETYPE
&& !mono_type_is_primitive (type))) {
lowering.by_reference = TRUE;
return lowering;
} |
The next problem looks like some sort of corruption in the caller function (somehow we're ending up with a non-zero-length null span). Any other ideas? Maybe an issue with |
Looks like @kotlarmilos's suggested workaround was successful. Failures are unrelated, so I'll merge this in. |
/ba-g wasm timeouts unrelated (CryptoKit is apple-only) |
Now that we have support for frozen structs in the Swift calling convention support in the VM, use that support to reimplement the CryptoKit PAL using basic Swift types that implement the necessary protocols for CryptoKit APIs (
Unsafe{Mutable}BufferPointer<T>
) at the PAL boundary.Also refactor our CryptoKit bindings to reduce duplication.
This PR represents us reaching Phase 2 of our .NET 9 Swift Interop project (using all of the JIT calling convention support, minimal projection support, still using a Swift wrapper).