linux/crypto/authenc.c

723 lines
20 KiB

crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks When comparing MAC hashes, AEAD authentication tags, or other hash values in the context of authentication or integrity checking, it is important not to leak timing information to a potential attacker, i.e. when communication happens over a network. Bytewise memory comparisons (such as memcmp) are usually optimized so that they return a nonzero value as soon as a mismatch is found. E.g, on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch and up to ~850 cyc for a full match (cold). This early-return behavior can leak timing information as a side channel, allowing an attacker to iteratively guess the correct result. This patch adds a new method crypto_memneq ("memory not equal to each other") to the crypto API that compares memory areas of the same length in roughly "constant time" (cache misses could change the timing, but since they don't reveal information about the content of the strings being compared, they are effectively benign). Iow, best and worst case behaviour take the same amount of time to complete (in contrast to memcmp). Note that crypto_memneq (unlike memcmp) can only be used to test for equality or inequality, NOT for lexicographical order. This, however, is not an issue for its use-cases within the crypto API. We tried to locate all of the places in the crypto API where memcmp was being used for authentication or integrity checking, and convert them over to crypto_memneq. crypto_memneq is declared noinline, placed in its own source file, and compiled with optimizations that might increase code size disabled ("Os") because a smart compiler (or LTO) might notice that the return value is always compared against zero/nonzero, and might then reintroduce the same early-return optimization that we are trying to avoid. Using #pragma or __attribute__ optimization annotations of the code for disabling optimization was avoided as it seems to be considered broken or unmaintained for long time in GCC [1]. Therefore, we work around that by specifying the compile flag for memneq.o directly in the Makefile. We found that this seems to be most appropriate. As we use ("Os"), this patch also provides a loop-free "fast-path" for frequently used 16 byte digests. Similarly to kernel library string functions, leave an option for future even further optimized architecture specific assembler implementations. This was a joint work of James Yonan and Daniel Borkmann. Also thanks for feedback from Florian Weimer on this and earlier proposals [2]. [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html [2] https://lkml.org/lkml/2013/2/10/131 Signed-off-by: James Yonan <james@openvpn.net> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Cc: Florian Weimer <fw@deneb.enyo.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-09-26 02:20:39 -06:00
crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks When comparing MAC hashes, AEAD authentication tags, or other hash values in the context of authentication or integrity checking, it is important not to leak timing information to a potential attacker, i.e. when communication happens over a network. Bytewise memory comparisons (such as memcmp) are usually optimized so that they return a nonzero value as soon as a mismatch is found. E.g, on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch and up to ~850 cyc for a full match (cold). This early-return behavior can leak timing information as a side channel, allowing an attacker to iteratively guess the correct result. This patch adds a new method crypto_memneq ("memory not equal to each other") to the crypto API that compares memory areas of the same length in roughly "constant time" (cache misses could change the timing, but since they don't reveal information about the content of the strings being compared, they are effectively benign). Iow, best and worst case behaviour take the same amount of time to complete (in contrast to memcmp). Note that crypto_memneq (unlike memcmp) can only be used to test for equality or inequality, NOT for lexicographical order. This, however, is not an issue for its use-cases within the crypto API. We tried to locate all of the places in the crypto API where memcmp was being used for authentication or integrity checking, and convert them over to crypto_memneq. crypto_memneq is declared noinline, placed in its own source file, and compiled with optimizations that might increase code size disabled ("Os") because a smart compiler (or LTO) might notice that the return value is always compared against zero/nonzero, and might then reintroduce the same early-return optimization that we are trying to avoid. Using #pragma or __attribute__ optimization annotations of the code for disabling optimization was avoided as it seems to be considered broken or unmaintained for long time in GCC [1]. Therefore, we work around that by specifying the compile flag for memneq.o directly in the Makefile. We found that this seems to be most appropriate. As we use ("Os"), this patch also provides a loop-free "fast-path" for frequently used 16 byte digests. Similarly to kernel library string functions, leave an option for future even further optimized architecture specific assembler implementations. This was a joint work of James Yonan and Daniel Borkmann. Also thanks for feedback from Florian Weimer on this and earlier proposals [2]. [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html [2] https://lkml.org/lkml/2013/2/10/131 Signed-off-by: James Yonan <james@openvpn.net> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Cc: Florian Weimer <fw@deneb.enyo.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-09-26 02:20:39 -06:00
[CRYPTO] authenc: Fix async crypto crash in crypto_authenc_genicv() crypto_authenc_givencrypt_done uses req->data as struct aead_givcrypt_request, while it really points to a struct aead_request, causing this crash: BUG: unable to handle kernel paging request at 6b6b6b6b IP: [<dc87517b>] :authenc:crypto_authenc_genicv+0x23/0x109 *pde = 00000000 Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC Modules linked in: hifn_795x authenc esp4 aead xfrm4_mode_tunnel sha1_generic hmac crypto_hash] Pid: 3074, comm: ping Not tainted (2.6.25 #4) EIP: 0060:[<dc87517b>] EFLAGS: 00010296 CPU: 0 EIP is at crypto_authenc_genicv+0x23/0x109 [authenc] EAX: daa04690 EBX: daa046e0 ECX: dab0a100 EDX: daa046b0 ESI: 6b6b6b6b EDI: dc872054 EBP: c033ff60 ESP: c033ff0c DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process ping (pid: 3074, ti=c033f000 task=db883a80 task.ti=dab6c000) Stack: 00000000 daa046b0 c0215a3e daa04690 dab0a100 00000000 ffffffff db9fd7f0 dba208c0 dbbb1720 00000001 daa04720 00000001 c033ff54 c0119ca9 dc852a75 c033ff60 c033ff60 daa046e0 00000000 00000001 c033ff6c dc87527b 00000001 Call Trace: [<c0215a3e>] ? dev_alloc_skb+0x14/0x29 [<c0119ca9>] ? printk+0x15/0x17 [<dc87527b>] ? crypto_authenc_givencrypt_done+0x1a/0x27 [authenc] [<dc850cca>] ? hifn_process_ready+0x34a/0x352 [hifn_795x] [<dc8353c7>] ? rhine_napipoll+0x3f2/0x3fd [via_rhine] [<dc851a56>] ? hifn_check_for_completion+0x4d/0xa6 [hifn_795x] [<dc851ab9>] ? hifn_tasklet_callback+0xa/0xc [hifn_795x] [<c011d046>] ? tasklet_action+0x3f/0x66 [<c011d230>] ? __do_softirq+0x38/0x7a [<c0105a5f>] ? do_softirq+0x3e/0x71 [<c011d17c>] ? irq_exit+0x2c/0x65 [<c010e0c0>] ? smp_apic_timer_interrupt+0x5f/0x6a [<c01042e4>] ? apic_timer_interrupt+0x28/0x30 [<dc851640>] ? hifn_handle_req+0x44a/0x50d [hifn_795x] ... Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-29 21:44:28 +08:00
[CRYPTO] authenc: Fix async crypto crash in crypto_authenc_genicv() crypto_authenc_givencrypt_done uses req->data as struct aead_givcrypt_request, while it really points to a struct aead_request, causing this crash: BUG: unable to handle kernel paging request at 6b6b6b6b IP: [<dc87517b>] :authenc:crypto_authenc_genicv+0x23/0x109 *pde = 00000000 Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC Modules linked in: hifn_795x authenc esp4 aead xfrm4_mode_tunnel sha1_generic hmac crypto_hash] Pid: 3074, comm: ping Not tainted (2.6.25 #4) EIP: 0060:[<dc87517b>] EFLAGS: 00010296 CPU: 0 EIP is at crypto_authenc_genicv+0x23/0x109 [authenc] EAX: daa04690 EBX: daa046e0 ECX: dab0a100 EDX: daa046b0 ESI: 6b6b6b6b EDI: dc872054 EBP: c033ff60 ESP: c033ff0c DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Process ping (pid: 3074, ti=c033f000 task=db883a80 task.ti=dab6c000) Stack: 00000000 daa046b0 c0215a3e daa04690 dab0a100 00000000 ffffffff db9fd7f0 dba208c0 dbbb1720 00000001 daa04720 00000001 c033ff54 c0119ca9 dc852a75 c033ff60 c033ff60 daa046e0 00000000 00000001 c033ff6c dc87527b 00000001 Call Trace: [<c0215a3e>] ? dev_alloc_skb+0x14/0x29 [<c0119ca9>] ? printk+0x15/0x17 [<dc87527b>] ? crypto_authenc_givencrypt_done+0x1a/0x27 [authenc] [<dc850cca>] ? hifn_process_ready+0x34a/0x352 [hifn_795x] [<dc8353c7>] ? rhine_napipoll+0x3f2/0x3fd [via_rhine] [<dc851a56>] ? hifn_check_for_completion+0x4d/0xa6 [hifn_795x] [<dc851ab9>] ? hifn_tasklet_callback+0xa/0xc [hifn_795x] [<c011d046>] ? tasklet_action+0x3f/0x66 [<c011d230>] ? __do_softirq+0x38/0x7a [<c0105a5f>] ? do_softirq+0x3e/0x71 [<c011d17c>] ? irq_exit+0x2c/0x65 [<c010e0c0>] ? smp_apic_timer_interrupt+0x5f/0x6a [<c01042e4>] ? apic_timer_interrupt+0x28/0x30 [<dc851640>] ? hifn_handle_req+0x44a/0x50d [hifn_795x] ... Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-29 21:44:28 +08:00
crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks When comparing MAC hashes, AEAD authentication tags, or other hash values in the context of authentication or integrity checking, it is important not to leak timing information to a potential attacker, i.e. when communication happens over a network. Bytewise memory comparisons (such as memcmp) are usually optimized so that they return a nonzero value as soon as a mismatch is found. E.g, on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch and up to ~850 cyc for a full match (cold). This early-return behavior can leak timing information as a side channel, allowing an attacker to iteratively guess the correct result. This patch adds a new method crypto_memneq ("memory not equal to each other") to the crypto API that compares memory areas of the same length in roughly "constant time" (cache misses could change the timing, but since they don't reveal information about the content of the strings being compared, they are effectively benign). Iow, best and worst case behaviour take the same amount of time to complete (in contrast to memcmp). Note that crypto_memneq (unlike memcmp) can only be used to test for equality or inequality, NOT for lexicographical order. This, however, is not an issue for its use-cases within the crypto API. We tried to locate all of the places in the crypto API where memcmp was being used for authentication or integrity checking, and convert them over to crypto_memneq. crypto_memneq is declared noinline, placed in its own source file, and compiled with optimizations that might increase code size disabled ("Os") because a smart compiler (or LTO) might notice that the return value is always compared against zero/nonzero, and might then reintroduce the same early-return optimization that we are trying to avoid. Using #pragma or __attribute__ optimization annotations of the code for disabling optimization was avoided as it seems to be considered broken or unmaintained for long time in GCC [1]. Therefore, we work around that by specifying the compile flag for memneq.o directly in the Makefile. We found that this seems to be most appropriate. As we use ("Os"), this patch also provides a loop-free "fast-path" for frequently used 16 byte digests. Similarly to kernel library string functions, leave an option for future even further optimized architecture specific assembler implementations. This was a joint work of James Yonan and Daniel Borkmann. Also thanks for feedback from Florian Weimer on this and earlier proposals [2]. [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html [2] https://lkml.org/lkml/2013/2/10/131 Signed-off-by: James Yonan <james@openvpn.net> Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Cc: Florian Weimer <fw@deneb.enyo.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-09-26 02:20:39 -06:00