aboutsummaryrefslogtreecommitdiff
path: root/sys/crypto
Commit message (Collapse)AuthorAgeFilesLines
...
* aesni(4): Fix trivial type typoConrad Meyer2019-05-271-1/+1
| | | | | | | | | This fixes the kernel build with xtoolchain-gcc (6.4.0). X-MFC-With: r348268 Notes: svn path=/head/; revision=348293
* Add an AESNI-optimized version of the CCM/CBC cryptographic and authenticationSean Eric Fagan2019-05-254-11/+512
| | | | | | | | | | | code. The primary client of this is probably going to be ZFS encryption. Reviewed by: jhb, cem Sponsored by: iXsystems Inc, Kithrup Enterprises Differential Revision: https://reviews.freebsd.org/D19298 Notes: svn path=/head/; revision=348268
* Extract eventfilter declarations to sys/_eventfilter.hConrad Meyer2019-05-205-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h" in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header pollution substantially. EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c files into appropriate headers (e.g., sys/proc.h, powernv/opal.h). As a side effect of reduced header pollution, many .c files and headers no longer contain needed definitions. The remainder of the patch addresses adding appropriate includes to fix those files. LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by sys/mutex.h since r326106 (but silently protected by header pollution prior to this change). No functional change (intended). Of course, any out of tree modules that relied on header pollution for sys/eventhandler.h, sys/lock.h, or sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped. Notes: svn path=/head/; revision=347984
* Embedded chacha: Add 0-bit iv + 128-bit counter modeConrad Meyer2019-03-012-1/+43
| | | | | | | | | | | This mode might be suitable for a Fortuna keystream primitive. Reviewed by: markm Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D19410 Notes: svn path=/head/; revision=344714
* Regularize the Netflix copyrightWarner Losh2019-02-041-1/+2
| | | | | | | | | | | | | | | Use recent best practices for Copyright form at the top of the license: 1. Remove all the All Rights Reserved clauses on our stuff. Where we piggybacked others, use a separate line to make things clear. 2. Use "Netflix, Inc." everywhere. 3. Use a single line for the copyright for grep friendliness. 4. Use date ranges in all places for our stuff. Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files) Notes: svn path=/head/; revision=343755
* Generalize AES iov optimizationMatt Macy2018-12-131-21/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Right now, aesni_cipher_alloc does a bit of special-casing for CRYPTO_F_IOV, to not do any allocation if the first uio is large enough for the requested size. While working on ZFS crypto port, I ran into horrible performance because the code uses scatter-gather, and many of the times the data to encrypt was in the second entry. This code looks through the list, and tries to see if there is a single uio that can contain the requested data, and, if so, uses that. This has a slight impact on the current consumers, in that the check is a little more complicated for the ones that use CRYPTO_F_IOV -- but none of them meet the criteria for testing more than one. Submitted by: sef at ixsystems.com Reviewed by: cem@ MFC after: 3 days Sponsored by: iX Systems Differential Revision: https://reviews.freebsd.org/D18522 Notes: svn path=/head/; revision=342024
* rijndael (AES): Avoid leaking sensitive data on kernel stackConrad Meyer2018-10-261-11/+20
| | | | | | | | | | | | | Noticed this investigating Fortuna. Remove useless duplicate stack copies of sensitive contents when possible, or if not possible, be sure to zero them out when we're finished. Approved by: secteam (gordon) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D16935 Notes: svn path=/head/; revision=339787
* Add explicit copyright text to trivial headerConrad Meyer2018-10-221-0/+3
| | | | | | | Reported by: rgrimes Notes: svn path=/head/; revision=339561
* Embedded chacha: Remove some harmless dead stores in keystream modeConrad Meyer2018-10-201-0/+2
| | | | | | | | | (From r338059.) Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=339500
* Embedded chacha: Distinguish via dedicated macroConrad Meyer2018-10-201-3/+3
| | | | | | | | | | | | Set embedding expectations via CHACHA_EMBED macro rather than _KERNEL definition. No functional change. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=339499
* crypto/chacha: Split header into separate _chacha.hConrad Meyer2018-10-202-4/+13
| | | | | | | Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=339498
* Reapply, with minor tweaks, r338025, from the original commit:Warner Losh2018-09-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove unused and easy to misuse PNP macro parameter Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Approved by: re (glen) Notes: svn path=/head/; revision=338948
* Don't load ccp automatically with devmatchWarner Losh2018-08-311-0/+2
| | | | | | | | | | | | | | | Remove the PNP info for the moment from the driver. It's an experimental driver (as noted in r328150). It's performance is about 1/10th that of aesni. It will often panic when used with GELI (PR 2279820). It's not in our best interest to have such a driver be autoloaded by default. Approved by: re@ (rgrimes) Reviewed By: cem@ Differential Review: https://reviews.freebsd.org/D16959 Notes: svn path=/head/; revision=338402
* Update userland arc4random() with OpenBSD's Chacha20 based arc4random().Xin LI2018-08-192-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ObsoleteFiles.inc: Remove manual pages for arc4random_addrandom(3) and arc4random_stir(3). contrib/ntp/lib/isc/random.c: contrib/ntp/sntp/libevent/evutil_rand.c: Eliminate in-tree usage of arc4random_addrandom(). crypto/heimdal/lib/roken/rand.c: crypto/openssh/config.h: Eliminate in-tree usage of arc4random_stir(). include/stdlib.h: Remove arc4random_stir() and arc4random_addrandom() prototypes, provide temporary shims for transistion period. lib/libc/gen/Makefile.inc: Hook arc4random-compat.c to build, add hint for Chacha20 source for kernel, and remove arc4random_addrandom(3) and arc4random_stir(3) links. lib/libc/gen/arc4random.c: Adopt OpenBSD arc4random.c,v 1.54 with bare minimum changes, use the sys/crypto/chacha20 implementation of keystream. lib/libc/gen/Symbol.map: Remove arc4random_stir and arc4random_addrandom interfaces. lib/libc/gen/arc4random.h: Adopt OpenBSD arc4random.h,v 1.4 but provide _ARC4_LOCK of our own. lib/libc/gen/arc4random.3: Adopt OpenBSD arc4random.3,v 1.35 but keep FreeBSD r114444 and r118247. lib/libc/gen/arc4random-compat.c: Compatibility shims for arc4random_stir and arc4random_addrandom functions to preserve ABI. Log once when called but do nothing otherwise. lib/libc/gen/getentropy.c: lib/libc/include/libc_private.h: Fold __arc4_sysctl into getentropy.c (renamed to arnd_sysctl). Remove from libc_private.h as a result. sys/crypto/chacha20/chacha.c: sys/crypto/chacha20/chacha.h: Make it possible to use the kernel implementation in libc. PR: 182610 Reviewed by: cem, markm Obtained from: OpenBSD Relnotes: yes Differential Revision: https://reviews.freebsd.org/D16760 Notes: svn path=/head/; revision=338059
* Back out r338035 until Warner is finished churning GSoC PNP patchesConrad Meyer2018-08-191-1/+1
| | | | | | | | | | I was not aware Warner was making or planning to make forward progress in this area and have since been informed of that. It's easy to apply/reapply when churn dies down. Notes: svn path=/head/; revision=338037
* Remove unused and easy to misuse PNP macro parameterConrad Meyer2018-08-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inspired by r338025, just remove the element size parameter to the MODULE_PNP_INFO macro entirely. The 'table' parameter is now required to have correct pointer (or array) type. Since all invocations of the macro already had this property and the emitted PNP data continues to include the element size, there is no functional change. Mostly done with the coccinelle 'spatch' tool: $ cat modpnpsize0.cocci @normaltables@ identifier b,c; expression a,d,e; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,d, -sizeof(d[0]), e); @singletons@ identifier b,c,d; expression a; declarer MODULE_PNP_INFO; @@ MODULE_PNP_INFO(a,b,c,&d, -sizeof(d), 1); $ rg -l MODULE_PNP_INFO -- sys | \ xargs spatch --in-place --sp-file modpnpsize0.cocci (Note that coccinelle invokes diff(1) via a PATH search and expects diff to tolerate the -B flag, which BSD diff does not. So I had to link gdiff into PATH as diff to use spatch.) Tinderbox'd (-DMAKE_JUST_KERNELS). Notes: svn path=/head/; revision=338035
* Bring in compatibility glue for libsodiumConrad Meyer2018-08-178-0/+42
| | | | | | | | | | | | The idea is untouched upstream sources live in sys/contrib/libsodium. sys/crypto/libsodium are support routines or compatibility headers to allow building unmodified upstream code. This is not yet integrated into the build system, so no functional change. Notes: svn path=/head/; revision=337938
* libmd: Always erase context in _Final method, and when doingXin LI2018-07-203-5/+8
| | | | | | | | | | | | | it, consistently use explicit_bzero(). Update manual pages to match the behavior. Reviewed by: pfg, allanjude, jmg MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D16316 Notes: svn path=/head/; revision=336539
* Remove unused variableConrad Meyer2018-07-181-2/+0
| | | | | | | Reported by: gcc Notes: svn path=/head/; revision=336445
* aesni(4): Add SHA2-224(-HMAC) support as wellConrad Meyer2018-07-181-0/+32
| | | | Notes: svn path=/head/; revision=336444
* aesni(4): Add sha256 plain hash supportConrad Meyer2018-07-181-0/+6
| | | | Notes: svn path=/head/; revision=336443
* aesni(4): Abstract out hash/HMAC supportConrad Meyer2018-07-181-26/+49
| | | | | | | | | No functional change. Verified with cryptocheck. Notes: svn path=/head/; revision=336442
* OpenCrypto: Convert sessions to opaque handles instead of integersConrad Meyer2018-07-189-499/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Track session objects in the framework, and pass handles between the framework (OCF), consumers, and drivers. Avoid redundancy and complexity in individual drivers by allocating session memory in the framework and providing it to drivers in ::newsession(). Session handles are no longer integers with information encoded in various high bits. Use of the CRYPTO_SESID2FOO() macros should be replaced with the appropriate crypto_ses2foo() function on the opaque session handle. Convert OCF drivers (in particular, cryptosoft, as well as myriad others) to the opaque handle interface. Discard existing session tracking as much as possible (quick pass). There may be additional code ripe for deletion. Convert OCF consumers (ipsec, geom_eli, krb5, cryptodev) to handle-style interface. The conversion is largely mechnical. The change is documented in crypto.9. Inspired by https://lists.freebsd.org/pipermail/freebsd-arch/2018-January/018835.html . No objection from: ae (ipsec portion) Reported by: jhb Notes: svn path=/head/; revision=336439
* Create an empty stdint.h for arm_neon.h to include.Andrew Turner2018-07-161-0/+5
| | | | | | | | | | | | | The armv8crypto module includes arm_neon.h for the compiler intrinsic functions. This includes the userland stdint.h file that doesn't exist in the kernel. Fix this by providing an empty stdint.h to be used when we include arm_neon.h. Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D16254 Notes: svn path=/head/; revision=336348
* Implement SHA2-224 submode of SHA2-256Conrad Meyer2018-07-092-0/+154
| | | | | | | | Like SHA2-384:SHA2-512, SHA2-224 is simply a truncated SHA2-256 with a different initial vector. Add to round out the complete basic SHA2 family. Notes: svn path=/head/; revision=336123
* Remove "HMAC" from <HASH>_HMAC_BLOCK_LEN macro namesConrad Meyer2018-07-093-6/+6
| | | | | | | | | | The block size is a property of the underlying hash algorithm, and has nothing to do with the HMAC construction. No functional change. Notes: svn path=/head/; revision=336122
* aesni(4): Fix {de,en}crypt operations that allocated a bufferConrad Meyer2018-06-231-0/+4
| | | | | | | | | | | | | | | | | | | | aesni(4) allocates a contiguous buffer for the data it processes if the provided input was not already virtually contiguous, and copies the input there. It performs encryption or decryption in-place. r324037 removed the logic that then copied the processed data back to the user-provided input buffer, breaking {de,enc}crypt for mbuf chains or iovecs with more than a single descriptor. PR: 228094 (probably, not confirmed) Submitted by: Sean Fagan <kithrup AT me.com> Reported by: Emeric POUPON <emeric.poupon AT stormshield.eu> X-MFC-With: 324037 Security: could result in plaintext being output by "encrypt" operation Notes: svn path=/head/; revision=335584
* aesni(4): Support CRD_F_KEY_EXPLICIT OCF modeConrad Meyer2018-06-231-11/+31
| | | | | | | | PR: 227788 Reported by: eadler@ Notes: svn path=/head/; revision=335583
* disable printing value of SKEIN_LOOP during standard out,Matt Macy2018-05-191-1/+1
| | | | | | | not useful information Notes: svn path=/head/; revision=333883
* opencrypto: Integrate Chacha20 algorithm into OCFConrad Meyer2018-03-291-0/+78
| | | | | | | | | | | Mostly this is a thin shim around existing code to integrate with enc_xform and cryptosoft (+ cryptodev). Expand the cryptodev buffer used to match that of Chacha20's native block size as a performance enhancement for chacha20_xform_crypt_multi. Notes: svn path=/head/; revision=331724
* MFV: libb2: use native calls for secure memory clearanceConrad Meyer2018-03-271-0/+2
| | | | | | | | | | | | | Drop our local patch and restore full vanilla upstream code in contrib/libb2. No functional change intended. explicit_bzero() should continue to be used. Obtained from: libb2 b4b241a34824b51956a7866606329a065d397525 Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=331620
* The PNP info has to follow the module definition. Move it from justWarner Losh2018-03-251-2/+2
| | | | | | | | | after the array to its proper location. Otherwise, the linker.hints file has things out of order and we associated it with whatever was the previous module. Notes: svn path=/head/; revision=331532
* Import Blake2 algorithms (blake2b, blake2s) from libb2Conrad Meyer2018-03-2119-0/+772
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The upstream repository is on github BLAKE2/libb2. Files landed in sys/contrib/libb2 are the unmodified upstream files, except for one difference: secure_zero_memory's contents have been replaced with explicit_bzero() only because the previous implementation broke powerpc link. Preferential use of explicit_bzero() is in progress upstream, so it is anticipated we will be able to drop this diff in the future. sys/crypto/blake2 contains the source files needed to port libb2 to our build system, a wrapped (limited) variant of the algorithm to match the API of our auth_transform softcrypto abstraction, incorporation into the Open Crypto Framework (OCF) cryptosoft(4) driver, as well as an x86 SSE/AVX accelerated OCF driver, blake2(4). Optimized variants of blake2 are compiled for a number of x86 machines (anything from SSE2 to AVX + XOP). On those machines, FPU context will need to be explicitly saved before using blake2(4)-provided algorithms directly. Use via cryptodev / OCF saves FPU state automatically, and use via the auth_transform softcrypto abstraction does not use FPU. The intent of the OCF driver is mostly to enable testing in userspace via /dev/crypto. ATF tests are added with published KAT test vectors to validate correctness. Reviewed by: jhb, markj Obtained from: github BLAKE2/libb2 Differential Revision: https://reviews.freebsd.org/D14662 Notes: svn path=/head/; revision=331312
* Garbage collect unused chacha20 codeConrad Meyer2018-03-162-262/+0
| | | | | | | | | | | | | | | | | Two copies of chacha20 were imported into the tree on Apr 15 2017 (r316982) and Apr 16 2017 (r317015). Only the latter is actually used by anything, so just go ahead and garbage collect the unused version while it's still only in CURRENT. I'm not making any judgement on which implementation is better. If I pulled the wrong one, feel free to swap the existing implementation out and replace it with the other code (conforming to the API that actually gets used in randomdev, of course). We only need one generic implementation. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=331049
* aesni(4): Stylistic/comment enhancementsConrad Meyer2018-03-151-5/+7
| | | | | | | | | | | | Improve clarity of a comment and style(9) some areas. No functional change. Reported by: markj (on review of a mostly-copied driver) Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=331007
* Remove unused error return from API that cannot failConrad Meyer2018-02-235-32/+12
| | | | | | | | | | | | | | | | | | | No implementation of fpu_kern_enter() can fail, and it was causing needless error checking boilerplate and confusion. Change the return code to void to match reality. (This trivial change took nine days to land because of the commit hook on sys/dev/random. Please consider removing the hook or otherwise lowering the bar -- secteam never seems to have free time to review patches.) Reported by: Lachlan McIlroy <Lachlan.McIlroy AT isilon.com> Reviewed by: delphij Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D14380 Notes: svn path=/head/; revision=329878
* ccp(4): Store IV in output buffer in GCM software fallback when requestedConrad Meyer2018-01-271-0/+3
| | | | | | | | | | Apply r328361 to duplicate copy of ccr_gcm_soft in ccp(4). Properly honor the lack of the CRD_F_IV_PRESENT flag in the GCM software fallback case for encryption requests. Notes: svn path=/head/; revision=328465
* Add ccp(4): experimental driver for AMD Crypto Co-ProcessorConrad Meyer2018-01-186-0/+3907
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Registers TRNG source for random(4) * Finds available queues, LSBs; allocates static objects * Allocates a shared MSI-X for all queues. The hardware does not have separate interrupts per queue. Working interrupt mode driver. * Computes SHA hashes, HMAC. Passes cryptotest.py, cryptocheck tests. * Does AES-CBC, CTR mode, and XTS. cryptotest.py and cryptocheck pass. * Support for "authenc" (AES + HMAC). (SHA1 seems to result in "unaligned" cleartext inputs from cryptocheck -- which the engine cannot handle. SHA2 seems to work fine.) * GCM passes for block-multiple AAD, input lengths Largely based on ccr(4), part of cxgbe(4). Rough performance averages on AMD Ryzen 1950X (4kB buffer): aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s ccp: ~630 Mb/s SHA256: ~660 Mb/s SHA512: ~700 Mb/s cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s As you can see, performance is poor in comparison to aesni(4) and even cryptosoft (due to high setup cost). At a larger buffer size (128kB), throughput is a little better (but still worse than aesni(4)): aesni: SHA1:~10400 Mb/s SHA256: ~9950 Mb/s ccp: ~2200 Mb/s SHA256: ~2600 Mb/s SHA512: ~3800 Mb/s cryptosoft: ~1750 Mb/s SHA256: ~1800 Mb/s SHA512: ~2700 Mb/s AES performance has a similar story: aesni: 4kB: ~11250 Mb/s 128kB: ~11250 Mb/s ccp: ~350 Mb/s 128kB: ~4600 Mb/s cryptosoft: ~1750 Mb/s 128kB: ~1700 Mb/s This driver is EXPERIMENTAL. You should verify cryptographic results on typical and corner case inputs from your application against a known- good implementation. Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12723 Notes: svn path=/head/; revision=328150
* Revert r327340, as the workaround for rep prefixes followed by .byteDimitry Andric2018-01-171-1/+1
| | | | | | | directives is no longer needed after r328090. Notes: svn path=/head/; revision=328091
* Merge ^/head r327624 through r327885.Dimitry Andric2018-01-121-0/+5
|\ | | | | | | Notes: svn path=/projects/clang600-import/; revision=327886
| * aesni(4): Quiesce spurious GCC 6.3.0 -Wmaybe-uninitialized warningsConrad Meyer2018-01-121-0/+5
| | | | | | | | | | | | | | | | | | | | Always initialize some variables GCC warns about. They are initialized in every path where they are used, but GCC doesn't know that. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=327866
* | Work around a clang 6.0.0 issue with rep prefixes followed by .byteDimitry Andric2017-12-291-1/+1
|/ | | | | | | | | | | directives (as reported in https://bugs.llvm.org/show_bug.cgi?id=35749), by defining the rep prefix with yet another .byte directive. This is a temporary fix, to be reverted before merging back to head, until upstream has a proper fix for this. Notes: svn path=/projects/clang600-import/; revision=327340
* sys: further adoption of SPDX licensing ID tags.Pedro F. Giffuni2017-11-202-2/+6
| | | | | | | | | | | | | | | | | Mainly focus on files that use BSD 3-Clause license. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts. Special thanks to Wind River for providing access to "The Duke of Highlander" tool: an older (2014) run over FreeBSD tree was useful as a starting point. Notes: svn path=/head/; revision=326023
* aesni(4): CRYPTO_AES_NIST_GCM_16 mandates MACConrad Meyer2017-10-041-2/+5
| | | | | | | | | | | | | Remove some dead conditionals and add an assertion around behavior already present in aesni_process(). Silence a few Coverity false positives. CIDs: 1381571, 1381557 Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=324288
* aesni(4): Fix GCC buildConrad Meyer2017-09-292-4/+6
| | | | | | | | | | | | | | | | The GCC xmmintrin.h header brokenly includes mm_malloc.h unconditionally. (The Clang version of xmmintrin.h only includes mm_malloc.h if not compiling in standalone mode.) Hack around GCC's broken header by defining the include guard macro ahead of including xmmintrin.h. Reported by: lwhsu, jhb Tested by: lwhsu Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=324106
* aesni(4): Add support for x86 SHA intrinsicsConrad Meyer2017-09-265-104/+968
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some x86 class CPUs have accelerated intrinsics for SHA1 and SHA256. Provide this functionality on CPUs that support it. This implements CRYPTO_SHA1, CRYPTO_SHA1_HMAC, and CRYPTO_SHA2_256_HMAC. Correctness: The cryptotest.py suite in tests/sys/opencrypto has been enhanced to verify SHA1 and SHA256 HMAC using standard NIST test vectors. The test passes on this driver. Additionally, jhb's cryptocheck tool has been used to compare various random inputs against OpenSSL. This test also passes. Rough performance averages on AMD Ryzen 1950X (4kB buffer): aesni: SHA1: ~8300 Mb/s SHA256: ~8000 Mb/s cryptosoft: ~1800 Mb/s SHA256: ~1800 Mb/s So ~4.4-4.6x speedup depending on algorithm choice. This is consistent with the results the Linux folks saw for 4kB buffers. The driver borrows SHA update code from sys/crypto sha1 and sha256. The intrinsic step function comes from Intel under a 3-clause BSDL.[0] The intel_sha_extensions_sha<foo>_intrinsic.c files were renamed and lightly modified (added const, resolved a warning or two; included the sha_sse header to declare the functions). [0]: https://software.intel.com/en-us/articles/intel-sha-extensions-implementations Reviewed by: jhb Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12452 Notes: svn path=/head/; revision=324037
* opencrypto: Use C99 initializers for auth_hash instancesConrad Meyer2017-09-261-12/+18
| | | | | | | | | | | | A misordering in the Via padlock driver really strongly suggested that these should use C99 named initializers. No functional change. Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=324019
* opencrypto: Loosen restriction on HMAC key sizesConrad Meyer2017-09-261-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Theoretically, HMACs do not actually have any limit on key sizes. Transforms should compact input keys larger than the HMAC block size by using the transform (hash) on the input key. (Short input keys are padded out with zeros to the HMAC block size.) Still, not all FreeBSD crypto drivers that provide HMAC functionality handle longer-than-blocksize keys appropriately, so enforce a "maximum" key length in the crypto API for auth_hashes that previously expressed a requirement. (The "maximum" is the size of a single HMAC block for the given transform.) Unconstrained auth_hashes are left as-is. I believe the previous hardcoded sizes were committed in the original import of opencrypto from OpenBSD and are due to specific protocol details of IPSec. Note that none of the previous sizes actually matched the appropriate HMAC block size. The previous hardcoded sizes made the SHA tests in cryptotest.py useless for testing FreeBSD crypto drivers; none of the NIST-KAT example inputs had keys sized to the previous expectations. The following drivers were audited to check that they handled keys up to the block size of the HMAC safely: Software HMAC: * padlock(4) * cesa * glxsb * safe(4) * ubsec(4) Hardware accelerated HMAC: * ccr(4) * hifn(4) * sec(4) (Only supports up to 64 byte keys despite claiming to support SHA2 HMACs, but validates input key sizes) * cryptocteon (MIPS) * nlmsec (MIPS) * rmisec (MIPS) (Amusingly, does not appear to use key material at all -- presumed broken) Reviewed by: jhb (previous version), rlibby (previous version) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12437 Notes: svn path=/head/; revision=324017
* aesni(4): Fix another trivial typo (aensi -> aesni)Conrad Meyer2017-09-201-2/+2
| | | | | | | Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=323823
* aesni(4): Fix trivial typo (AQUIRE -> ACQUIRE)Conrad Meyer2017-09-201-3/+3
| | | | | | | Sponsored by: Dell EMC Isilon Notes: svn path=/head/; revision=323820
generated by cgit v1.3 (git 2.53.0) at 2026-08-01 21:04:41 +0000