Re: [PATCH v5 00/11] crypto: crypto_user_stat: misc enhancement
On Thu, Nov 29, 2018 at 02:42:15PM +, Corentin Labbe wrote: > Hello > > This patchset fixes all reported problem by Eric biggers. > > Regards > > Changes since v4: > - Inlined functions when !CRYPTO_STATS > > Changes since v3: > - Added a crypto_stats_init as asked vy Neil Horman > - Fixed some checkpatch complaints > > Changes since v2: > - moved all crypto_stats functions from header to algapi.c for using > crypto_alg_get/put > > Changes since v1: > - Better locking of crypto_alg via crypto_alg_get/crypto_alg_put > - remove all intermediate variables in crypto/crypto_user_stat.c > - splited all internal stats variables into different structures > > Corentin Labbe (11): > crypto: crypto_user_stat: made crypto_user_stat optional > crypto: CRYPTO_STATS should depend on CRYPTO_USER > crypto: crypto_user_stat: convert all stats from u32 to u64 > crypto: crypto_user_stat: split user space crypto stat structures > crypto: tool: getstat: convert user space example to the new > crypto_user_stat uapi > crypto: crypto_user_stat: fix use_after_free of struct xxx_request > crypto: crypto_user_stat: Fix invalid stat reporting > crypto: crypto_user_stat: remove intermediate variable > crypto: crypto_user_stat: Split stats in multiple structures > crypto: crypto_user_stat: rename err_cnt parameter > crypto: crypto_user_stat: Add crypto_stats_init > > crypto/Kconfig | 1 + > crypto/Makefile | 3 +- > crypto/ahash.c | 17 +- > crypto/algapi.c | 247 ++- > crypto/crypto_user_stat.c| 160 +-- > crypto/rng.c | 4 +- > include/crypto/acompress.h | 38 +--- > include/crypto/aead.h| 38 +--- > include/crypto/akcipher.h| 74 ++- > include/crypto/hash.h| 32 +-- > include/crypto/internal/cryptouser.h | 17 ++ > include/crypto/kpp.h | 48 + > include/crypto/rng.h | 27 +-- > include/crypto/skcipher.h| 36 +--- > include/linux/crypto.h | 290 ++- > include/uapi/linux/cryptouser.h | 102 ++---- > tools/crypto/getstat.c | 72 +++ > 17 files changed, 676 insertions(+), 530 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [crypto chcr 1/2] small packet Tx stalls the queue
On Fri, Nov 30, 2018 at 02:31:48PM +0530, Atul Gupta wrote: > Immediate packets sent to hardware should include the work > request length in calculating the flits. WR occupy one flit and > if not accounted result in invalid request which stalls the HW > queue. > > Cc: sta...@vger.kernel.org > Signed-off-by: Atul Gupta > --- > drivers/crypto/chelsio/chcr_ipsec.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto: x86/chacha20 - AVX-512VL block functions
4 2703 1960 2547 > 872 2047 2685 1945 2501 > 880 2055 2683 1902 2497 > 888 2060 2689 1897 2478 > 896 2139 2693 2023 2663 > 904 2049 2686 1970 2644 > 912 2055 2688 1925 2621 > 920 2047 2685 1911 2572 > 928 2114 2695 1907 2545 > 936 2055 2681 1927 2492 > 944 2055 2693 1930 2478 > 952 2042 2688 1909 2471 > 960 2136 2682 2014 2672 > 968 2054 2687 1999 2626 > 976 2040 2682 1982 2598 > 984 2055 2687 1943 2569 > 992 2138 2694 1884 2522 > 1000 2036 2681 1929 2506 > 1008 2052 2676 1926 2475 > 1016 2050 2686 1889 2430 > 1024 2125 2670 2039 2656 > 1032 1717 2175 1470 1995 > 1040 1768 2186 1456 1983 > 1048 1704 2185 1451 1950 > 1056 1770 2176 1410 1927 > 1064 1710 2178 1418 1918 > 1072 1753 2168 1394 1892 > 1080 1696 2170 1400 1892 > 1088 1761 2174 1472 2014 > 1096 1681 2158 1464 1968 > 1104 1746 2172 1457 1978 > 1112 1689 2167 1445 1955 > 1120 1738 2160 1431 1919 > 1128 1689 2155 1428 1915 > 1136 1747 2169 1415 1899 > 1144 1678 2161 1403 1881 > 1152 1749 2159 1474 2007 > 1160 1601 2050 1470 1991 > 1168 1648 2057 1461 1969 > 1176 1605 2043 1439 1948 > 1184 1654 2057 1428 1926 > 1192 1595 2051 1427 1899 > 1200 1647 2036 1419 1902 > 1208 1598 2048 1402 1888 > 1216 1643 2053 1471 1991 > 1224 1595 2043 1469 1987 > 1232 1649 2048 1456 1971 > 1240 1599 2040 1436 1939 > 1248 1644 2042 1433 1918 > 1256 1602 2045 1424 1900 > 1264 1648 2048 1413 1878 > 1272 1591 2034 1401 1878 > 1280 1649 2044 1475 2002 > 1288 1493 1984 1461 1972 > 1296 1484 1971 1438 1962 > 1304 1490 1985 1443 1947 > 1312 1535 1987 1425 1913 > 1320 1481 1965 1410 1901 > 1328 1493 1984 1407 1900 > 1336 1493 1979 1396 1882 > 1344 1526 1980 1465 1988 > 1352 1492 1970 1463 1983 > 1360 1487 1974 1452 1966 > 1368 1481 1977 1439 1937 > 1376 1535 1970 1428 1915 > 1384 1489 1973 1417 1905 > 1392 1483 1974 1415 1881 > 1400 1485 1963 1403 1882 > 1408 1523 1976 1466 1988 > 1416 1477 1969 1459 1964 > 1424 1487 1975 1455 1966 > 1432 1488 1972 1438 1941 > 1440 1518 1958 1432 1908 > 1448 1484 1972 1421 1905 > 1456 1485 1973 1398 1888 > 1464 1476 1962 1399 1870 > 1472 1530 1975 1471 1998 > 1480 1478 1967 1452 1979 > 1488 1478 1963 1453 1947 > 1496 1477 1963 1438 1930 > > > Martin Willi (3): > crypto: x86/chacha20 - Add a 8-block AVX-512VL variant > crypto: x86/chacha20 - Add a 2-block AVX-512VL variant > crypto: x86/chacha20 - Add a 4-block AVX-512VL variant > > arch/x86/crypto/Makefile | 5 + > arch/x86/crypto/chacha20-avx512vl-x86_64.S | 839 + > arch/x86/crypto/chacha20_glue.c| 40 + > 3 files changed, 884 insertions(+) > create mode 100644 arch/x86/crypto/chacha20-avx512vl-x86_64.S All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [Help] Null pointer exception in scatterwalk_start() in kernel-4.9
On Tue, Nov 20, 2018 at 07:09:53AM +, gongchen (E) wrote: > Hi Dear Herbert, > > Sorry to bother you , but we’ve met a problem in crypto module, > would you please kindly help us look into it ? Thank you very much. > > In the below function chain, scatterwalk_start() doesn't check > the result of sg_next(), so the kernel will crash if sg_next() returns a null > pointer, which is our case. (The full stack is at the end of letter) > > blkcipher_walk_done()->scatterwalk_done()->scatterwalk_pagedone()->scatterwalk_start(walk, > sg_next(walk->sg)); > > Should we add a null-pointer-check in scatterwalk_start()? Or is > there any process can ensure that there should be a valid sg pointer if the > condition (walk->offset >= walk->sg->offset + walk->sg->length) is true? > > We are really looking forward to your reply, any information will > be appreciated , thanks again. Did you apply the following patch? commit 0868def3e4100591e7a1fdbf3eed1439cc8f7ca3 Author: Eric Biggers Date: Mon Jul 23 10:54:57 2018 -0700 crypto: blkcipher - fix crash flushing dcache in error path Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: drop mask=CRYPTO_ALG_ASYNC from 'shash' tfm allocations
On Wed, Nov 14, 2018 at 12:21:11PM -0800, Eric Biggers wrote: > From: Eric Biggers > > 'shash' algorithms are always synchronous, so passing CRYPTO_ALG_ASYNC > in the mask to crypto_alloc_shash() has no effect. Many users therefore > already don't pass it, but some still do. This inconsistency can cause > confusion, especially since the way the 'mask' argument works is > somewhat counterintuitive. > > Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags. > > This patch shouldn't change any actual behavior. > > Signed-off-by: Eric Biggers > --- > drivers/block/drbd/drbd_receiver.c | 2 +- > drivers/md/dm-integrity.c | 2 +- > drivers/net/wireless/intersil/orinoco/mic.c | 6 ++ > fs/ubifs/auth.c | 5 ++--- > net/bluetooth/smp.c | 2 +- > security/apparmor/crypto.c | 2 +- > security/integrity/evm/evm_crypto.c | 3 +-- > security/keys/encrypted-keys/encrypted.c| 4 ++-- > security/keys/trusted.c | 4 ++-- > 9 files changed, 13 insertions(+), 17 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: drop mask=CRYPTO_ALG_ASYNC from 'cipher' tfm allocations
On Wed, Nov 14, 2018 at 12:19:39PM -0800, Eric Biggers wrote: > From: Eric Biggers > > 'cipher' algorithms (single block ciphers) are always synchronous, so > passing CRYPTO_ALG_ASYNC in the mask to crypto_alloc_cipher() has no > effect. Many users therefore already don't pass it, but some still do. > This inconsistency can cause confusion, especially since the way the > 'mask' argument works is somewhat counterintuitive. > > Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags. > > This patch shouldn't change any actual behavior. > > Signed-off-by: Eric Biggers > --- > arch/s390/crypto/aes_s390.c | 2 +- > drivers/crypto/amcc/crypto4xx_alg.c | 3 +-- > drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 4 +--- > drivers/crypto/geode-aes.c| 2 +- > drivers/md/dm-crypt.c | 2 +- > drivers/net/wireless/cisco/airo.c | 2 +- > drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 2 +- > drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 2 +- > drivers/usb/wusbcore/crypto.c | 2 +- > net/bluetooth/smp.c | 6 +++--- > net/mac80211/wep.c| 4 ++-- > net/wireless/lib80211_crypt_ccmp.c| 2 +- > net/wireless/lib80211_crypt_tkip.c| 4 ++-- > net/wireless/lib80211_crypt_wep.c | 4 ++-- > 14 files changed, 19 insertions(+), 22 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: remove useless initializations of cra_list
On Wed, Nov 14, 2018 at 11:35:48AM -0800, Eric Biggers wrote: > From: Eric Biggers > > Some algorithms initialize their .cra_list prior to registration. > But this is unnecessary since crypto_register_alg() will overwrite > .cra_list when adding the algorithm to the 'crypto_alg_list'. > Apparently the useless assignment has just been copy+pasted around. > > So, remove the useless assignments. > > Exception: paes_s390.c uses cra_list to check whether the algorithm is > registered or not, so I left that as-is for now. > > This patch shouldn't change any actual behavior. > > Signed-off-by: Eric Biggers > --- > arch/sparc/crypto/aes_glue.c | 5 - > arch/sparc/crypto/camellia_glue.c | 5 - > arch/sparc/crypto/des_glue.c | 5 - > crypto/lz4.c | 1 - > crypto/lz4hc.c| 1 - > drivers/crypto/bcm/cipher.c | 2 -- > drivers/crypto/omap-aes.c | 2 -- > drivers/crypto/omap-des.c | 1 - > drivers/crypto/qce/ablkcipher.c | 1 - > drivers/crypto/qce/sha.c | 1 - > drivers/crypto/sahara.c | 1 - > 11 files changed, 25 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: inside-secure - remove useless setting of type flags
On Wed, Nov 14, 2018 at 11:10:53AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> Remove the unnecessary setting of CRYPTO_ALG_TYPE_SKCIPHER.
> Commit 2c95e6d97892 ("crypto: skcipher - remove useless setting of type
> flags") took care of this everywhere else, but a few more instances made
> it into the tree at about the same time. Squash them before they get
> copy+pasted around again.
>
> This patch shouldn't change any actual behavior.
>
> Signed-off-by: Eric Biggers
> ---
> drivers/crypto/inside-secure/safexcel_cipher.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/5] crypto: caam - add support for Era 10
On Thu, Nov 08, 2018 at 03:36:26PM +0200, Horia Geantă wrote: > This patch set adds support for CAAM Era 10, currently used in LX2160A SoC: > -new register mapping: some registers/fields are deprecated and moved > to different locations, mainly version registers > -algorithms > chacha20 (over DPSECI - Data Path SEC Interface on fsl-mc bus) > rfc7539(chacha20,poly1305) (over both DPSECI and Job Ring Interface) > rfc7539esp(chacha20,poly1305) (over both DPSECI and Job Ring Interface) > > Note: the patch set is generated on top of cryptodev-2.6, however testing > was performed based on linux-next (tag: next-20181108) - which includes > LX2160A platform support + manually updating LX2160A dts with: > -fsl-mc bus DT node > -missing dma-ranges property in soc DT node > > Cristian Stoica (1): > crypto: export CHACHAPOLY_IV_SIZE > > Horia Geantă (4): > crypto: caam - add register map changes cf. Era 10 > crypto: caam/qi2 - add support for ChaCha20 > crypto: caam/jr - add support for Chacha20 + Poly1305 > crypto: caam/qi2 - add support for Chacha20 + Poly1305 > > crypto/chacha20poly1305.c | 2 - > drivers/crypto/caam/caamalg.c | 266 > ++--- > drivers/crypto/caam/caamalg_desc.c | 139 ++- > drivers/crypto/caam/caamalg_desc.h | 5 + > drivers/crypto/caam/caamalg_qi.c | 37 -- > drivers/crypto/caam/caamalg_qi2.c | 156 +- > drivers/crypto/caam/caamhash.c | 20 ++- > drivers/crypto/caam/caampkc.c | 10 +- > drivers/crypto/caam/caamrng.c | 10 +- > drivers/crypto/caam/compat.h | 2 + > drivers/crypto/caam/ctrl.c | 28 +++- > drivers/crypto/caam/desc.h | 28 > drivers/crypto/caam/desc_constr.h | 7 +- > drivers/crypto/caam/regs.h | 74 +-- > include/crypto/chacha20.h | 1 + > 15 files changed, 724 insertions(+), 61 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/6] crypto: x86/chacha20 - SIMD performance improvements
> 1048 1736 1737 1554 > 1056 1738 1802 1541 > 1064 1735 1728 1523 > 1072 1730 1780 1507 > 1080 1729 1724 1497 > 1088 1757 1783 1592 > 1096 1475 1723 1575 > 1104 1474 1778 1563 > 1112 1472 1708 1544 > 1120 1468 1774 1521 > 1128 1466 1718 1521 > 1136 1462 1780 1501 > 1144 1460 1719 1491 > 1152 1481 1782 1575 > 1160 1271 1647 1558 > 1168 1271 1706 1554 > 1176 1268 1645 1545 > 1184 1265 1711 1538 > 1192 1265 1648 1530 > 1200 1264 1705 1493 > 1208 1262 1647 1498 > 1216 1277 1695 1581 > 1224 1120 1642 1563 > 1232 1115 1702 1549 > 1240 1121 1646 1538 > 1248 1119 1703 1527 > 1256 1115 1640 1520 > 1264 1114 1693 1505 > 1272 1112 1642 1492 > 1280 1552 1699 1574 > 1288 1314 1525 1573 > 1296 1315 1522 1551 > 1304 1312 1521 1548 > 1312 1311 1564 1535 > 1320 1309 1518 1524 > 1328 1302 1527 1508 > 1336 1303 1521 1500 > 1344 1333 1561 1579 > 1352 1157 1524 1573 > 1360 1152 1520 1546 > 1368 1154 1522 1545 > 1376 1153 1562 1536 > 1384 1151 1525 1526 > 1392 1149 1523 1504 > 1400 1148 1517 1480 > 1408 1167 1561 1589 > 1416 1030 1516 1558 > 1424 1028 1516 1546 > 1432 1027 1522 1537 > 1440 1027 1564 1523 > 1448 1026 1507 1512 > 1456 1025 1515 1491 > 1464 1023 1522 1481 > 1472 1037 1559 1577 > 1480 927 1518 1559 > 1488 926 1514 1548 > 1496 926 1513 1534 > > > Martin Willi (6): > crypto: x86/chacha20 - Support partial lengths in 1-block SSSE3 > variant > crypto: x86/chacha20 - Support partial lengths in 4-block SSSE3 > variant > crypto: x86/chacha20 - Support partial lengths in 8-block AVX2 variant > crypto: x86/chacha20 - Use larger block functions more aggressively > crypto: x86/chacha20 - Add a 2-block AVX2 variant > crypto: x86/chacha20 - Add a 4-block AVX2 variant > > arch/x86/crypto/chacha20-avx2-x86_64.S | 696 ++-- > arch/x86/crypto/chacha20-ssse3-x86_64.S | 237 ++-- > arch/x86/crypto/chacha20_glue.c | 72 ++- > 3 files changed, 868 insertions(+), 137 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/6] crypto: x86/chacha20 - SIMD performance improvements
> 1048 1736 1737 1554 > 1056 1738 1802 1541 > 1064 1735 1728 1523 > 1072 1730 1780 1507 > 1080 1729 1724 1497 > 1088 1757 1783 1592 > 1096 1475 1723 1575 > 1104 1474 1778 1563 > 1112 1472 1708 1544 > 1120 1468 1774 1521 > 1128 1466 1718 1521 > 1136 1462 1780 1501 > 1144 1460 1719 1491 > 1152 1481 1782 1575 > 1160 1271 1647 1558 > 1168 1271 1706 1554 > 1176 1268 1645 1545 > 1184 1265 1711 1538 > 1192 1265 1648 1530 > 1200 1264 1705 1493 > 1208 1262 1647 1498 > 1216 1277 1695 1581 > 1224 1120 1642 1563 > 1232 1115 1702 1549 > 1240 1121 1646 1538 > 1248 1119 1703 1527 > 1256 1115 1640 1520 > 1264 1114 1693 1505 > 1272 1112 1642 1492 > 1280 1552 1699 1574 > 1288 1314 1525 1573 > 1296 1315 1522 1551 > 1304 1312 1521 1548 > 1312 1311 1564 1535 > 1320 1309 1518 1524 > 1328 1302 1527 1508 > 1336 1303 1521 1500 > 1344 1333 1561 1579 > 1352 1157 1524 1573 > 1360 1152 1520 1546 > 1368 1154 1522 1545 > 1376 1153 1562 1536 > 1384 1151 1525 1526 > 1392 1149 1523 1504 > 1400 1148 1517 1480 > 1408 1167 1561 1589 > 1416 1030 1516 1558 > 1424 1028 1516 1546 > 1432 1027 1522 1537 > 1440 1027 1564 1523 > 1448 1026 1507 1512 > 1456 1025 1515 1491 > 1464 1023 1522 1481 > 1472 1037 1559 1577 > 1480 927 1518 1559 > 1488 926 1514 1548 > 1496 926 1513 1534 Nice work Martin! In light of this, and the grumblings over the wholesale replacment of the existing chacha20 implementations, could we add the zinc interface in a piecemeal fashion? That is, instead of adding a bunch of new implementations through zinc and then converting the crypto users over, we instead convert the existing implementations over to zinc in-place. This would also resolve the complaints over not being able to choose different implementations through the crypto API and leaving that choice solely up to zinc. After that is done, wireguard could then proceed in parallel with replacing any implementations should the need arise. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Something wrong with cryptodev-2.6 tree?
On Mon, Nov 12, 2018 at 09:44:41AM +0200, Gilad Ben-Yossef wrote: > Hi, > > It seems that the cryptodev-2.6 tree at > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > has somehow rolled back 3 months ago. > > Not sure if it's a git.kernel.org issue or something else but probably > worth taking a look? Thanks Gilad. It should be fixed now. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: fix cfb mode decryption
On Sat, Oct 20, 2018 at 02:01:52AM +0300, Dmitry Eremin-Solenikov wrote: > crypto_cfb_decrypt_segment() incorrectly XOR'ed generated keystream with > IV, rather than with data stream, resulting in incorrect decryption. > Test vectors will be added in the next patch. > > Signed-off-by: Dmitry Eremin-Solenikov > Cc: sta...@vger.kernel.org > --- > crypto/cfb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 0/2] crypto: some hardening against AES cache-timing attacks
On Wed, Oct 17, 2018 at 09:37:57PM -0700, Eric Biggers wrote: > This series makes the "aes-fixed-time" and "aes-arm" implementations of > AES more resistant to cache-timing attacks. > > Note that even after these changes, the implementations still aren't > necessarily guaranteed to be constant-time; see > https://cr.yp.to/antiforgery/cachetiming-20050414.pdf for a discussion > of the many difficulties involved in writing truly constant-time AES > software. But it's valuable to make such attacks more difficult. > > Changed since v2: > - In aes-arm, move the IRQ disable/enable into the assembly file. > - Other aes-arm tweaks. > - Add Kconfig help text. > > Thanks to Ard Biesheuvel for the suggestions. > > Eric Biggers (2): > crypto: aes_ti - disable interrupts while accessing S-box > crypto: arm/aes - add some hardening against cache-timing attacks > > arch/arm/crypto/Kconfig | 9 + > arch/arm/crypto/aes-cipher-core.S | 62 ++- > crypto/Kconfig| 3 +- > crypto/aes_generic.c | 9 +++-- > crypto/aes_ti.c | 18 +++++ > 5 files changed, 86 insertions(+), 15 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto/simd: correctly take reqsize of wrapped skcipher into account
On Fri, Nov 09, 2018 at 05:44:47PM +0800, Herbert Xu wrote: > On Fri, Nov 09, 2018 at 12:33:23AM +0100, Ard Biesheuvel wrote: > > > > This should be > > > > reqsize += max(crypto_skcipher_reqsize(_tfm->base); > >crypto_skcipher_reqsize(cryptd_skcipher_child(cryptd_tfm))); > > > > since the cryptd path in simd still needs some space in the subreq for > > the completion. > > OK this is what I applied to the cryptodev tree, please double-check > to see if I did anything silly: I meant the crypto tree rather than cryptodev. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto/simd: correctly take reqsize of wrapped skcipher into account
On Fri, Nov 09, 2018 at 12:33:23AM +0100, Ard Biesheuvel wrote: > > This should be > > reqsize += max(crypto_skcipher_reqsize(_tfm->base); >crypto_skcipher_reqsize(cryptd_skcipher_child(cryptd_tfm))); > > since the cryptd path in simd still needs some space in the subreq for > the completion. OK this is what I applied to the cryptodev tree, please double-check to see if I did anything silly: diff --git a/crypto/simd.c b/crypto/simd.c index ea7240be3001..78e8d037ae2b 100644 --- a/crypto/simd.c +++ b/crypto/simd.c @@ -124,8 +124,9 @@ static int simd_skcipher_init(struct crypto_skcipher *tfm) ctx->cryptd_tfm = cryptd_tfm; - reqsize = sizeof(struct skcipher_request); - reqsize += crypto_skcipher_reqsize(_tfm->base); + reqsize = crypto_skcipher_reqsize(cryptd_skcipher_child(cryptd_tfm)); + reqsize = max(reqsize, crypto_skcipher_reqsize(_tfm->base)); + reqsize += sizeof(struct skcipher_request); crypto_skcipher_set_reqsize(tfm, reqsize); Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: fix cfb mode decryption
On Thu, Nov 01, 2018 at 11:32:37AM +0300, Dmitry Eremin-Solenikov wrote: > > Since 4.20 pull went into Linus'es tree, any change of getting these two > patches > in crypto tree? These aren't critical enough for the current mainline so they will go in at the next merge window. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam - add SPDX license identifier to all files
On Wed, Oct 10, 2018 at 02:26:48PM +0300, Horia Geantă wrote:
> Previously, a tree-wide change added SPDX license identifiers to
> files lacking licensing information:
> b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files
> with no license")
>
> To be consistent update the rest of the files:
> -files with license specified by means of MODULE_LICENSE()
> -files with complete license text
> -Kconfig
>
> Signed-off-by: Horia Geantă
> ---
> drivers/crypto/caam/Kconfig| 1 +
> drivers/crypto/caam/caamalg.c | 1 +
> drivers/crypto/caam/caamalg_desc.c | 1 +
> drivers/crypto/caam/caamalg_qi.c | 1 +
> drivers/crypto/caam/caamhash.c | 1 +
> drivers/crypto/caam/caampkc.c | 1 +
> drivers/crypto/caam/caamrng.c | 1 +
> drivers/crypto/caam/ctrl.c | 1 +
> drivers/crypto/caam/jr.c | 1 +
> drivers/crypto/caam/sg_sw_qm.h | 29 +
> drivers/crypto/caam/sg_sw_qm2.h| 30 +-
> 11 files changed, 11 insertions(+), 57 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/aes-blk - ensure XTS mask is always loaded
On Mon, Oct 08, 2018 at 01:16:59PM +0200, Ard Biesheuvel wrote:
> Commit 2e5d2f33d1db ("crypto: arm64/aes-blk - improve XTS mask handling")
> optimized away some reloads of the XTS mask vector, but failed to take
> into account that calls into the XTS en/decrypt routines will take a
> slightly different code path if a single block of input is split across
> different buffers. So let's ensure that the first load occurs
> unconditionally, and move the reload to the end so it doesn't occur
> needlessly.
>
> Fixes: 2e5d2f33d1db ("crypto: arm64/aes-blk - improve XTS mask handling")
> Signed-off-by: Ard Biesheuvel
> ---
> arch/arm64/crypto/aes-modes.S | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] crypto: mxs-dcp: make symbols 'sha1_null_hash' and 'sha256_null_hash' static
On Thu, Oct 11, 2018 at 01:49:48AM +, Wei Yongjun wrote:
> Fixes the following sparse warnings:
>
> drivers/crypto/mxs-dcp.c:39:15: warning:
> symbol 'sha1_null_hash' was not declared. Should it be static?
> drivers/crypto/mxs-dcp.c:43:15: warning:
> symbol 'sha256_null_hash' was not declared. Should it be static?
>
> Fixes: c709eebaf5c5 ("crypto: mxs-dcp - Fix SHA null hashes and output
> length")
> Signed-off-by: Wei Yongjun
> ---
> drivers/crypto/mxs-dcp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto/testmgr.c: fix sizeof() on COMP_BUF_SIZE
On Sun, Oct 07, 2018 at 01:58:10PM +0200, Michael Schupikov wrote:
> After allocation, output and decomp_output both point to memory chunks of
> size COMP_BUF_SIZE. Then, only the first bytes are zeroed out using
> sizeof(COMP_BUF_SIZE) as parameter to memset(), because
> sizeof(COMP_BUF_SIZE) provides the size of the constant and not the size of
> allocated memory.
>
> Instead, the whole allocated memory is meant to be zeroed out. Use
> COMP_BUF_SIZE as parameter to memset() directly in order to accomplish
> this.
>
> Fixes: 336073840a872 ("crypto: testmgr - Allow different compression results")
>
> Signed-off-by: Michael Schupikov
> ---
> crypto/testmgr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] crypto: axis - fix platform_no_drv_owner.cocci warnings
On Fri, Oct 05, 2018 at 06:42:44AM +, YueHaibing wrote: > Remove .owner field if calls are used which set it automatically > Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci > > Signed-off-by: YueHaibing Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] crypto: chtls - remove set but not used variable 'csk'
On Fri, Oct 05, 2018 at 06:43:27AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/crypto/chelsio/chtls/chtls_cm.c: In function 'chtls_disconnect':
> drivers/crypto/chelsio/chtls/chtls_cm.c:408:21: warning:
> variable 'csk' set but not used [-Wunused-but-set-variable]
>
> drivers/crypto/chelsio/chtls/chtls_cm.c: In function 'chtls_recv_sock':
> drivers/crypto/chelsio/chtls/chtls_cm.c:1016:23: warning:
> variable 'tcph' set but not used [-Wunused-but-set-variable]
>
> 'csk' and 'tcph' are never used since introduce
> in commit cc35c88ae4db ("crypto : chtls - CPL handler definition")
>
> Signed-off-by: YueHaibing
> ---
> drivers/crypto/chelsio/chtls/chtls_cm.c | 4
> 1 file changed, 4 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/aes-ni - fix build error following fpu template removal
On Fri, Oct 05, 2018 at 10:13:06AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> aesni-intel_glue.c still calls crypto_fpu_init() and crypto_fpu_exit()
> to register/unregister the "fpu" template. But these functions don't
> exist anymore, causing a build error. Remove the calls to them.
>
> Fixes: 944585a64f5e ("crypto: x86/aes-ni - remove special handling of AES in
> PCBC mode")
> Signed-off-by: Eric Biggers
> ---
> arch/x86/crypto/aesni-intel_glue.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/aes - fix handling sub-block CTS-CBC inputs
On Tue, Oct 02, 2018 at 10:22:15PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In the new arm64 CTS-CBC implementation, return an error code rather
> than crashing on inputs shorter than AES_BLOCK_SIZE bytes. Also set
> cra_blocksize to AES_BLOCK_SIZE (like is done in the cts template) to
> indicate the minimum input size.
>
> Fixes: dd597fb33ff0 ("crypto: arm64/aes-blk - add support for CTS-CBC mode")
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto: mxs-dcp - Fix tcrypt on imx6
On Tue, Oct 02, 2018 at 07:01:46PM +, Leonard Crestez wrote: > The mxs-dcp driver currently fails to probe on imx6. Fix the whole thing > by porting a cleaned/squashed version of fixes carried in the NXP vendor > tree. > > Tested with "modprobe tcrypt" and CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=n > on imx6sl imx6sll imx6ull: no failures. > > I'm not very familiar with crypto and did not write write these fixes so > a skeptical review would be appreciated. > > Previously: > https://lore.kernel.org/patchwork/patch/989652/ > > Dan Douglass (1): > crypto: mxs-dcp - Implement sha import/export > > Radu Solea (2): > crypto: mxs-dcp - Fix SHA null hashes and output length > crypto: mxs-dcp - Fix AES issues > > drivers/crypto/mxs-dcp.c | 121 --- > 1 file changed, 101 insertions(+), 20 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/2] crypto - fix aegis/morus for big endian systems
On Mon, Oct 01, 2018 at 10:36:36AM +0200, Ard Biesheuvel wrote: > Some bug fixes for issues that I stumbled upon while working on other > stuff. > > Changes since v1: > - add Ondrej's ack to #1 > - simplify #2 and drop unrelated performance tweak > > Ard Biesheuvel (2): > crypto: morus/generic - fix for big endian systems > crypto: aegis/generic - fix for big endian systems > > crypto/aegis.h | 20 +--- > crypto/morus1280.c | 7 ++- > crypto/morus640.c | 16 > 3 files changed, 15 insertions(+), 28 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] drivers: crypto: caam: kconfig: create menu for CAAM
Franck LENORMAND wrote: > The CAAM driver has multiple configuration and all are listed > in the crypto menu. > > This patch create a menu dedicated to the Freescale CAAM driver. > > Signed-off-by: Franck LENORMAND > --- > drivers/crypto/caam/Kconfig | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig > index 1eb8527..fb87245 100644 > --- a/drivers/crypto/caam/Kconfig > +++ b/drivers/crypto/caam/Kconfig > @@ -1,3 +1,5 @@ > +menu "Freescale CAAM" > + > config CRYPTO_DEV_FSL_CAAM >tristate "Freescale CAAM-Multicore driver backend" >depends on FSL_SOC || ARCH_MXC || ARCH_LAYERSCAPE > @@ -152,3 +154,5 @@ config CRYPTO_DEV_FSL_CAAM_DEBUG > config CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC >def_tristate (CRYPTO_DEV_FSL_CAAM_CRYPTO_API || \ > CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI) > + > +endmenu Please rebase this on the current cryptodev tree as it doesn't apply. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: lrw - fix rebase error after out of bounds fix
On Sun, Sep 30, 2018 at 09:51:16PM +0200, Ard Biesheuvel wrote:
> Due to an unfortunate interaction between commit fbe1a850b3b1
> ("crypto: lrw - Fix out-of bounds access on counter overflow") and
> commit c778f96bf347 ("crypto: lrw - Optimize tweak computation"),
> we ended up with a version of next_index() that always returns 127.
>
> Fixes: c778f96bf347 ("crypto: lrw - Optimize tweak computation")
> Signed-off-by: Ard Biesheuvel
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: qat - move temp buffers off the stack
On Wed, Sep 26, 2018 at 11:51:59AM +0200, Ard Biesheuvel wrote: > Arnd reports that with Kees's latest VLA patches applied, the HMAC > handling in the QAT driver uses a worst case estimate of 160 bytes > for the SHA blocksize, allowing the compiler to determine the size > of the stack frame at runtime and throw a warning: > > drivers/crypto/qat/qat_common/qat_algs.c: In function > 'qat_alg_do_precomputes': > drivers/crypto/qat/qat_common/qat_algs.c:257:1: error: the frame size > of 1112 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] > > Given that this worst case estimate is only 32 bytes larger than the > actual block size of SHA-512, the use of a VLA here was hiding the > excessive size of the stack frame from the compiler, and so we should > try to move these buffers off the stack. > > So move the ipad/opad buffers and the various SHA state descriptors > into the tfm context struct. Since qat_alg_do_precomputes() is only > called in the context of a setkey() operation, this should be safe. > Using SHA512_BLOCK_SIZE for the size of the ipad/opad buffers allows > them to be used by SHA-1/SHA-256 as well. > > Reported-by: Arnd Bergmann > Signed-off-by: Ard Biesheuvel > --- > This applies against v4.19-rc while Arnd's report was about -next. However, > since Kees's VLA change results in a warning about a pre-existing condition, > we may decide to apply it as a fix, and handle the conflict with Kees's > patch in cryptodev. Otherwise, I can respin it to apply onto cryptodev > directly. The patch was build tested only - I don't have the hardware. > > Thoughts anyone? I applied it against cryptodev only. I don't think it's bad enough to warrant a backport to stable though. But if you guys disagree we could always send the backport to stable after this goes upstream. > drivers/crypto/qat/qat_common/qat_algs.c | 60 ++-- > 1 file changed, 31 insertions(+), 29 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next v2] crypto: ccp - Make function sev_get_firmware() static
On Wed, Sep 26, 2018 at 02:09:23AM +, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/psp-dev.c:444:5: warning:
> symbol 'sev_get_firmware' was not declared. Should it be static?
>
> Fixes: e93720606efd ("crypto: ccp - Allow SEV firmware to be chosen based on
> Family and Model")
> Signed-off-by: Wei Yongjun
> ---
> v1 -> v2: add fixes and add cc Janakarajan
> ---
> drivers/crypto/ccp/psp-dev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH] crypto: x86/aes-ni - remove special handling of AES in PCBC mode
On Mon, Sep 24, 2018 at 02:48:16PM +0200, Ard Biesheuvel wrote: > For historical reasons, the AES-NI based implementation of the PCBC > chaining mode uses a special FPU chaining mode wrapper template to > amortize the FPU start/stop overhead over multiple blocks. > > When this FPU wrapper was introduced, it supported widely used > chaining modes such as XTS and CTR (as well as LRW), but currently, > PCBC is the only remaining user. > > Since there are no known users of pcbc(aes) in the kernel, let's remove > this special driver, and rely on the generic pcbc driver to encapsulate > the AES-NI core cipher. > > Signed-off-by: Ard Biesheuvel > --- > arch/x86/crypto/Makefile | 2 +- > arch/x86/crypto/aesni-intel_glue.c | 32 --- > arch/x86/crypto/fpu.c | 207 > crypto/Kconfig | 2 +- > 4 files changed, 2 insertions(+), 241 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/1] crypto:chelsio: Fix memory corruption in DMA Mapped buffers.
On Wed, Sep 19, 2018 at 10:42:16PM +0530, Harsh Jain wrote: > Update PCI Id in "cpl_rx_phys_dsgl" header. In case pci_chan_id and > tx_chan_id are not derived from same queue, H/W can send request > completion indication before completing DMA Transfer. > > Herbert, It would be good if fix can be merge to stable tree. > For 4.14 kernel, It requires some update to avoid mege conficts. > > Signed-off-by: Harsh Jain Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: tcrypt - remove remnants of pcomp-based zlib
On Wed, Sep 19, 2018 at 05:54:21PM +0300, Horia Geantă wrote:
> Commit 110492183c4b ("crypto: compress - remove unused pcomp interface")
> removed pcomp interface but missed cleaning up tcrypt.
>
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: fix a memory leak in rsa-kcs1pad's encryption mode
On Mon, Sep 17, 2018 at 08:24:32PM +0300, Dan Aloni wrote: > The encryption mode of pkcs1pad never uses out_sg and out_buf, so > there's no need to allocate the buffer, which presently is not even > being freed. > > CC: Herbert Xu > CC: linux-crypto@vger.kernel.org > CC: "David S. Miller" > Signed-off-by: Dan Aloni Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam/jr - fix ablkcipher_edesc pointer arithmetic
On Fri, Sep 14, 2018 at 06:34:28PM +0300, Horia Geantă wrote:
> In some cases the zero-length hw_desc array at the end of
> ablkcipher_edesc struct requires for 4B of tail padding.
>
> Due to tail padding and the way pointers to S/G table and IV
> are computed:
> edesc->sec4_sg = (void *)edesc + sizeof(struct ablkcipher_edesc) +
>desc_bytes;
> iv = (u8 *)edesc->hw_desc + desc_bytes + sec4_sg_bytes;
> first 4 bytes of IV are overwritten by S/G table.
>
> Update computation of pointer to S/G table to rely on offset of hw_desc
> member and not on sizeof() operator.
>
> Cc: # 4.13+
> Fixes: 115957bb3e59 ("crypto: caam - fix IV DMA mapping and updating")
> Signed-off-by: Horia Geantă
> ---
>
> This is for crypto-2.6 tree / current v4.19 release cycle.
Patch applied. Thanks.
> Note that it will create merge conflicts later in v4.20 due to commits
> cf5448b5c3d8 ("crypto: caam/jr - remove ablkcipher IV generation")
> 5ca7badb1f62 ("crypto: caam/jr - ablkcipher -> skcipher conversion")
> from cryptodev-2.6 tree.
>
> Should I send a similar fix for skcipher-based caam/jr driver
> on cryptodev-2.6 tree, or will this be handled while solving the conflicts?
I have merged crypto into cryptodev to resolve the conflict.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: tcrypt - fix ghash-generic speed test
On Wed, Sep 12, 2018 at 04:20:48PM +0300, Horia Geantă wrote:
> ghash is a keyed hash algorithm, thus setkey needs to be called.
> Otherwise the following error occurs:
> $ modprobe tcrypt mode=318 sec=1
> testing speed of async ghash-generic (ghash-generic)
> tcrypt: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
> tcrypt: hashing failed ret=-126
>
> Cc: # 4.6+
> Fixes: 0660511c0bee ("crypto: tcrypt - Use ahash")
> Tested-by: Franck Lenormand
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: chacha20 - Fix chacha20_block() keystream alignment (again)
On Tue, Sep 11, 2018 at 08:05:10PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
> chacha20_block()"), I had missed that chacha20_block() can be called
> directly on the buffer passed to get_random_bytes(), which can have any
> alignment. So, while my commit didn't break anything, it didn't fully
> solve the alignment problems.
>
> Revert my solution and just update chacha20_block() to use
> put_unaligned_le32(), so the output buffer need not be aligned.
> This is simpler, and on many CPUs it's the same speed.
>
> But, I kept the 'tmp' buffers in extract_crng_user() and
> _get_random_bytes() 4-byte aligned, since that alignment is actually
> needed for _crng_backtrack_protect() too.
>
> Reported-by: Stephan Müller
> Cc: Theodore Ts'o
> Signed-off-by: Eric Biggers
> ---
> crypto/chacha20_generic.c | 7 ---
> drivers/char/random.c | 24
> include/crypto/chacha20.h | 3 +--
> lib/chacha20.c| 6 +++---
> 4 files changed, 20 insertions(+), 20 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: arm64/aes-blk - cleanups and optimizations for XTS/CTS-CBC
On Mon, Sep 10, 2018 at 04:41:11PM +0200, Ard Biesheuvel wrote: > Some cleanups and optimizations for the arm64 AES skcipher routines. > > Patch #1 fixes the peculiar use of u8 arrays to refer to AES round keys, > which are natively arrays of u32. > > Patch #2 partially reverts the use of NEON yield calls, which is not > needed for skciphers. > > Patch #3 adds support for cts(cbc(aes)) in the NEON chaining mode handling. > > Patch #4 tweaks the XTS handling to remove a literal load from the inner > loop. > > Cc: Eric Biggers > Cc: Theodore Ts'o > Cc: Steve Capper > > Ard Biesheuvel (4): > crypto: arm64/aes-blk - remove pointless (u8 *) casts > crypto: arm64/aes-blk - revert NEON yield for skciphers > crypto: arm64/aes-blk - add support for CTS-CBC mode > crypto: aes/arm64-blk - improve XTS mask handling > > arch/arm64/crypto/aes-ce.S| 5 + > arch/arm64/crypto/aes-glue.c | 212 +-- > arch/arm64/crypto/aes-modes.S | 400 ++-- > arch/arm64/crypto/aes-neon.S | 6 + > 4 files changed, 406 insertions(+), 217 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v5] crypto: xts - Drop use of auxiliary buffer
On Tue, Sep 11, 2018 at 09:40:08AM +0200, Ondrej Mosnacek wrote:
> Since commit acb9b159c784 ("crypto: gf128mul - define gf128mul_x_* in
> gf128mul.h"), the gf128mul_x_*() functions are very fast and therefore
> caching the computed XTS tweaks has only negligible advantage over
> computing them twice.
>
> In fact, since the current caching implementation limits the size of
> the calls to the child ecb(...) algorithm to PAGE_SIZE (usually 4096 B),
> it is often actually slower than the simple recomputing implementation.
>
> This patch simplifies the XTS template to recompute the XTS tweaks from
> scratch in the second pass and thus also removes the need to allocate a
> dynamic buffer using kmalloc().
>
> As discussed at [1], the use of kmalloc causes deadlocks with dm-crypt.
>
> PERFORMANCE RESULTS
> I measured time to encrypt/decrypt a memory buffer of varying sizes with
> xts(ecb-aes-aesni) using a tool I wrote ([2]) and the results suggest
> that after this patch the performance is either better or comparable for
> both small and large buffers. Note that there is a lot of noise in the
> measurements, but the overall difference is easy to see.
>
> Old code:
>ALGORITHM KEY (b)DATA (B) TIME ENC (ns) TIME DEC (ns)
> xts(aes) 256 64 331 328
> xts(aes) 384 64 332 333
> xts(aes) 512 64 338 348
> xts(aes) 256 512 889 920
> xts(aes) 384 5121019 993
> xts(aes) 512 5121032 990
> xts(aes) 256409621522292
> xts(aes) 384409624532597
> xts(aes) 512409630412641
> xts(aes) 256 1638494438027
> xts(aes) 384 1638485368925
> xts(aes) 512 1638492329417
> xts(aes) 256 32768 16383 14897
> xts(aes) 384 32768 17527 16102
> xts(aes) 512 32768 18483 17322
>
> New code:
>ALGORITHM KEY (b)DATA (B) TIME ENC (ns) TIME DEC (ns)
> xts(aes) 256 64 328 324
> xts(aes) 384 64 324 319
> xts(aes) 512 64 320 322
> xts(aes) 256 512 476 473
> xts(aes) 384 512 509 492
> xts(aes) 512 512 531 514
> xts(aes) 256409621321829
> xts(aes) 384409623572055
> xts(aes) 512409621782027
> xts(aes) 256 1638469206983
> xts(aes) 384 1638485977505
> xts(aes) 512 1638478418164
> xts(aes) 256 32768 13468 12307
> xts(aes) 384 32768 14808 13402
> xts(aes) 512 32768 15753 14636
>
> [1] https://lkml.org/lkml/2018/8/23/1315
> [2] https://gitlab.com/omos/linux-crypto-bench
>
> Signed-off-by: Ondrej Mosnacek
> ---
> crypto/xts.c | 269 +--
> 1 file changed, 46 insertions(+), 223 deletions(-)
>
> Changes in v5:
> - fix dumb mistakes
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] gcmaes_crypt_by_sg: don't use GFP_ATOMIC allocation if the request doesn't cross a page
On Wed, Sep 05, 2018 at 09:18:43AM -0400, Mikulas Patocka wrote: > This patch fixes gcmaes_crypt_by_sg so that it won't use memory > allocation if the data doesn't cross a page boundary. > > Authenticated encryption may be used by dm-crypt. If the encryption or > decryption fails, it would result in I/O error and filesystem corruption. > The function gcmaes_crypt_by_sg is using GFP_ATOMIC allocation that can > fail anytime. This patch fixes the logic so that it won't attempt the > failing allocation if the data doesn't cross a page boundary. > > Signed-off-by: Mikulas Patocka > Cc: sta...@vger.kernel.org Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH cryptodev] crc-t10dif: crc_t10dif_mutex can be static
On Wed, Sep 05, 2018 at 01:52:44AM +0800, kbuild test robot wrote:
>
> Fixes: b76377543b73 ("crc-t10dif: Pick better transform if one becomes
> available")
> Signed-off-by: kbuild test robot
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86/aegis,morus - Do not require OSXSAVE for SSE2
On Wed, Sep 05, 2018 at 09:26:41AM +0200, Ondrej Mosnacek wrote:
> It turns out OSXSAVE needs to be checked only for AVX, not for SSE.
> Without this patch the affected modules refuse to load on CPUs with SSE2
> but without AVX support.
>
> Fixes: 877ccce7cbe8 ("crypto: x86/aegis,morus - Fix and simplify CPUID
> checks")
> Cc: # 4.18
> Reported-by: Zdenek Kaspar
> Signed-off-by: Ondrej Mosnacek
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: padlock-aes: Add ecx to outputs for rep instructions
On Fri, Sep 07, 2018 at 02:57:42AM +0100, Ben Hutchings wrote:
> The current constraints for inline "rep xcrypt*" instructions mark ecx
> as an input only. The compiler can therefore assume wrongly that ecx
> holds the same value afterward, but in reality it will contain 0.
>
> This previously led to data corruption, which was fixed around by
> commit 46d8c4b28652 ("crypto: padlock-aes - Fix Nano workaround data
> corruption"). But a future compiler or different optimisation
> configuration could reintroduce the problem. Update the constraints
> to avoid this.
>
> Fixes: a76c1c23d0c3 ("crypto: padlock-aes - work around Nano CPU ...")
> Fixes: 46d8c4b28652 ("crypto: padlock-aes - Fix Nano workaround data ...")
> Signed-off-by: Ben Hutchings
> ---
> This is totally untested, so don't assume I know what I'm talking
> about. :-)
Could you please test it by combining this patch with a revert
of my fix to confirm that it actually works?
Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: correct obvious misspelling "cypto-controller"
On Tue, Sep 04, 2018 at 09:18:32AM -0500, Rob Herring wrote: > On Mon, Sep 3, 2018 at 10:09 PM Herbert Xu > wrote: > > > > On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote: > > > > > > Signed-off-by: Robert P. J. Day > > > > Adding Rob Herring to the cc list. > > Please resend to DT list if you want me to take it. Otherwise, > > Acked-by: Rob Herring Thanks Rob. Robert, can you resend this to the DT list? Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/chacha20 - faster 8-bit rotations and other optimizations
On Sat, Sep 01, 2018 at 12:17:07AM -0700, Eric Biggers wrote: > From: Eric Biggers > > Optimize ChaCha20 NEON performance by: > > - Implementing the 8-bit rotations using the 'vtbl.8' instruction. > - Streamlining the part that adds the original state and XORs the data. > - Making some other small tweaks. > > On ARM Cortex-A7, these optimizations improve ChaCha20 performance from > about 12.08 cycles per byte to about 11.37 -- a 5.9% improvement. > > There is a tradeoff involved with the 'vtbl.8' rotation method since > there is at least one CPU (Cortex-A53) where it's not fastest. But it > seems to be a better default; see the added comment. Overall, this > patch reduces Cortex-A53 performance by less than 0.5%. > > Signed-off-by: Eric Biggers > --- > arch/arm/crypto/chacha20-neon-core.S | 277 ++- > 1 file changed, 143 insertions(+), 134 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: arm64/crct10dif - refactor and implement non-Crypto Extension version
On Mon, Aug 27, 2018 at 05:38:10PM +0200, Ard Biesheuvel wrote: > The current arm64 CRC-T10DIF code only runs on cores that implement the > 64x64 bit PMULL instructions that are part of the optional Crypto > Extensions, and falls back to the highly inefficient C code otherwise. > > Let's provide a SIMD version that is twice as fast as the C code even on > a low end core like the Cortex-A53, and is time invariant and much easier > on the D-cache. > > Some performance numbers at the bottom. > > Ard Biesheuvel (2): > crypto: arm64/crct10dif - preparatory refactor for 8x8 PMULL version > crypto: arm64/crct10dif - implement non-Crypto Extensions alternative > > arch/arm64/crypto/crct10dif-ce-core.S | 314 +++- > arch/arm64/crypto/crct10dif-ce-glue.c | 14 +- > 2 files changed, 251 insertions(+), 77 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 1/3] crypto: Introduce notifier for new crypto algorithms
On Thu, Aug 30, 2018 at 11:00:14AM -0400, Martin K. Petersen wrote: > Introduce a facility that can be used to receive a notification > callback when a new algorithm becomes available. This can be used by > existing crypto registrations to trigger a switch from a software-only > algorithm to a hardware-accelerated version. > > A new CRYPTO_MSG_ALG_LOADED state is introduced to the existing crypto > notification chain, and the register/unregister functions are exported > so they can be called by subsystems outside of crypto. > > Signed-off-by: Martin K. Petersen > Suggested-by: Herbert Xu > --- > crypto/algapi.c | 2 ++ > crypto/algboss.c| 2 ++ > crypto/internal.h | 8 > include/crypto/algapi.h | 10 ++ > 4 files changed, 14 insertions(+), 8 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 4/4] crypto: arm64/crc32 - remove PMULL based CRC32 driver
On Mon, Aug 27, 2018 at 01:02:45PM +0200, Ard Biesheuvel wrote: > Now that the scalar fallbacks have been moved out of this driver into > the core crc32()/crc32c() routines, we are left with a CRC32 crypto API > driver for arm64 that is based only on 64x64 polynomial multiplication, > which is an optional instruction in the ARMv8 architecture, and is less > and less likely to be available on cores that do not also implement the > CRC32 instructions, given that those are mandatory in the architecture > as of ARMv8.1. > > Since the scalar instructions do not require the special handling that > SIMD instructions do, and since they turn out to be considerably faster > on some cores (Cortex-A53) as well, there is really no point in keeping > this code around so let's just remove it. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm64/aes-modes - get rid of literal load of addend vector
On Thu, Aug 23, 2018 at 05:48:45PM +0100, Ard Biesheuvel wrote: > Replace the literal load of the addend vector with a sequence that > performs each add individually. This sequence is only 2 instructions > longer than the original, and 2% faster on Cortex-A53. > > This is an improvement by itself, but also works around a Clang issue, > whose integrated assembler does not implement the GNU ARM asm syntax > completely, and does not support the =literal notation for FP registers > (more info at https://bugs.llvm.org/show_bug.cgi?id=38642) > > Cc: Nick Desaulniers > Signed-off-by: Ard Biesheuvel > --- > v2: replace convoluted code involving a SIMD add to increment four BE counters > at once with individual add/rev/mov instructions > > arch/arm64/crypto/aes-modes.S | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: arm/ghash-ce - implement support for 4-way aggregation
On Thu, Aug 23, 2018 at 03:48:51PM +0100, Ard Biesheuvel wrote: > Speed up the GHASH algorithm based on 64-bit polynomial multiplication > by adding support for 4-way aggregation. This improves throughput by > ~85% on Cortex-A53, from 1.7 cycles per byte to 0.9 cycles per byte. > > When combined with AES into GCM, throughput improves by ~25%, from > 3.8 cycles per byte to 3.0 cycles per byte. > > Signed-off-by: Ard Biesheuvel > --- > v2: modulo schedule the loads of the input > add AES/GCM performance numbers to commit log > > arch/arm/crypto/Kconfig | 1 + > arch/arm/crypto/ghash-ce-core.S | 108 +++- > arch/arm/crypto/ghash-ce-glue.c | 38 +-- > 3 files changed, 131 insertions(+), 16 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v8 0/9] crypto: Remove VLA usage
On Tue, Aug 07, 2018 at 02:18:34PM -0700, Kees Cook wrote: > v8 cover letter: > > I continue to hope this can land in v4.19, but I realize that's unlikely. > It would be nice, though, if some of the "trivial" patches could get taken > (e.g. cbc, xcbc, ccm VLA removals) so I don't have to keep repeating them. > *fingers crossed* > > Series cover letter: > > This is nearly the last of the VLA removals[1], but it's one of the > largest because crypto gets used in lots of places. After looking > through code, usage, reading the threads Gustavo started, and comparing > the use-cases to the other VLA removals that have landed in the kernel, > I think this series is likely the best way forward to shut the door on > VLAs forever. > > For background, the crypto stack usage is for callers to do an immediate > bit of work that doesn't allocate new memory. This means that other VLA > removal techniques (like just using kmalloc) aren't workable, and the > next common technique is needed: examination of maximum stack usage and > the addition of sanity checks. This series does that, and in several > cases, these maximums were already implicit in the code. > > This series is intended to land via the crypto tree for 4.19, though it > touches dm, networking, and a few other things as well, since there are > dependent patches (new crypto #defines being used, etc). I have applied patches 1-4 and 6-8. I'd like to get an ack from the dm folks regarding patch 5. As to patch 9, please fix it so it doesn't rely on the BUG_ON to catch things. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: x86 - remove SHA multibuffer routines and mcryptd
avx2.S > delete mode 100644 arch/x86/crypto/sha256-mb/sha256_x8_avx2.S > delete mode 100644 arch/x86/crypto/sha512-mb/Makefile > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb.c > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_ctx.h > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_mgr.h > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_mgr_datastruct.S > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_mb_mgr_submit_avx2.S > delete mode 100644 arch/x86/crypto/sha512-mb/sha512_x4_avx2.S > delete mode 100644 crypto/mcryptd.c > delete mode 100644 include/crypto/mcryptd.h Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH crypto-2.6] crypto: ccp: add timeout support in the SEV command
On Wed, Aug 15, 2018 at 04:11:25PM -0500, Brijesh Singh wrote: > Currently, the CCP driver assumes that the SEV command issued to the PSP > will always return (i.e. it will never hang). But recently, firmware bugs > have shown that a command can hang. Since of the SEV commands are used > in probe routines, this can cause boot hangs and/or loss of virtualization > capabilities. > > To protect against firmware bugs, add a timeout in the SEV command > execution flow. If a command does not complete within the specified > timeout then return -ETIMEOUT and stop the driver from executing any > further commands since the state of the SEV firmware is unknown. > > Cc: Tom Lendacky > Cc: Gary Hook > Cc: Herbert Xu > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Brijesh Singh > --- > drivers/crypto/ccp/psp-dev.c | 46 > +++- > 1 file changed, 41 insertions(+), 5 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: atmel - switch to SPDX license identifiers
On Tue, Aug 21, 2018 at 04:36:09PM +0300, Tudor Ambarus wrote: > Adopt the SPDX license identifiers to ease license compliance > management. > > Signed-off-by: Tudor Ambarus > --- > drivers/crypto/atmel-aes.c | 5 + > drivers/crypto/atmel-authenc.h | 13 + > drivers/crypto/atmel-ecc.c | 11 +-- > drivers/crypto/atmel-ecc.h | 14 +- > drivers/crypto/atmel-sha.c | 5 + > drivers/crypto/atmel-tdes.c| 5 + > 6 files changed, 6 insertions(+), 47 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: remove Speck
On Tue, Aug 07, 2018 at 08:22:25AM +0200, Jason A. Donenfeld wrote: > These are unused, undesired, and have never actually been used by > anybody. The original authors of this code have changed their mind about > its inclusion. While originally proposed for disk encryption on low-end > devices, the idea was discarded [1] in favor of something else before > that could really get going. Therefore, this patch removes Speck. > > [1] https://marc.info/?l=linux-crypto-vger=153359499015659 > > Signed-off-by: Jason A. Donenfeld > Acked-by: Eric Biggers > Cc: sta...@vger.kernel.org > --- > Documentation/filesystems/fscrypt.rst | 10 - > arch/arm/crypto/Kconfig | 6 - > arch/arm/crypto/Makefile | 2 - > arch/arm/crypto/speck-neon-core.S | 434 --- > arch/arm/crypto/speck-neon-glue.c | 288 -- > arch/arm64/crypto/Kconfig | 6 - > arch/arm64/crypto/Makefile| 3 - > arch/arm64/crypto/speck-neon-core.S | 352 > arch/arm64/crypto/speck-neon-glue.c | 282 -- > arch/m68k/configs/amiga_defconfig | 1 - > arch/m68k/configs/apollo_defconfig| 1 - > arch/m68k/configs/atari_defconfig | 1 - > arch/m68k/configs/bvme6000_defconfig | 1 - > arch/m68k/configs/hp300_defconfig | 1 - > arch/m68k/configs/mac_defconfig | 1 - > arch/m68k/configs/multi_defconfig | 1 - > arch/m68k/configs/mvme147_defconfig | 1 - > arch/m68k/configs/mvme16x_defconfig | 1 - > arch/m68k/configs/q40_defconfig | 1 - > arch/m68k/configs/sun3_defconfig | 1 - > arch/m68k/configs/sun3x_defconfig | 1 - > arch/s390/defconfig | 1 - > crypto/Kconfig| 14 - > crypto/Makefile | 1 - > crypto/speck.c| 307 --- > crypto/testmgr.c | 24 - > crypto/testmgr.h | 738 -- > fs/crypto/fscrypt_private.h | 4 - > fs/crypto/keyinfo.c | 10 - > include/crypto/speck.h| 62 --- > include/uapi/linux/fs.h | 4 +- > 31 files changed, 2 insertions(+), 2558 deletions(-) > delete mode 100644 arch/arm/crypto/speck-neon-core.S > delete mode 100644 arch/arm/crypto/speck-neon-glue.c > delete mode 100644 arch/arm64/crypto/speck-neon-core.S > delete mode 100644 arch/arm64/crypto/speck-neon-glue.c > delete mode 100644 crypto/speck.c > delete mode 100644 include/crypto/speck.h Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: caam - ablkcipher -> skcipher conversion
On Mon, Aug 06, 2018 at 03:43:56PM +0300, Horia Geantă wrote: > This patch set converts caam/jr and caam/qi top level drivers > from ablkcipher API to skcipher. > > First two patches remove the unused ablkcipher algorithms with > support for IV generation. > The following two patches deal with the conversion. > > Note: There is a dependency for the patch set - a fix sent separately: > "crypto: caam/qi - fix error path in xts setkey" > https://patchwork.kernel.org/patch/10557015 > > Horia Geantă (4): > crypto: caam/jr - remove ablkcipher IV generation > crypto: caam/qi - remove ablkcipher IV generation > crypto: caam/jr - ablkcipher -> skcipher conversion > crypto: caam/qi - ablkcipher -> skcipher conversion > > drivers/crypto/caam/caamalg.c | 729 > +++-- > drivers/crypto/caam/caamalg_desc.c | 142 ++-- > drivers/crypto/caam/caamalg_desc.h | 28 +- > drivers/crypto/caam/caamalg_qi.c | 626 ++- > drivers/crypto/caam/compat.h | 1 + > drivers/crypto/caam/qi.h | 1 - > 6 files changed, 449 insertions(+), 1078 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: correct obvious misspelling "cypto-controller"
On Mon, Aug 06, 2018 at 07:48:52AM -0400, Robert P. J. Day wrote:
>
> Signed-off-by: Robert P. J. Day
Adding Rob Herring to the cc list.
>
> ---
>
> diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> index 5e2ba385b8c9..53e39d5f94e7 100644
> --- a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> +++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> @@ -16,7 +16,7 @@ Required properties:
>
> Examples:
>
> - crypto: cypto-controller@ff8a {
> + crypto: crypto-controller@ff8a {
> compatible = "rockchip,rk3288-crypto";
> reg = <0xff8a 0x4000>;
> interrupts = ;
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index d7e49d29ace5..dcfdb2c0d206 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -942,7 +942,7 @@
> status = "disabled";
> };
>
> - crypto: cypto-controller@ff8a {
> + crypto: crypto-controller@ff8a {
> compatible = "rockchip,rk3288-crypto";
> reg = <0x0 0xff8a 0x0 0x4000>;
> interrupts = ;
>
> rday
>
> --
>
>
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca/dokuwiki
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
>
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Backport e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback
On Sun, Aug 26, 2018 at 08:12:06AM +0200, Greg KH wrote: > > The patch didn't apply, but I fixed it :) > > Now queued up. Thanks Greg! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/aes-gcm-ce - fix scatterwalk API violation
On Mon, Aug 20, 2018 at 04:58:34PM +0200, Ard Biesheuvel wrote:
> Commit 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on
> two input blocks at a time") modified the granularity at which
> the AES/GCM code processes its input to allow subsequent changes
> to be applied that improve performance by using aggregation to
> process multiple input blocks at once.
>
> For this reason, it doubled the algorithm's 'chunksize' property
> to 2 x AES_BLOCK_SIZE, but retained the non-SIMD fallback path that
> processes a single block at a time. In some cases, this violates the
> skcipher scatterwalk API, by calling skcipher_walk_done() with a
> non-zero residue value for a chunk that is expected to be handled
> in its entirety. This results in a WARN_ON() to be hit by the TLS
> self test code, but is likely to break other user cases as well.
> Unfortunately, none of the current test cases exercises this exact
> code path at the moment.
>
> Fixes: 71e52c278c54 ("crypto: arm64/aes-ce-gcm - operate on two ...")
> Reported-by: Vakul Garg
> Signed-off-by: Ard Biesheuvel
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/sm4-ce - check for the right CPU feature bit
On Tue, Aug 07, 2018 at 11:18:36PM +0200, Ard Biesheuvel wrote: > ARMv8.2 specifies special instructions for the SM3 cryptographic hash > and the SM4 symmetric cipher. While it is unlikely that a core would > implement one and not the other, we should only use SM4 instructions > if the SM4 CPU feature bit is set, and we currently check the SM3 > feature bit instead. So fix that. > > Signed-off-by: Ard Biesheuvel Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam/qi - fix error path in xts setkey
On Mon, Aug 06, 2018 at 03:29:39PM +0300, Horia Geantă wrote:
> xts setkey callback returns 0 on some error paths.
> Fix this by returning -EINVAL.
>
> Cc: # 4.12+
> Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc
> algorithms")
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam - fix DMA mapping direction for RSA forms 2 & 3
On Mon, Aug 06, 2018 at 03:29:55PM +0300, Horia Geantă wrote:
> Crypto engine needs some temporary locations in external memory for
> running RSA decrypt forms 2 and 3 (CRT).
> These are named "tmp1" and "tmp2" in the PDB.
>
> Update DMA mapping direction of tmp1 and tmp2 from TO_DEVICE to
> BIDIRECTIONAL, since engine needs r/w access.
>
> Cc: # 4.13+
> Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
> Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3")
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: caam/jr - fix descriptor DMA unmapping
On Mon, Aug 06, 2018 at 03:29:09PM +0300, Horia Geantă wrote:
> Descriptor address needs to be swapped to CPU endianness before being
> DMA unmapped.
>
> Cc: # 4.8+
> Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam
> endianness")
> Reported-by: Laurentiu Tudor
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] chtls_cm.c: fix missing return value check of alloc_skb()
Jiecheng Wu wrote: > Function chtls_close_conn() defined in > drivers/crypto/chelsio/chtls/chtls_cm.c calls alloc_skb() to allocate memory > for struct sk_buff which is dereferenced immediately. As alloc_skb() may > return NULL on failure, this code piece may cause NULL pointer dereference > bug. Please add a sign-off. You can refer to Documentation/process/submitting-patches.rst Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RESEND PATCH 2/2] crypto: caam - Support deferred probing in JR dependent drivers
On Tue, Aug 07, 2018 at 12:34:57PM +, Horia Geanta wrote:
> On 8/7/2018 11:00 AM, Marcin Niestroj wrote:
> > It is possible, that caam_jr_alloc() is called before JR devices are
> > probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
> > they are probed at later stage.
> >
> These drivers don't have a probe() callback.
> Returning -EPROBE_DEFER in module's init() (caamrng) or crypto algorithm's
> init() (caamalg etc.) callbacks is not going to help, they won't be called
> later.
>
> Does adding request_module("caam_jr") in module's init() solve the issue?
If everything is built as a module this should always work because
a module isn't available until after its init function has finished.
So the only problem here appears to be when everything is built-in
in which case the init functions are run in random order.
So perhaps move caam_jr's module_init function to an earlier level
(i.e., earlier than device_initcall)?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Backport e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback
On Thu, Aug 23, 2018 at 05:31:01PM +0200, Petr Vorel wrote:
> Hi,
>
> I wonder, it it makes sense to backport commit
> e666d4e9ceec crypto: vmx - Use skcipher for ctr fallback
> to v 4.14 stable kernel.
> I'm using it in 4.12+.
>
> These commits (somehow similar) has been backported to 4.10.2:
> 5839f555fa57 crypto: vmx - Use skcipher for xts fallback
> c96d0a1c47ab crypto: vmx - Use skcipher for cbc fallback
I think so. Here is the patch which should be applied for all
kernels since 4.10 up to and including 4.14:
commit e666d4e9ceec94c0a88c94b7db31d56474da43b3
Author: Paulo Flabiano Smorigo
Date: Mon Oct 16 20:54:19 2017 -0200
crypto: vmx - Use skcipher for ctr fallback
Signed-off-by: Paulo Flabiano Smorigo
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/vmx/aes_ctr.c b/drivers/crypto/vmx/aes_ctr.c
index 17d8421..fc60d00 100644
--- a/drivers/crypto/vmx/aes_ctr.c
+++ b/drivers/crypto/vmx/aes_ctr.c
@@ -27,21 +27,23 @@
#include
#include
#include
+#include
+
#include "aesp8-ppc.h"
struct p8_aes_ctr_ctx {
- struct crypto_blkcipher *fallback;
+ struct crypto_skcipher *fallback;
struct aes_key enc_key;
};
static int p8_aes_ctr_init(struct crypto_tfm *tfm)
{
const char *alg = crypto_tfm_alg_name(tfm);
- struct crypto_blkcipher *fallback;
+ struct crypto_skcipher *fallback;
struct p8_aes_ctr_ctx *ctx = crypto_tfm_ctx(tfm);
- fallback =
- crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
+ fallback = crypto_alloc_skcipher(alg, 0,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback)) {
printk(KERN_ERR
"Failed to allocate transformation for '%s': %ld\n",
@@ -49,11 +51,11 @@ static int p8_aes_ctr_init(struct crypto_tfm *tfm)
return PTR_ERR(fallback);
}
printk(KERN_INFO "Using '%s' as fallback implementation.\n",
- crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
+ crypto_skcipher_driver_name(fallback));
- crypto_blkcipher_set_flags(
+ crypto_skcipher_set_flags(
fallback,
- crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
+ crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
ctx->fallback = fallback;
return 0;
@@ -64,7 +66,7 @@ static void p8_aes_ctr_exit(struct crypto_tfm *tfm)
struct p8_aes_ctr_ctx *ctx = crypto_tfm_ctx(tfm);
if (ctx->fallback) {
- crypto_free_blkcipher(ctx->fallback);
+ crypto_free_skcipher(ctx->fallback);
ctx->fallback = NULL;
}
}
@@ -83,7 +85,7 @@ static int p8_aes_ctr_setkey(struct crypto_tfm *tfm, const u8
*key,
pagefault_enable();
preempt_enable();
- ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
+ ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
return ret;
}
@@ -117,15 +119,14 @@ static int p8_aes_ctr_crypt(struct blkcipher_desc *desc,
struct blkcipher_walk walk;
struct p8_aes_ctr_ctx *ctx =
crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
- struct blkcipher_desc fallback_desc = {
- .tfm = ctx->fallback,
- .info = desc->info,
- .flags = desc->flags
- };
if (in_interrupt()) {
- ret = crypto_blkcipher_encrypt(_desc, dst, src,
- nbytes);
+ SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
+ skcipher_request_set_tfm(req, ctx->fallback);
+ skcipher_request_set_callback(req, desc->flags, NULL, NULL);
+ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+ ret = crypto_skcipher_encrypt(req);
+ skcipher_request_zero(req);
} else {
blkcipher_walk_init(, dst, src, nbytes);
ret = blkcipher_walk_virt_block(desc, , AES_BLOCK_SIZE);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] crypto: hisilicon - Make function sec_send_request() static
On Wed, Aug 08, 2018 at 04:30:09AM +, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/crypto/hisilicon/sec/sec_algs.c:396:5: warning:
> symbol 'sec_send_request' was not declared. Should it be static?
>
> Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
> Signed-off-by: Wei Yongjun
This is already fixed in the current tree.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH cryptodev] crypto: sec_send_request() can be static
On Sat, Aug 04, 2018 at 06:21:01AM +0800, kbuild test robot wrote:
>
> Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
> Signed-off-by: kbuild test robot
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: arm64/ghash-ce - performance improvements
On Sat, Aug 04, 2018 at 08:46:23PM +0200, Ard Biesheuvel wrote: > Another bit of performance work on the GHASH driver: this time it is not > the combined AES/GCM algorithm but the bare GHASH driver that gets updated. > > Even though ARM cores that implement the polynomical multiplication > instructions that these routines depend on are guaranteed to also support > the AES instructions, and can thus use the AES/GCM driver, there could > be reasons to use the accelerated GHASH in isolation, e.g., with another > symmetric blockcipher, with a faster h/w accelerator, or potentially with > an accelerator that does not expose the AES key to the OS. > > The resulting code runs at 1.1 cycles per byte on Cortex-A53 (down from > 2.4 cycles per byte) > > Ard Biesheuvel (2): > crypto: arm64/ghash-ce - replace NEON yield check with block limit > crypto: arm64/ghash-ce - implement 4-way aggregation > > arch/arm64/crypto/ghash-ce-core.S | 153 ++-- > arch/arm64/crypto/ghash-ce-glue.c | 87 ++- > 2 files changed, 161 insertions(+), 79 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: x86/aegis,morus - Fix and simplify CPUID checks
On Fri, Aug 03, 2018 at 01:37:50PM +0200, Ondrej Mosnacek wrote:
> It turns out I had misunderstood how the x86_match_cpu() function works.
> It evaluates a logical OR of the matching conditions, not logical AND.
> This caused the CPU feature checks for AEGIS to pass even if only SSE2
> (but not AES-NI) was supported (or vice versa), leading to potential
> crashes if something tried to use the registered algs.
>
> This patch switches the checks to a simpler method that is used e.g. in
> the Camellia x86 code.
>
> The patch also removes the MODULE_DEVICE_TABLE declarations which
> actually seem to cause the modules to be auto-loaded at boot, which is
> not desired. The crypto API on-demand module loading is sufficient.
>
> Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations")
> Fixes: 6ecc9d9ff91f ("crypto: x86 - Add optimized MORUS implementations")
> Signed-off-by: Ondrej Mosnacek
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64 - revert NEON yield for fast AEAD implementations
On Sun, Jul 29, 2018 at 04:52:30PM +0200, Ard Biesheuvel wrote:
> As it turns out, checking the TIF_NEED_RESCHED flag after each
> iteration results in a significant performance regression (~10%)
> when running fast algorithms (i.e., ones that use special instructions
> and operate in the < 4 cycles per byte range) on in-order cores with
> comparatively slow memory accesses such as the Cortex-A53.
>
> Given the speed of these ciphers, and the fact that the page based
> nature of the AEAD scatterwalk API guarantees that the core NEON
> transform is never invoked with more than a single page's worth of
> input, we can estimate the worst case duration of any resulting
> scheduling blackout: on a 1 GHz Cortex-A53 running with 64k pages,
> processing a page's worth of input at 4 cycles per byte results in
> a delay of ~250 us, which is a reasonable upper bound.
>
> So let's remove the yield checks from the fused AES-CCM and AES-GCM
> routines entirely.
>
> This reverts commit 7b67ae4d5ce8e2f912377f5fbccb95811a92097f and
> partially reverts commit 7c50136a8aba8784f07fb66a950cc61a7f3d2ee3.
>
> Fixes: 7c50136a8aba ("crypto: arm64/aes-ghash - yield NEON after every ...")
> Fixes: 7b67ae4d5ce8 ("crypto: arm64/aes-ccm - yield NEON after every ...")
> Signed-off-by: Ard Biesheuvel
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/3] crypto/arm64: aes-ce-gcm - switch to 2-way aggregation
On Mon, Jul 30, 2018 at 11:06:39PM +0200, Ard Biesheuvel wrote: > Update the combined AES-GCM AEAD implementation to process two blocks > at a time, allowing us to switch to a faster version of the GHASH > implementation. > > Note that this does not update the core GHASH transform, only the > combined AES-GCM AEAD mode. GHASH is mostly used with AES anyway, and > the ARMv8 architecture mandates support for AES instructions if > 64-bit polynomial multiplication instructions are implemented. This > means that mosts users of the pmull.p64 based GHASH routines are better > off using the combined AES-GCM code anyway. Users of the pmull.p8 based > GHASH implementation are unlikely to benefit substantially from aggregation, > given that the multiplication phase is much more dominant in this case > (and it is only the reduction phase that is amortized over multiple > blocks) > > Performance numbers for Cortex-A53 can be found after patches #2 and #3. > > Changes since v1: > - rebase to take the changes in patch 'crypto: arm64 - revert NEON yield for > fast AEAD implementations' which I sent out on July 29th > - add a patch to reduce the number of invocations of kernel_neon_begin() > and kernel_neon_end() on the common path > > Ard Biesheuvel (3): > crypto/arm64: aes-ce-gcm - operate on two input blocks at a time > crypto/arm64: aes-ce-gcm - implement 2-way aggregation > crypto: arm64/aes-ce-gcm - don't reload key schedule if avoidable > > arch/arm64/crypto/ghash-ce-core.S | 136 +-- > arch/arm64/crypto/ghash-ce-glue.c | 176 > 2 files changed, 198 insertions(+), 114 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 1/2] crypto: dh - fix calculating encoded key size
On Fri, Jul 27, 2018 at 03:36:10PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> It was forgotten to increase DH_KPP_SECRET_MIN_SIZE to include 'q_size',
> causing an out-of-bounds write of 4 bytes in crypto_dh_encode_key(), and
> an out-of-bounds read of 4 bytes in crypto_dh_decode_key(). Fix it, and
> fix the lengths of the test vectors to match this.
>
> Reported-by: syzbot+6d38d558c25b53b8f...@syzkaller.appspotmail.com
> Fixes: e3fe0ae12962 ("crypto: dh - add public key verification test")
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ccp: Check for NULL PSP pointer at module unload
Tom Lendacky wrote:
> Should the PSP initialization fail, the PSP data structure will be
> freed and the value contained in the sp_device struct set to NULL.
> At module unload, psp_dev_destroy() does not check if the pointer
> value is NULL and will end up dereferencing a NULL pointer.
>
> Add a pointer check of the psp_data field in the sp_device struct
> in psp_dev_destroy() and return immediately if it is NULL.
>
> Cc: # 4.16.x-
> Fixes: 2a6170dfe755 ("crypto: ccp: Add Platform Security Processor (PSP)
> device support")
> Signed-off-by: Tom Lendacky
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 2/2] crypto: dh - make crypto_dh_encode_key() make robust
On Fri, Jul 27, 2018 at 03:36:11PM -0700, Eric Biggers wrote: > From: Eric Biggers > > Make it return -EINVAL if crypto_dh_key_len() is incorrect rather than > overflowing the buffer. > > Signed-off-by: Eric Biggers Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm/chacha20 - always use vrev for 16-bit rotates
On Tue, Jul 24, 2018 at 06:29:07PM -0700, Eric Biggers wrote: > From: Eric Biggers > > The 4-way ChaCha20 NEON code implements 16-bit rotates with vrev32.16, > but the one-way code (used on remainder blocks) implements it with > vshl + vsri, which is slower. Switch the one-way code to vrev32.16 too. > > Signed-off-by: Eric Biggers Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/3] crypto: fix crash in scatterwalk_pagedone()
On Mon, Jul 23, 2018 at 10:54:55AM -0700, Eric Biggers wrote: > From: Eric Biggers > > This series fixes the bug reported by Liu Chao (found using syzkaller) > where a crash occurs in scatterwalk_pagedone() on architectures such as > arm and arm64 that implement flush_dcache_page(), due to an invalid page > pointer when walk->offset == 0. This series attempts to address the > underlying problem which is that scatterwalk_pagedone() shouldn't have > been called at all in that case. > > Eric Biggers (3): > crypto: skcipher - fix crash flushing dcache in error path > crypto: blkcipher - fix crash flushing dcache in error path > crypto: ablkcipher - fix crash flushing dcache in error path > > crypto/ablkcipher.c | 57 + > crypto/blkcipher.c | 54 +- > crypto/skcipher.c | 53 - > 3 files changed, 79 insertions(+), 85 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: skcipher - remove unnecessary setting of walk->nbytes
On Mon, Jul 23, 2018 at 10:21:29AM -0700, Eric Biggers wrote: > From: Eric Biggers > > Setting 'walk->nbytes = walk->total' in skcipher_walk_first() doesn't > make sense because actually walk->nbytes needs to be set to the length > of the first step in the walk, which may be less than walk->total. This > is done by skcipher_walk_next() which is called immediately afterwards. > Also walk->nbytes was already set to 0 in skcipher_walk_skcipher(), > which is a better default value in case it's forgotten to be set later. > > Therefore, remove the unnecessary assignment to walk->nbytes. > > Signed-off-by: Eric Biggers Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: scatterwalk - remove scatterwalk_samebuf()
On Mon, Jul 23, 2018 at 10:04:28AM -0700, Eric Biggers wrote: > From: Eric Biggers > > scatterwalk_samebuf() is never used. Remove it. > > Signed-off-by: Eric Biggers Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: skcipher - fix aligning block size in skcipher_copy_iv()
On Mon, Jul 23, 2018 at 09:57:50AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The ALIGN() macro needs to be passed the alignment, not the alignmask
> (which is the alignment minus 1).
>
> Fixes: b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface")
> Cc: # v4.10+
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: scatterwalk - remove 'chain' argument from scatterwalk_crypto_chain()
On Mon, Jul 23, 2018 at 10:01:33AM -0700, Eric Biggers wrote: > From: Eric Biggers > > All callers pass chain=0 to scatterwalk_crypto_chain(). > > Remove this unneeded parameter. > > Signed-off-by: Eric Biggers Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: tcrypt - reschedule during speed tests
On Mon, Jul 23, 2018 at 05:18:48PM +0300, Horia Geantă wrote: > Avoid RCU stalls in the case of non-preemptible kernel and lengthy > speed tests by rescheduling when advancing from one block size > to another. > > Signed-off-by: Horia Geantă Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V2 0/3] Hisilicon SEC crypto driver (hip06 / hip07)
On Mon, Jul 23, 2018 at 04:49:52PM +0100, Jonathan Cameron wrote: > The driver provides in kernel support for the Hisilicon SEC accelerator > found in the hip06 and hip07 SoCs. There are 4 such units on the D05 > board for which an appropriate DT binding has been provided. ACPI also > works with an appropriate UEFI build. > > The hardware does not update the IV in chaining or counting modes. > This is done in the drive ron completion of the cipher operation. > > The driver support AES, DES and 3DES block ciphers in a range of > modes (others to follow). Hash and AAED support to follow. > > Sorry for the delay on this one, other priorities and all that... > > Changes since V1. > 1) DT binding fixes suggested by Rob Herring in patches 1 and 3. > 2) Added XTS key check as suggested by Stephan Muller. > 3) A trivial use after free found during testing of the above. > > Changes since RFC. > 1) Addition of backlog queuing as needed to support dm-crypt usecases. > 2) iommu presence tests now done as Robin Murphy suggested. > 3) Hardware limiation to 32MB requests worked aroud in driver so it will >now support very large requests (512*32MB). Larger request handling >than this would require a longer queue with the associate overheads and >is considered unlikely to be necessary. > 4) The specific handling related to the inline IV patch set from Stephan >has been dropped for now. > 5) Interrupt handler was previous more complex than necessary so has been >reworked. > 6) Use of the bounce buffer for small packeets is dropped for now. This is a >performance optimization that made the code harder to review and can be >reintroduced as necessary at a later date. > 7) Restructuring of some code to simplify hash and aaed (hash implemented >but not ready fo upstream at this time) > 8) Various minor fixes and reworks of the code >* several off by one errors in the cleanup paths >* single template for enc and dec >* drop dec_key as not used (enc_key was used in both cases) >* drop dma pool for IVs as it breaks chaining. >* lots of spinlocks changed to mutexes as not taken in atomic context. >* nasty memory leak cleaned up. > > Jonathan Cameron (3): > dt-bindings: Add bindings for Hisilicon SEC crypto accelerators. > crypto: hisilicon SEC security accelerator driver > arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC > > .../bindings/crypto/hisilicon,hip07-sec.txt| 67 + > arch/arm64/boot/dts/hisilicon/hip07.dtsi | 284 + > drivers/crypto/Kconfig |2 + > drivers/crypto/Makefile|1 + > drivers/crypto/hisilicon/Kconfig | 14 + > drivers/crypto/hisilicon/Makefile |2 + > drivers/crypto/hisilicon/sec/Makefile |3 + > drivers/crypto/hisilicon/sec/sec_algs.c| 1122 + > drivers/crypto/hisilicon/sec/sec_drv.c | 1323 > > drivers/crypto/hisilicon/sec/sec_drv.h | 428 +++ > 10 files changed, 3246 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/crypto/hisilicon,hip07-sec.txt > create mode 100644 drivers/crypto/hisilicon/Kconfig > create mode 100644 drivers/crypto/hisilicon/Makefile > create mode 100644 drivers/crypto/hisilicon/sec/Makefile > create mode 100644 drivers/crypto/hisilicon/sec/sec_algs.c > create mode 100644 drivers/crypto/hisilicon/sec/sec_drv.c > create mode 100644 drivers/crypto/hisilicon/sec/sec_drv.h All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: CTR DRBG - in-place cipher operation
On Fri, Jul 20, 2018 at 07:42:01PM +0200, Stephan Müller wrote: > The cipher implementations of the kernel crypto API favor in-place > cipher operations. Thus, switch the CTR cipher operation in the DRBG to > perform in-place operations. This is implemented by using the output > buffer as input buffer and zeroizing it before the cipher operation to > implement a CTR encryption of a NULL buffer. > > The speed improvement is quite visibile with the following comparison > using the LRNG implementation. > > Without the patch set: > > 16 bytes| 12.267661 MB/s|61338304 bytes | 500213 ns > 32 bytes| 23.603770 MB/s| 118018848 bytes | 500073 ns > 64 bytes| 46.732262 MB/s| 233661312 bytes | 500241 ns > 128 bytes| 90.038042 MB/s| 450190208 bytes | 500244 ns > 256 bytes| 160.399616 MB/s| 801998080 bytes | 500393 ns > 512 bytes| 259.878400 MB/s| 1299392000 bytes | 501675 ns > 1024 bytes| 386.050662 MB/s| 1930253312 bytes | 501661 ns > 2048 bytes| 493.641728 MB/s| 2468208640 bytes | 501598 ns > 4096 bytes| 581.835981 MB/s| 2909179904 bytes | 503426 ns > > With the patch set: > > 16 bytes | 17.051142 MB/s | 85255712 bytes | 500854 ns > 32 bytes | 32.695898 MB/s |163479488 bytes | 500544 ns > 64 bytes | 64.490739 MB/s |322453696 bytes | 500954 ns > 128 bytes |123.285043 MB/s |616425216 bytes | 500201 ns > 256 bytes |233.434573 MB/s | 1167172864 bytes | 500573 ns > 512 bytes |384.405197 MB/s | 1922025984 bytes | 500671 ns > 1024 bytes |566.313370 MB/s | 2831566848 bytes | 501080 ns > 2048 bytes |744.518042 MB/s | 3722590208 bytes | 500926 ns > 4096 bytes |867.501670 MB/s | 4337508352 bytes | 502181 ns > > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64 - revert NEON yield for fast AEAD implementations
On Fri, Aug 03, 2018 at 09:10:08AM +0200, Ard Biesheuvel wrote: > But I think it's too late now to take this into v4.18. Could you > please queue this (and my other two pending arm64/aes-gcm patches, if > possible) for v4.19 instead? OK I'll do that. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64 - revert NEON yield for fast AEAD implementations
On Sun, Jul 29, 2018 at 04:52:30PM +0200, Ard Biesheuvel wrote:
> As it turns out, checking the TIF_NEED_RESCHED flag after each
> iteration results in a significant performance regression (~10%)
> when running fast algorithms (i.e., ones that use special instructions
> and operate in the < 4 cycles per byte range) on in-order cores with
> comparatively slow memory accesses such as the Cortex-A53.
>
> Given the speed of these ciphers, and the fact that the page based
> nature of the AEAD scatterwalk API guarantees that the core NEON
> transform is never invoked with more than a single page's worth of
> input, we can estimate the worst case duration of any resulting
> scheduling blackout: on a 1 GHz Cortex-A53 running with 64k pages,
> processing a page's worth of input at 4 cycles per byte results in
> a delay of ~250 us, which is a reasonable upper bound.
>
> So let's remove the yield checks from the fused AES-CCM and AES-GCM
> routines entirely.
>
> This reverts commit 7b67ae4d5ce8e2f912377f5fbccb95811a92097f and
> partially reverts commit 7c50136a8aba8784f07fb66a950cc61a7f3d2ee3.
>
> Fixes: 7c50136a8aba ("crypto: arm64/aes-ghash - yield NEON after every ...")
> Fixes: 7b67ae4d5ce8 ("crypto: arm64/aes-ccm - yield NEON after every ...")
> Signed-off-by: Ard Biesheuvel
> ---
> This supersedes my series 'crypto/arm64: reduce impact of NEON yield checks'
> sent out on the 24th of July.
>
> Given the significant performance regression, we may want to treat this as
> a fix (the patches in question went into v4.18)
>
> This patch applies onto my patch 'crypto/arm64: aes-ce-gcm - add missing
> kernel_neon_begin/end pair' which I sent out on the 27th of July, which
> fixes a data corruption bug, whic should also be applied as a fix.
Acked-by: Herbert Xu
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto/arm64: aes-ce-gcm - add missing kernel_neon_begin/end pair
On Tue, Jul 31, 2018 at 09:47:28AM +0100, Will Deacon wrote:
> On Tue, Jul 31, 2018 at 09:22:52AM +0200, Ard Biesheuvel wrote:
> > (+ Catalin, Will)
> >
> > On 27 July 2018 at 14:59, Ard Biesheuvel wrote:
> > > Calling pmull_gcm_encrypt_block() requires kernel_neon_begin() and
> > > kernel_neon_end() to be used since the routine touches the NEON
> > > register file. Add the missing calls.
> > >
> > > Also, since NEON register contents are not preserved outside of
> > > a kernel mode NEON region, pass the key schedule array again.
> > >
> > > Fixes: 7c50136a8aba ("crypto: arm64/aes-ghash - yield NEON after every
> > > ...")
> > > Signed-off-by: Ard Biesheuvel
> > > ---
> > > arch/arm64/crypto/ghash-ce-glue.c | 8 ++--
> > > 1 file changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm64/crypto/ghash-ce-glue.c
> > > b/arch/arm64/crypto/ghash-ce-glue.c
> > > index 7cf0b1aa6ea8..8a10f1d7199a 100644
> > > --- a/arch/arm64/crypto/ghash-ce-glue.c
> > > +++ b/arch/arm64/crypto/ghash-ce-glue.c
> > > @@ -488,9 +488,13 @@ static int gcm_decrypt(struct aead_request *req)
> > > err = skcipher_walk_done(,
> > > walk.nbytes %
> > > AES_BLOCK_SIZE);
> > > }
> > > - if (walk.nbytes)
> > > - pmull_gcm_encrypt_block(iv, iv, NULL,
> > > + if (walk.nbytes) {
> > > + kernel_neon_begin();
> > > + pmull_gcm_encrypt_block(iv, iv,
> > > ctx->aes_key.key_enc,
> > >
> > > num_rounds(>aes_key));
> > > + kernel_neon_end();
> > > + }
> > > +
> > > } else {
> > > __aes_arm64_encrypt(ctx->aes_key.key_enc, tag, iv,
> > > num_rounds(>aes_key));
> > > --
> > > 2.18.0
> > >
> >
> > This fixes a rather nasty bug in the AES-GCM code: failing to call
> > kernel_neon_begin()/_end() may clobber the NEON register state of
> > unrelated userland processes.
> >
> > Could we please get this queued before v4.18 is released? Thanks.
>
> I can take this via the arm64 tree if Herbert is ok with that.
Sure:
Acked-by: Herbert Xu
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: arm64/sha256 - increase cra_priority of scalar implementations
On Tue, Jul 17, 2018 at 10:09:26AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Commit b73b7ac0a774 ("crypto: sha256_generic - add cra_priority") gave
> sha256-generic and sha224-generic a cra_priority of 100, to match the
> convention for generic implementations. But sha256-arm64 and
> sha224-arm64 also have priority 100, so their order relative to the
> generic implementations became ambiguous.
>
> Therefore, increase their priority to 125 so that they have higher
> priority than the generic implementations but lower priority than the
> NEON implementations which have priority 150.
>
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v6 0/6] crypto: Add Qcom PRNG support
On Mon, Jul 16, 2018 at 11:20:21AM +0530, Vinod Koul wrote:
> This series removes the hwrng qcom driver and replaces it with crypto qcom
> driver and then adds support for Execution Environment (EE) found in v2
> version of the hardware and ACPI support for these
>
> Changes in v6:
> - Fix a typo in kconfig. Remove of_device.h and add of.h header
> - Add review and tested tags
>
> Changes in v5:
> - Update ACPI check and use generic driver data API
>
> Changes in v4:
> - Use memcpy for data copy
> - Fix trailing bytes copy
> - Fix ACPI ID table name
>
> Timur Tabi (1):
> crypto: qcom: Add ACPI support
>
> Vinod Koul (5):
> hwrng: remove msm hw_random driver
> dt-bindings: crypto: Move prng binding to crypto
> crypto: Add Qcom prng driver
> dt-bindings: crypto: Add new compatible qcom,prng-ee
> crypto: qcom: Add support for prng-ee
>
> .../bindings/{rng => crypto}/qcom,prng.txt | 4 +-
> drivers/char/hw_random/Kconfig | 13 --
> drivers/char/hw_random/Makefile| 1 -
> drivers/char/hw_random/msm-rng.c | 183
> drivers/crypto/Kconfig | 11 +
> drivers/crypto/Makefile| 1 +
> drivers/crypto/qcom-rng.c | 229
> +
> 7 files changed, 244 insertions(+), 198 deletions(-)
> rename Documentation/devicetree/bindings/{rng => crypto}/qcom,prng.txt (73%)
> delete mode 100644 drivers/char/hw_random/msm-rng.c
> create mode 100644 drivers/crypto/qcom-rng.c
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: CTR DRBG - in-place cipher operation
On Fri, Jul 27, 2018 at 01:49:08PM +0200, Stephan Mueller wrote: > > This is guaranteed by the invokers of drbg_kcapi_sym_ctr as there are two > only: > > - the one in drbg_ctr_update uses the scratchpad for inbuf > > - the one in drbg_ctr_generate uses NULL which implies that the outscratchpad > is used. I see. I missed the fact that the buffer provided by the user is the output buffer and not the input buffer. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: CTR DRBG - in-place cipher operation
On Fri, Jul 20, 2018 at 07:42:01PM +0200, Stephan Müller wrote:
>
> @@ -1747,10 +1733,18 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
> u8 *outbuf, u32 outlen)
> {
> struct scatterlist *sg_in = >sg_in, *sg_out = >sg_out;
> + u32 scratchpad_use = min_t(u32, outlen, DRBG_OUTSCRATCHLEN);
> int ret;
>
> - sg_set_buf(sg_in, inbuf, inlen);
> - sg_set_buf(sg_out, drbg->outscratchpad, DRBG_OUTSCRATCHLEN);
> + if (inbuf) {
> + /* Use caller-provided input buffer */
> + sg_set_buf(sg_in, inbuf, inlen);
> + } else {
> + /* Use scratchpad for in-place operation */
> + inlen = scratchpad_use;
> + memset(drbg->outscratchpad, 0, scratchpad_use);
> + sg_set_buf(sg_in, drbg->outscratchpad, scratchpad_use);
> + }
What guarantees that inbuf isn't on the stack?
I think rather than doing this we need to fix the existing code
to copy inbuf onto the scratch pad and then do in-place operation
on that.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: DH - update test for public key verification
On Wed, Jul 11, 2018 at 08:35:49PM +0200, Stephan Müller wrote: > By adding a zero byte-length for the DH parameter Q value, the public > key verification test is disabled for the given test. > > Reported-by: Eric Biggers > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: sharah: Unregister correct algorithms for SAHARA 3
On Sun, Jul 15, 2018 at 12:27:06AM +0200, Michael Müller wrote: > This patch fixes two typos related to unregistering algorithms supported by > SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered > in case of an error. In sahara_unregister_algs the wrong array is used to > determine the iteration count. > > Signed-off-by: Michael Müller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/2] crypto: ECDH - fix typo of P-192 b value
On Wed, Jul 11, 2018 at 08:36:23PM +0200, Stephan Müller wrote: > Fix the b value to be compliant with FIPS 186-4 D.1.2.1. This fix is > required to make sure the SP800-56A public key test passes for P-192. > > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/2] crypto: DRBG - use caller buffer if suitable
On Fri, Jul 20, 2018 at 07:09:05AM +0200, Stephan Mueller wrote: > > Maybe I have a different understanding of how such interface should look like. > > Can you give me some more detail on how you envision such virtual address > interface should work? It should look like shash. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: inside-secure - initialize first_rdesc to make GCC happy
On Fri, Jul 13, 2018 at 05:43:16PM +0200, Antoine Tenart wrote: > In the cipher safexcel_send_req function, GCC warns that > first_rdesc may be used uninitialized. While this should never > happen, this patch removes the warning by initializing this > variable to NULL to make GCC happy. > > This was reported by the kbuild test robot. > > Signed-off-by: Antoine Tenart Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: DRBG - eliminate constant reinitialization of SGL
On Tue, Jul 10, 2018 at 05:56:33PM +0200, Stephan Müller wrote: > The CTR DRBG requires two SGLs pointing to input/output buffers for the > CTR AES operation. The used SGLs always have only one entry. Thus, the > SGL can be initialized during allocation time, preventing a > re-initialization of the SGLs during each call. > > The performance is increased by about 1 to 3 percent depending on the > size of the requested buffer size. > > Signed-off-by: Stephan Mueller Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 2/2] crypto: DRBG - use caller buffer if suitable
On Fri, Jul 20, 2018 at 08:08:22AM +0200, Stephan Mueller wrote: > > - should it be synchronous like blkcipher? It should be synchronous. > - the TFMs (cipher Impls and templates) all operate on SGLs - should a virt > API simply convert a virt address into an SGL? If so, the problem that > triggered this thread is still not solved but only pushed to a different > layer. If it should not just be an SGL wrapper, should all TFMs be changed? Obviously if we're going to do this then we would be converting the underlying algorithms over to the virtual address-based interface just like shash. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: inside-secure - switch to SPDX identifiers
On Fri, Jul 13, 2018 at 04:51:37PM +0200, Antoine Tenart wrote: > Use the appropriate SPDX license identifiers and drop the license text. > This patch is only cosmetic. > > Signed-off-by: Antoine Tenart Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
