Re: [PATCH v4 17/19] Documentation: ioctl: add CMH ioctl documentation and register 'J'

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch introduces a massive vendor-specific UAPI for standard cryptographic algorithms (RSA, ECDSA, ML-KEM, ML-DSA, etc.) and key management, bypassing the standard Linux kernel Crypto API and Keys subsystems.
--

commit 46b4cfa2c3a26b48cc446eeae37ca79f94c3f4db
Author: Alex Ousherovitch <aousherovitch@rambus.com>

Documentation: ioctl: add CMH ioctl documentation and register 'J'

This commit adds documentation for the Rambus CryptoManager Hub (CMH) ioctl
interface, covering key management and cryptographic operations. It also
registers the 'J' ioctl magic number for the driver.

> diff --git a/Documentation/userspace-api/ioctl/cmh_mgmt.rst b/Documentation/userspace-api/ioctl/cmh_mgmt.rst
> new file mode 100644
> index 0000000000000..c02bac1287874
> --- /dev/null
> +++ b/Documentation/userspace-api/ioctl/cmh_mgmt.rst
[ ... ]
> +Relationship to the in-kernel crypto API
> +=========================================
> +
> +The main reason these operations are exposed as ioctls, rather than
> +through the standard in-kernel crypto API, is the CMH datastore key
> +model: an ioctl can operate on a *datastore-referenced* (hardware-held)
> +key, identified only by a ``ref`` or CID, whose raw bytes the CPU never
> +sees.  The standard crypto API cannot express this -- every

[Severity: High]
Does introducing a bespoke ioctl interface for standard cryptographic
algorithms (RSA, ECDSA, ML-KEM, ML-DSA, etc.) fracture the kernel UAPI
ecosystem?

Instead of integrating hardware-bound keys into the existing Key Retention
Service and Crypto API/AF_ALG, which allows user-space tools to transparently
support new hardware, this locks the kernel into maintaining an immutable,
vendor-specific ABI forever.

Is it possible to integrate these operations using existing core kernel
abstractions rather than creating a massive vendor-specific UAPI?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825221539.255951-1-aousherovitch@rambus.com?part=17