linux-stable.git/include/crypto, branch linux-3.10.y

crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks

2017-06-07T22:46:46+00:00

commit 6bf37e5aa90f18baf5acf4874bca505dd667c37f upstream.

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 
Signed-off-by: Daniel Borkmann 
Cc: Florian Weimer 
Signed-off-by: Herbert Xu 
Cc: Jason A. Donenfeld 
Signed-off-by: Willy Tarreau

crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path

2017-02-06T08:04:07+00:00

commit 6a935170a980024dd29199e9dbb5c4da4767a1b9 upstream.

This patch allows af_alg_release_parent to be called even for
nokey sockets.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Willy Tarreau

crypto: hash - Add crypto_ahash_has_setkey

2017-02-06T08:04:07+00:00

commit a5596d6332787fd383b3b5427b41f94254430827 upstream.

This patch adds a way for ahash users to determine whether a key
is required by a crypto_ahash transform.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Willy Tarreau

crypto: af_alg - Add nokey compatibility path

2017-02-06T08:04:07+00:00

commit 37766586c965d63758ad542325a96d5384f4a8c9 upstream.

This patch adds a compatibility path to support old applications
that do acept(2) before setkey.

Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu 
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Willy Tarreau

crypto: af_alg - Disallow bind/setkey/... after accept(2)

2017-02-06T08:04:07+00:00

commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.

Each af_alg parent socket obtained by socket(2) corresponds to a
tfm object once bind(2) has succeeded.  An accept(2) call on that
parent socket creates a context which then uses the tfm object.

Therefore as long as any child sockets created by accept(2) exist
the parent socket must not be modified or freed.

This patch guarantees this by using locks and a reference count
on the parent socket.  Any attempt to modify the parent socket will
fail with EBUSY.

Cc: stable@vger.kernel.org
Reported-by: Dmitry Vyukov 
Signed-off-by: Herbert Xu 
Signed-off-by: Andrey Ryabinin 
Signed-off-by: Willy Tarreau

Revert: "crypto: af_alg - Disallow bind/setkey/... after accept(2)"

2016-03-16T15:41:37+00:00

This reverts commit 5a707f0972e1c9d8a4a921ddae79d0f9dc36a341 which is
commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.

It's been widely reported that this patch breaks existing userspace
applications when backported to the stable kernel releases.  As no fix
seems to be forthcoming, just revert it to let systems work again.

Reported-by: "J. Paul Reed" 
Cc: Dmitry Vyukov 
Cc: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: af_alg - Disallow bind/setkey/... after accept(2)

2016-02-19T22:22:41+00:00

commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.

Each af_alg parent socket obtained by socket(2) corresponds to a
tfm object once bind(2) has succeeded.  An accept(2) call on that
parent socket creates a context which then uses the tfm object.

Therefore as long as any child sockets created by accept(2) exist
the parent socket must not be modified or freed.

This patch guarantees this by using locks and a reference count
on the parent socket.  Any attempt to modify the parent socket will
fail with EBUSY.

Reported-by: Dmitry Vyukov 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: scatterwalk - Use sg_chain_ptr on chain entries

2013-12-12T06:36:29+00:00

commit 389a5390583a18e45bc4abd4439291abec5e7a63 upstream.

Now that scatterwalk_sg_chain sets the chain pointer bit the sg_page
call in scatterwalk_sg_next hits a BUG_ON when CONFIG_DEBUG_SG is
enabled. Use sg_chain_ptr instead of sg_page on a chain entry.

Signed-off-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: scatterwalk - Set the chain pointer indication bit

2013-12-12T06:36:26+00:00

commit 41da8b5adba77e22584f8b45f9641504fa885308 upstream.

The scatterwalk_crypto_chain function invokes the scatterwalk_sg_chain
function to chain two scatterlists, but the chain pointer indication
bit is not set.  When the resulting scatterlist is used, for example,
by sg_nents to count the number of scatterlist entries, a segfault occurs
because sg_nents does not follow the chain pointer to the chained scatterlist.

Update scatterwalk_sg_chain to set the chain pointer indication bit as is
done by the sg_chain function.

Signed-off-by: Tom Lendacky 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: sha512 - Expose generic sha512 routine to be callable from other modules

2013-04-25T13:00:57+00:00

Other SHA512 routines may need to use the generic routine when
FPU is not available.

Signed-off-by: Tim Chen 
Signed-off-by: Herbert Xu