diff options
| author | Mark Brown <broonie@kernel.org> | 2026-05-29 22:36:57 +0100 |
|---|---|---|
| committer | Mark Brown <broonie@kernel.org> | 2026-05-29 22:36:57 +0100 |
| commit | 27d393e3d2a5dc873f563e143a3f20fd8fb9cdb2 (patch) | |
| tree | 851527b00f61ea18d64c296d580f42ec32938df8 /Documentation | |
| parent | 7a822a9dd6e98ccec31f0f02bd4db6252ed7f188 (diff) | |
| parent | 5624ea54f3ba5c83d2e5503411a31a8be0278c1e (diff) | |
| download | linux-next-history-27d393e3d2a5dc873f563e143a3f20fd8fb9cdb2.tar.gz | |
Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/ABI/testing/sysfs-driver-qat_rl | 2 | ||||
| -rw-r--r-- | Documentation/crypto/api-samples.rst | 2 | ||||
| -rw-r--r-- | Documentation/crypto/userspace-if.rst | 127 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 2 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 4 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/rng/mtk-rng.yaml | 43 | ||||
| -rw-r--r-- | Documentation/devicetree/bindings/trivial-devices.yaml | 4 | ||||
| -rw-r--r-- | Documentation/userspace-api/ioctl/ioctl-number.rst | 1 |
8 files changed, 128 insertions, 57 deletions
diff --git a/Documentation/ABI/testing/sysfs-driver-qat_rl b/Documentation/ABI/testing/sysfs-driver-qat_rl index d534f89b49719..422333a0eb691 100644 --- a/Documentation/ABI/testing/sysfs-driver-qat_rl +++ b/Documentation/ABI/testing/sysfs-driver-qat_rl @@ -209,7 +209,7 @@ Date: January 2024 KernelVersion: 6.7 Contact: qat-linux@intel.com Description: - (RW) This file will return the remaining capability for a + (RW) This file will return the remaining capacity for a particular service/sla. This is the remaining value that a new SLA can be set to or a current SLA can be increased with. diff --git a/Documentation/crypto/api-samples.rst b/Documentation/crypto/api-samples.rst index e923f17bc2bd5..388bb7d7a460b 100644 --- a/Documentation/crypto/api-samples.rst +++ b/Documentation/crypto/api-samples.rst @@ -159,7 +159,7 @@ Code Example For Random Number Generator Usage static int get_random_numbers(u8 *buf, unsigned int len) { struct crypto_rng *rng = NULL; - char *drbg = "drbg_nopr_sha256"; /* Hash DRBG with SHA-256, no PR */ + char *drbg = "stdrng"; int ret; if (!buf || !len) { diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst index 021759198fe77..ab93300c8e045 100644 --- a/Documentation/crypto/userspace-if.rst +++ b/Documentation/crypto/userspace-if.rst @@ -4,26 +4,88 @@ User Space Interface Introduction ------------ -The concepts of the kernel crypto API visible to kernel space is fully -applicable to the user space interface as well. Therefore, the kernel -crypto API high level discussion for the in-kernel use cases applies -here as well. +AF_ALG provides unprivileged userspace programs access to arbitrary hash, +symmetric cipher, AEAD, and RNG algorithms that are implemented in kernel-mode +code. -The major difference, however, is that user space can only act as a -consumer and never as a provider of a transformation or cipher -algorithm. +AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010, +most kernel developers now consider it to be a mistake. Support for hardware +accelerators, which was the original purpose of AF_ALG, has been removed. -The following covers the user space interface exported by the kernel -crypto API. A working example of this description is libkcapi that can -be obtained from [1]. That library can be used by user space -applications that require cryptographic services from the kernel. +AF_ALG continues to be supported only for backwards compatibility. On systems +where no programs using AF_ALG remain, the support for it should be disabled by +disabling ``CONFIG_CRYPTO_USER_API_*``. -Some details of the in-kernel kernel crypto API aspects do not apply to -user space, however. This includes the difference between synchronous -and asynchronous invocations. The user space API call is fully -synchronous. +Deprecation +----------- -[1] https://www.chronox.de/libkcapi/index.html +AF_ALG was originally intended to provide userspace programs access to crypto +accelerators that they wouldn't otherwise have access to. + +However, that capability turned out to not be useful on very many systems. More +significantly, the actual implementation exposes a vastly greater amount of +functionality than that. It actually provides access to all software algorithms. + +This includes arbitrary compositions of different algorithms created via a +complex template system, as well as algorithms that only make sense as internal +implementation details of other algorithms. In the past, it also included full +zero-copy support, which was difficult for the kernel to implement securely. + +Ultimately, these algorithms are just math computations. They use the same +instructions that userspace programs already have access to, just accessed in a +much more convoluted and less efficient way. + +Indeed, userspace code is nearly always what is being used anyway. These same +algorithms are widely implemented in userspace crypto libraries. + +Even when zero-copy and off-CPU accelerators were supported, AF_ALG was usually +much slower than optimized software cryptography in userspace. This was +especially true for the small message sizes usually seen in performance-critical +workloads. While it was possible to demonstrate performance wins for hashing +large files on embedded devices, it is hard to imagine a situation where this +would be performance-critical. + +Nowadays, AF_ALG no longer supports zero-copy or off-CPU accelerators. +Therefore, it is *always* slower than an optimized userspace implementation, +even for large messages. The only possible advantage left is that it avoids +duplicating code between kernel and userspace. However, userspace +implementations, especially hardware-accelerated ones, do not need to be large. +Just because OpenSSL is huge does not mean that all userspace cryptography +libraries are. + +Meanwhile, AF_ALG hasn't been withstanding modern vulnerability discovery tools +such as syzbot and large language models. It receives a steady stream of CVEs. +Some of the examples include: + +- CVE-2026-31677 +- CVE-2026-31431 (https://copy.fail) +- CVE-2025-38079 +- CVE-2025-37808 +- CVE-2024-26824 +- CVE-2022-48781 +- CVE-2019-8912 +- CVE-2018-14619 +- CVE-2017-18075 +- CVE-2017-17806 +- CVE-2017-17805 +- CVE-2016-10147 +- CVE-2015-8970 +- CVE-2015-3331 +- CVE-2014-9644 +- CVE-2013-7421 +- CVE-2011-4081 + +Hardware accelerator drivers are frequently buggy. To reduce attack surface, +AF_ALG now only provides access to algorithms implemented in software. This +means that AF_ALG no longer fulfills its original purpose. + +It is recommended that, whenever possible, userspace programs be migrated to +userspace crypto code (which again, is what is normally used anyway) and +``CONFIG_CRYPTO_USER_API_*`` be disabled. On systems that use SELinux, SELinux +can also be used to restrict the use of AF_ALG to trusted programs. + +The remainder of this documentation provides the historical documentation for +the deprecated AF_ALG interface. User Space API General Remarks ------------------------------ @@ -297,7 +359,7 @@ follows: struct sockaddr_alg sa = { .salg_family = AF_ALG, .salg_type = "rng", /* this selects the random number generator */ - .salg_name = "drbg_nopr_sha256" /* this is the RNG name */ + .salg_name = "stdrng" /* this is the RNG name */ }; @@ -327,33 +389,10 @@ CRYPTO_USER_API_RNG_CAVP option: Zero-Copy Interface ------------------- -In addition to the send/write/read/recv system call family, the AF_ALG -interface can be accessed with the zero-copy interface of -splice/vmsplice. As the name indicates, the kernel tries to avoid a copy -operation into kernel space. - -The zero-copy operation requires data to be aligned at the page -boundary. Non-aligned data can be used as well, but may require more -operations of the kernel which would defeat the speed gains obtained -from the zero-copy interface. - -The system-inherent limit for the size of one zero-copy operation is 16 -pages. If more data is to be sent to AF_ALG, user space must slice the -input into segments with a maximum size of 16 pages. - -Zero-copy can be used with the following code example (a complete -working example is provided with libkcapi): - -:: - - int pipes[2]; - - pipe(pipes); - /* input data in iov */ - vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT); - /* opfd is the file descriptor returned from accept() system call */ - splice(pipes[0], NULL, opfd, NULL, ret, 0); - read(opfd, out, outlen); +AF_ALG used to have zero-copy support, but it was removed due to it being a +frequent source of vulnerabilities. For backwards compatibility the splice() +and sendfile() system calls are still supported, but the kernel will make an +internal copy of the data before passing it to the crypto code. Setsockopt Interface diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml index 41402599e9ab8..d054cc114707b 100644 --- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml @@ -17,11 +17,13 @@ properties: - qcom,prng-ee # 8996 and later using EE - items: - enum: + - qcom,glymur-trng - qcom,ipq5332-trng - qcom,ipq5424-trng - qcom,ipq9574-trng - qcom,kaanapali-trng - qcom,milos-trng + - qcom,nord-trng - qcom,qcs615-trng - qcom,qcs8300-trng - qcom,sa8255p-trng diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml index 79d5be2548bc5..08febd66c22ba 100644 --- a/Documentation/devicetree/bindings/crypto/qcom-qce.yaml +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.yaml @@ -45,7 +45,11 @@ properties: - items: - enum: + - qcom,eliza-qce + - qcom,glymur-qce - qcom,kaanapali-qce + - qcom,milos-qce + - qcom,nord-qce - qcom,qcs615-qce - qcom,qcs8300-qce - qcom,sa8775p-qce diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml index 7e8dc62e5d3a6..38e67861b88fa 100644 --- a/Documentation/devicetree/bindings/rng/mtk-rng.yaml +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -11,12 +11,13 @@ maintainers: properties: $nodename: - pattern: "^rng@[0-9a-f]+$" + pattern: "^rng(@[0-9a-f]+)?$" compatible: oneOf: - enum: - mediatek,mt7623-rng + - mediatek,mt7981-rng - items: - enum: - mediatek,mt7622-rng @@ -25,6 +26,11 @@ properties: - mediatek,mt8365-rng - mediatek,mt8516-rng - const: mediatek,mt7623-rng + - items: + - enum: + - mediatek,mt7987-rng + - mediatek,mt7988-rng + - const: mediatek,mt7981-rng reg: maxItems: 1 @@ -38,18 +44,37 @@ properties: required: - compatible - - reg - - clocks - - clock-names + +allOf: + - if: + properties: + compatible: + contains: + const: mediatek,mt7981-rng + then: + properties: + reg: false + clocks: false + clock-names: false + else: + required: + - reg + - clocks + - clock-names additionalProperties: false examples: - | #include <dt-bindings/clock/mt2701-clk.h> - rng: rng@1020f000 { - compatible = "mediatek,mt7623-rng"; - reg = <0x1020f000 0x1000>; - clocks = <&infracfg CLK_INFRA_TRNG>; - clock-names = "rng"; + + rng@1020f000 { + compatible = "mediatek,mt7623-rng"; + reg = <0x1020f000 0x1000>; + clocks = <&infracfg CLK_INFRA_TRNG>; + clock-names = "rng"; + }; + - | + rng { + compatible = "mediatek,mt7981-rng"; }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 1e870bb1bb6ec..1b35b411e73bb 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -67,8 +67,10 @@ properties: - arduino,unoq-mcu # Temperature monitoring of Astera Labs PT5161L PCIe retimer - asteralabs,pt5161l - # i2c h/w elliptic curve crypto module + # ATECC508A - i2c h/w elliptic curve crypto module - atmel,atecc508a + # ATECC608B - i2c h/w elliptic curve crypto module + - atmel,atecc608b # ATSHA204 - i2c h/w symmetric crypto module - atmel,atsha204 # ATSHA204A - i2c h/w symmetric crypto module diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 331223761ffff..29a08bc059dd7 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -229,7 +229,6 @@ Code Seq# Include File Comments <mailto:gregkh@linuxfoundation.org> 'a' all linux/atm*.h, linux/sonet.h ATM on linux <http://lrcwww.epfl.ch/> -'a' 00-0F drivers/crypto/qat/qat_common/adf_cfg_common.h conflict! qat driver 'b' 00-FF conflict! bit3 vme host bridge <mailto:natalia@nikhefk.nikhef.nl> 'b' 00-0F linux/dma-buf.h conflict! |