Convert our CryptoKit bindings to use Swift structs at the boundary

[jkoritzinsky]

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).

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[vcsjones]

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.

[jkoritzinsky]

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.

[kotlarmilos]

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.

[kotlarmilos]

LGTM!

[jkoritzinsky]

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 encrypt to dump the key and the buffer size I got was way too big (123145356760544), so I think there was some corruption in the interop layer/incorrect register assignments.

My LLDB is crashing locally, so I'm having trouble getting much further.

[kotlarmilos]

The Unsafe{Mutable}BufferPointer structs are not lowered at the interop boundary due to the following condition in the

runtime/src/mono/mono/metadata/marshal.c

Lines 6820 to 6827 in 1ded19e

	// Non-value types are illegal at the interop boundary.
	if (type->type == MONO_TYPE_GENERICINST && !mono_type_generic_inst_is_valuetype (type)) {
	lowering.by_reference = TRUE;
	return lowering;
	} else if (type->type != MONO_TYPE_VALUETYPE && !mono_type_is_primitive(type)) {
	lowering.by_reference = TRUE;
	return lowering;
	}

The parameter is of type MONO_TYPE_GENERICINST, and mono_type_is_primitive returns FALSE. Here is one suggestion to address this:

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;
    }

[jkoritzinsky]

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 SwiftError* with this many parameters?

[jkoritzinsky]

Looks like @kotlarmilos's suggested workaround was successful.

Failures are unrelated, so I'll merge this in.

[jkoritzinsky]

/ba-g wasm timeouts unrelated (CryptoKit is apple-only)