Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 3月, 2014 2 次提交
  3. 25 2月, 2014 1 次提交
  5. 05 1月, 2014 1 次提交
    • M
      crypto: ahash - Fully restore ahash request before completing · 1d9a394b
      由 Marek Vasut 提交于 
      When finishing the ahash request, the ahash_op_unaligned_done() will
call complete() on the request. Yet, this will not call the correct
complete callback. The correct complete callback was previously stored
in the requests' private data, as seen in ahash_op_unaligned(). This
patch restores the correct complete callback and .data field of the
request before calling complete() on it.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      1d9a394b
  7. 20 12月, 2013 1 次提交
  9. 09 12月, 2013 1 次提交
  11. 05 12月, 2013 2 次提交
    • M
      crypto: pcrypt - Fix wrong usage of rcu_dereference() · 3110e400
      由 Mathias Krause 提交于 
      A kernel with enabled lockdep complains about the wrong usage of
rcu_dereference() under a rcu_read_lock_bh() protected region.

  ===============================
  [ INFO: suspicious RCU usage. ]
  3.13.0-rc1+ #126 Not tainted
  -------------------------------
  linux/crypto/pcrypt.c:81 suspicious rcu_dereference_check() usage!

  other info that might help us debug this:

  rcu_scheduler_active = 1, debug_locks = 1
  1 lock held by cryptomgr_test/153:
   #0:  (rcu_read_lock_bh){.+....}, at: [<ffffffff812c8075>] pcrypt_do_parallel.isra.2+0x5/0x200

Fix that by using rcu_dereference_bh() instead.
Signed-off-by: NMathias Krause <minipli@googlemail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: NSteffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3110e400
    • C
      crypto: more robust crypto_memneq · fe8c8a12
      由 Cesar Eduardo Barros 提交于 
      Disabling compiler optimizations can be fragile, since a new
optimization could be added to -O0 or -Os that breaks the assumptions
the code is making.

Instead of disabling compiler optimizations, use a dummy inline assembly
(based on RELOC_HIDE) to block the problematic kinds of optimization,
while still allowing other optimizations to be applied to the code.

The dummy inline assembly is added after every OR, and has the
accumulator variable as its input and output. The compiler is forced to
assume that the dummy inline assembly could both depend on the
accumulator variable and change the accumulator variable, so it is
forced to compute the value correctly before the inline assembly, and
cannot assume anything about its value after the inline assembly.

This change should be enough to make crypto_memneq work correctly (with
data-independent timing) even if it is inlined at its call sites. That
can be done later in a followup patch.

Compile-tested on x86_64.
Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.eti.br>
Acked-by: NDaniel Borkmann <dborkman@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      fe8c8a12
  13. 30 11月, 2013 1 次提交
  15. 28 11月, 2013 4 次提交
    • H
      crypto: testmgr - fix sglen in test_aead for case 'dst != src' · 8ec25c51
      由 Horia Geanta 提交于 
      Commit d8a32ac2 (crypto: testmgr - make
test_aead also test 'dst != src' code paths) added support for different
source and destination buffers in test_aead.

This patch modifies the source and destination buffer lengths accordingly:
the lengths are not equal since encryption / decryption adds / removes
the ICV.

Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NHoria Geanta <horia.geanta@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8ec25c51
    • H
      crypto: caam - fix aead sglen for case 'dst != src' · bbf9c893
      由 Horia Geanta 提交于 
      For aead case when source and destination buffers are different,
there is an incorrect assumption that the source length includes the ICV
length. Fix this, since it leads to an oops when using sg_count() to
find the number of nents in the scatterlist:

Unable to handle kernel paging request for data at address 0x00000004
Faulting instruction address: 0xf91f7634
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=8 P4080 DS
Modules linked in: caamalg(+) caam_jr caam
CPU: 1 PID: 1053 Comm: cryptomgr_test Not tainted 3.11.0 #16
task: eeb24ab0 ti: eeafa000 task.ti: eeafa000
NIP: f91f7634 LR: f91f7f24 CTR: f91f7ef0
REGS: eeafbbc0 TRAP: 0300   Not tainted  (3.11.0)
MSR: 00029002 <CE,EE,ME>  CR: 44044044  XER: 00000000
DEAR: 00000004, ESR: 00000000

GPR00: f91f7f24 eeafbc70 eeb24ab0 00000002 ee8e0900 ee8e0800 00000024 c45c4462
GPR08: 00000010 00000000 00000014 0c0e4000 24044044 00000000 00000000 c0691590
GPR16: eeab0000 eeb23000 00000000 00000000 00000000 00000001 00000001 eeafbcc8
GPR24: 000000d1 00000010 ee2d5000 ee49ea10 ee49ea10 ee46f640 ee46f640 c0691590
NIP [f91f7634] aead_edesc_alloc.constprop.14+0x144/0x780 [caamalg]
LR [f91f7f24] aead_encrypt+0x34/0x288 [caamalg]
Call Trace:
[eeafbc70] [a1004000] 0xa1004000 (unreliable)
[eeafbcc0] [f91f7f24] aead_encrypt+0x34/0x288 [caamalg]
[eeafbcf0] [c020d77c] __test_aead+0x3ec/0xe20
[eeafbe20] [c020f35c] test_aead+0x6c/0xe0
[eeafbe40] [c020f420] alg_test_aead+0x50/0xd0
[eeafbe60] [c020e5e4] alg_test+0x114/0x2e0
[eeafbee0] [c020bd1c] cryptomgr_test+0x4c/0x60
[eeafbef0] [c0047058] kthread+0xa8/0xb0
[eeafbf40] [c000eb0c] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
69084321 7d080034 5508d97e 69080001 0f080000 81290024 552807fe 0f080000
3a600001 5529003a 2f8a0000 40dd0028 <80e90004> 3ab50001 8109000c 70e30002
---[ end trace b3c3e23925c7484e ]---

While here, add a tcrypt mode for making it easy to test authenc
(needed for triggering case above).
Signed-off-by: NHoria Geanta <horia.geanta@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bbf9c893
    • H
      crypto: ccm - Fix handling of zero plaintext when computing mac · 5638cabf
      由 Horia Geanta 提交于 
      There are cases when cryptlen can be zero in crypto_ccm_auth():
-encryptiom: input scatterlist length is zero (no plaintext)
-decryption: input scatterlist contains only the mac
plus the condition of having different source and destination buffers
(or else scatterlist length = max(plaintext_len, ciphertext_len)).

These are not handled correctly, leading to crashes like:

root@p4080ds:~/crypto# insmod tcrypt.ko mode=45
------------[ cut here ]------------
kernel BUG at crypto/scatterwalk.c:37!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=8 P4080 DS
Modules linked in: tcrypt(+) crc32c xts xcbc vmac pcbc ecb gcm ghash_generic gf128mul ccm ctr seqiv
CPU: 3 PID: 1082 Comm: cryptomgr_test Not tainted 3.11.0 #14
task: ee12c5b0 ti: eecd0000 task.ti: eecd0000
NIP: c0204d98 LR: f9225848 CTR: c0204d80
REGS: eecd1b70 TRAP: 0700   Not tainted  (3.11.0)
MSR: 00029002 <CE,EE,ME>  CR: 22044022  XER: 20000000

GPR00: f9225c94 eecd1c20 ee12c5b0 eecd1c28 ee879400 ee879400 00000000 ee607464
GPR08: 00000001 00000001 00000000 006b0000 c0204d80 00000000 00000002 c0698e20
GPR16: ee987000 ee895000 fffffff4 ee879500 00000100 eecd1d58 00000001 00000000
GPR24: ee879400 00000020 00000000 00000000 ee5b2800 ee607430 00000004 ee607460
NIP [c0204d98] scatterwalk_start+0x18/0x30
LR [f9225848] get_data_to_compute+0x28/0x2f0 [ccm]
Call Trace:
[eecd1c20] [f9225974] get_data_to_compute+0x154/0x2f0 [ccm] (unreliable)
[eecd1c70] [f9225c94] crypto_ccm_auth+0x184/0x1d0 [ccm]
[eecd1cb0] [f9225d40] crypto_ccm_encrypt+0x60/0x2d0 [ccm]
[eecd1cf0] [c020d77c] __test_aead+0x3ec/0xe20
[eecd1e20] [c020f35c] test_aead+0x6c/0xe0
[eecd1e40] [c020f420] alg_test_aead+0x50/0xd0
[eecd1e60] [c020e5e4] alg_test+0x114/0x2e0
[eecd1ee0] [c020bd1c] cryptomgr_test+0x4c/0x60
[eecd1ef0] [c0047058] kthread+0xa8/0xb0
[eecd1f40] [c000eb0c] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
0f080000 81290024 552807fe 0f080000 5529003a 4bffffb4 90830000 39400000
39000001 8124000c 2f890000 7d28579e <0f090000> 81240008 91230004 4e800020
---[ end trace 6d652dfcd1be37bd ]---

Cc: <stable@vger.kernel.org>
Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NHoria Geanta <horia.geanta@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5638cabf
    • T
      crypto: authenc - Find proper IV address in ablkcipher callback · fc019c71
      由 Tom Lendacky 提交于 
      When performing an asynchronous ablkcipher operation the authenc
completion callback routine is invoked, but it does not locate and use
the proper IV.

The callback routine, crypto_authenc_encrypt_done, is updated to use
the same method of calculating the address of the IV as is done in
crypto_authenc_encrypt function which sets up the callback.

Cc: stable@vger.kernel.org
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      fc019c71
  17. 24 11月, 2013 1 次提交
    • L
      Revert "KEYS: verify a certificate is signed by a 'trusted' key" · 4c1cc40a
      由 Linus Torvalds 提交于 
      This reverts commit 09fbc473, which
caused the following build errors:

  crypto/asymmetric_keys/x509_public_key.c: In function ‘x509_key_preparse’:
  crypto/asymmetric_keys/x509_public_key.c:237:35: error: ‘system_trusted_keyring’ undeclared (first use in this function)
   ret = x509_validate_trust(cert, system_trusted_keyring);
                                   ^
  crypto/asymmetric_keys/x509_public_key.c:237:35: note: each undeclared identifier is reported only once for each function it appears in

reported by Jim Davis. Mimi says:

 "I made the classic mistake of requesting this patch to be upstreamed
  at the last second, rather than waiting until the next open window.

  At this point, the best course would probably be to revert the two
  commits and fix them for the next open window"
Reported-by: NJim Davis <jim.epost@gmail.com>
Acked-by: NMimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4c1cc40a
  19. 21 11月, 2013 1 次提交
    • H
      net: rework recvmsg handler msg_name and msg_namelen logic · f3d33426
      由 Hannes Frederic Sowa 提交于 
      This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys->msg_namelen == 0)
	msg->msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller <davem@davemloft.net>
Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3d33426
  21. 15 11月, 2013 9 次提交
  23. 01 11月, 2013 1 次提交
    • D
      KEYS: The RSA public key algorithm needs to select MPILIB · dbed7141
      由 David Howells 提交于 
      The RSA public key algorithm needs to select MPILIB directly in Kconfig as the
'select' directive is not recursive and is thus MPILIB is not enabled by
selecting MPILIB_EXTRA.

Without this, the following errors can occur:

	crypto/built-in.o: In function `RSA_verify_signature':
	rsa.c:(.text+0x1d347): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d354): undefined reference to `mpi_get_nbits'
	rsa.c:(.text+0x1d36e): undefined reference to `mpi_cmp_ui'
	rsa.c:(.text+0x1d382): undefined reference to `mpi_cmp'
	rsa.c:(.text+0x1d391): undefined reference to `mpi_alloc'
	rsa.c:(.text+0x1d3b0): undefined reference to `mpi_powm'
	rsa.c:(.text+0x1d3c3): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d3d8): undefined reference to `mpi_get_buffer'
	rsa.c:(.text+0x1d4d4): undefined reference to `mpi_free'
	rsa.c:(.text+0x1d503): undefined reference to `mpi_get_nbits'
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      dbed7141
  25. 30 10月, 2013 1 次提交
  27. 26 10月, 2013 3 次提交
  29. 25 10月, 2013 1 次提交
  31. 16 10月, 2013 2 次提交
  33. 07 10月, 2013 2 次提交
    • J
      crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks · 6bf37e5a
      由 James Yonan 提交于 
      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/131Signed-off-by: NJames Yonan <james@openvpn.net>
Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
Cc: Florian Weimer <fw@deneb.enyo.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6bf37e5a
    • K
      crypto: ablk_helper - Replace memcpy with struct assignment · ea493d32
      由 kbuild test robot 提交于 
      tree:   git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head:   48e6dc1b
commit: a62b01cd [20/24] crypto: create generic version of ablk_helper

coccinelle warnings: (new ones prefixed by >>)

>> crypto/ablk_helper.c:97:2-8: Replace memcpy with struct assignment
>> crypto/ablk_helper.c:78:2-8: Replace memcpy with struct assignment

Please consider folding the attached diff :-)
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ea493d32
  35. 05 10月, 2013 1 次提交
    • A
      ARM: add support for bit sliced AES using NEON instructions · e4e7f10b
      由 Ard Biesheuvel 提交于 
      Bit sliced AES gives around 45% speedup on Cortex-A15 for encryption
and around 25% for decryption. This implementation of the AES algorithm
does not rely on any lookup tables so it is believed to be invulnerable
to cache timing attacks.

This algorithm processes up to 8 blocks in parallel in constant time. This
means that it is not usable by chaining modes that are strictly sequential
in nature, such as CBC encryption. CBC decryption, however, can benefit from
this implementation and runs about 25% faster. The other chaining modes
implemented in this module, XTS and CTR, can execute fully in parallel in
both directions.

The core code has been adopted from the OpenSSL project (in collaboration
with the original author, on cc). For ease of maintenance, this version is
identical to the upstream OpenSSL code, i.e., all modifications that were
required to make it suitable for inclusion into the kernel have been made
upstream. The original can be found here:

    http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=6f6a6130

Note to integrators:
While this implementation is significantly faster than the existing table
based ones (generic or ARM asm), especially in CTR mode, the effects on
power efficiency are unclear as of yet. This code does fundamentally more
work, by calculating values that the table based code obtains by a simple
lookup; only by doing all of that work in a SIMD fashion, it manages to
perform better.

Cc: Andy Polyakov <appro@openssl.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      e4e7f10b
  37. 26 9月, 2013 5 次提交