[BUGFIX PATCH] staging: ccree: fix buffer copy

Fix a bug where the copying of scatterlist buffers incorrectly ignored bytes to skip in a scatterlist and ended 1 byte short. This fixes testmgr hmac and hash test failures currently obscured by hash import/export not being supported. Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW

Re: [PATCH RFC v2 0/8] get_random_bytes_wait family of APIs

On Tue, Jun 06, 2017 at 01:47:25AM +0200, Jason A. Donenfeld wrote: > As this RFC series matures, all the changes are in this branch here, to look > at: > > https://git.zx2c4.com/linux-dev/log/?h=jd/rng-blocker > > Ted -- there's one, in particular, that should probably be picked up >

Re: [PATCH v3 05/13] security/keys: ensure RNG is seeded before use

Jason A. Donenfeld wrote: > + key->serial = get_random_u32() >> 1; If this may sleep, it must be interruptible. David

Re: [PATCH 1/4] dt-bindings: rng: add generic bindings for MediaTek SoCs

On 31/05/17 20:44, sean.w...@mediatek.com wrote: From: Sean Wang Add the generic binding for allowing the support of RNG on MediaTek SoCs such as MT7622. Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/rng/mtk-rng.txt | 3 ++-

[PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

The crypto engine could actually only enqueue hash and ablkcipher request. This patch permit it to enqueue skcipher requets by adding all necessary functions. The only problem is that ablkcipher and skcipher id are the same, so only one cipher type is usable on the same crypto engine.

[PATCH v2 0/2] crypto: engine - Permit to enqueue skcipher request

The crypto engine could actually only enqueue hash and ablkcipher request. This patch serie permit it to enqueue skcipher requets by adding all necessary functions. Changes since v1 - Aligned to column struct *dev in include - Added missing mutex_unlock in crypto_engine_start() Corentin Labbe

[PATCH v2 1/2] crypto: engine - replace pr_xxx by dev_xxx

By adding a struct device *dev to struct engine, we could store the device used at register time and so use all dev_xxx functions instead of pr_xxx. Signed-off-by: Corentin Labbe --- crypto/crypto_engine.c | 23 +-- include/crypto/engine.h | 1 +

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

Am Dienstag, 6. Juni 2017, 15:44:17 CEST schrieb Corentin Labbe: Hi Corentin, > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue skcipher requets by adding all necessary > functions. > The only problem is that ablkcipher and skcipher id

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

On Tue, Jun 06, 2017 at 04:07:25PM +0200, Stephan Müller wrote: > Am Dienstag, 6. Juni 2017, 15:44:17 CEST schrieb Corentin Labbe: > > Hi Corentin, > > > The crypto engine could actually only enqueue hash and ablkcipher request. > > This patch permit it to enqueue skcipher requets by adding all

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Hey again Eric, One thing led to another and I wound up just rewriting all the crypto in big_keys.c. I'll include this for v4: https://git.zx2c4.com/linux-dev/commit/?h=jd/rng-blocker=886ff283b9808aecb14aa8e397da8496a9635aed Not only was the use of crypto/rng inappropriate, but the decision to

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Hi Jason, On Tue, Jun 06, 2017 at 05:23:04PM +0200, Jason A. Donenfeld wrote: > Hey again Eric, > > One thing led to another and I wound up just rewriting all the crypto > in big_keys.c. I'll include this for v4: > >

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 07:19:10PM -0300, Henrique de Moraes Holschuh wrote: > On that same idea, one could add an early_initramfs handler for entropy > data. > > One could also ensure the kernel command line is used to feed some > entropy for the CRNG init (for all I know, this is already being

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

On Tue, Jun 06, 2017 at 03:04:08PM -0400, David Miller wrote: > From: David Miller > Date: Fri, 02 Jun 2017 11:28:54 -0400 (EDT) > > > > > On sparc, if we have an alloca() like situation, as is the case with > > SHASH_DESC_ON_STACK(), we can end up referencing deallocated

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, 06 Jun 2017, Theodore Ts'o wrote: > It might be possible, for example, to store a cryptographic key in a > UEFI boot-services variable, where the key becomes inaccessible after > the boot-time services terminate. But you also need either a reliable > time-of-day clock, or a reliable

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Hi Eric, On Tue, Jun 6, 2017 at 6:44 AM, Eric Biggers wrote: > I don't think big_key even needs randomness at init time. The 'big_key_rng' > could just be removed and big_key_gen_enckey() changed to call > get_random_bytes(). (Or get_random_bytes_wait(), I guess; it's only

Re: [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Tue, Jun 6, 2017 at 7:11 AM, Jeffrey Walton wrote: > On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote: >> These functions are simple convenience wrappers that call >> wait_for_random_bytes before calling the respective get_random_* >> function. > >

Re: [PATCH RFC v2 0/8] get_random_bytes_wait family of APIs

On Tue, Jun 6, 2017 at 9:45 AM, Greg Kroah-Hartman wrote: > If it's needed no matter what, can you make it the first patch in the > series? And does it need to go to any older kernels as well? I believe it does belong in older kernels too. I'll work out precisely

Re: [PATCH v3 05/13] security/keys: ensure RNG is seeded before use

On Tue, Jun 6, 2017 at 12:08 PM, David Howells wrote: > Jason A. Donenfeld wrote: > >> + key->serial = get_random_u32() >> 1; > > If this may sleep, it must be interruptible. That won't sleep. I could have made it get_random_u32_wait(), but we'd

Re: [PATCH 1/4] Staging: ccree: cc_crypto_ctx.h: Added * on subsequent lines of a comment block.

On Sun, Jun 4, 2017 at 1:49 PM, Greg KH wrote: > On Sun, Jun 04, 2017 at 05:02:08AM +0530, srishti sharma wrote: >> Added * on subsequent lines of a comment block. >> >> Signed-off-by: srishti sharma >> --- >>

[PATCH v2 net-next 1/4] tcp: ULP infrastructure

Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP sockets. Based on a similar infrastructure in tcp_cong. The idea is that any ULP can add its own logic by changing the TCP proto_ops structure to its own methods. Example usage: setsockopt(sock, SOL_TCP, TCP_ULP, "tls",

[PATCH v2 net-next 0/4] kernel TLS

This series adds support for kernel TLS encryption over TCP sockets. A standard TCP socket is converted to a TLS socket using a setsockopt. Only symmetric crypto is done in the kernel, as well as TLS record framing. The handshake remains in userspace, and the negotiated cipher keys/iv are

[PATCH v4 06/13] iscsi: ensure RNG is seeded before use

It's not safe to use weak random data here, especially for the challenge response randomness. Since we're always in process context, it's safe to simply wait until we have enough randomness to carry out the authentication correctly. While we're at it, we clean up a small memleak during an error

[PATCH v4 02/13] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 41

[PATCH v4 00/13] Unseeded In-Kernel Randomness Fixes

As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs involves adding a simple blocking API so that modules that use the RNG in process context can just sleep

[PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is sometimes when this is used. Signed-off-by: Jason A. Donenfeld Cc: Steve French

[PATCH v4 04/13] security/keys: ensure RNG is seeded before use

Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). However, we can't change to using a

[PATCH v4 05/13] crypto/rng: ensure that the RNG is ready before using

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. The one use of this function from within the kernel -- not from userspace -- is being removed (keys/big_key), so that call site isn't relevant in assessing this. Cc: Herbert Xu

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Am Dienstag, 6. Juni 2017, 19:03:19 CEST schrieb Theodore Ts'o: Hi Theodore, > On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote: > > Yes, I agree whole-heartedly. A lot of people have proposals for > > fixing the direct idea of entropy gathering, but for whatever reason, > >

[PATCH v2 net-next 3/4] tls: kernel TLS support

Software implementation of transport layer security, implemented using ULP infrastructure. tcp proto_ops are replaced with tls equivalents of sendmsg and sendpage. Only symmetric crypto is done in the kernel, keys are passed by setsockopt after the handshake is complete. All control messages

[PATCH v2 net-next 2/4] tcp: export do_tcp_sendpages and tcp_rate_check_app_limited functions

Export do_tcp_sendpages and tcp_rate_check_app_limited, since tls will need to sendpages while the socket is already locked. tcp_sendpage is exported, but requires the socket lock to not be held already. Signed-off-by: Aviad Yehezkel Signed-off-by: Ilya Lesokhin

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 6, 2017 at 7:26 PM, Eric Biggers wrote: > I agree that the use of ECB mode in big_key is broken, and thanks for trying > to > fix it! I think using GCM is good, but please leave a very conspicuous > comment > where the nonce is being set to 0, noting that it's

[PATCH v4 01/13] random: invalidate batched entropy after crng init

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to

[PATCH v4 03/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

These functions are simple convenience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.h | 25

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote: > > Yes, I agree whole-heartedly. A lot of people have proposals for > fixing the direct idea of entropy gathering, but for whatever reason, > Ted hasn't merged stuff. I think Stephan (CCd) rewrote big critical > sections of the

[PATCH v2 net-next 4/4] tls: Documentation

Add documentation for the tcp ULP tls interface. Signed-off-by: Boris Pismenny Signed-off-by: Dave Watson --- Documentation/networking/tls.txt | 135 +++ 1 file changed, 135 insertions(+) create mode 100644

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 6, 2017 at 7:03 PM, Theodore Ts'o wrote: > So it's not clear what you mean by Stephan's work. I just meant that there's a guy out there who seems really motivated to work on this stuff in detail, but hasn't seen too much love, AFAIK. I'm sure there's an interesting

[PATCH v4 11/13] net/route: use get_random_int for random counter

Using get_random_int here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Also, semantically, it's not really proper to have been assigning an

[PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

This protocol uses lots of complex cryptography that relies on securely generated random numbers. Thus, it's important that the RNG is actually seeded before use. Fortuantely, it appears we're always operating in process context (there are many GFP_KERNEL allocations and other sleeping

[PATCH v4 13/13] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it

[PATCH v4 10/13] net/neighbor: use get_random_u32 for 32-bit hash random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Signed-off-by: Jason A. Donenfeld Cc: David Miller

[PATCH v4 07/13] ceph: ensure RNG is seeded before using

Ceph uses the RNG for various nonce generations, and it shouldn't accept using bad randomness. So, we wait for the RNG to be properly seeded. We do this by calling wait_for_random_bytes() in a function that is certainly called in process context, early on, so that all subsequent calls to

[PATCH v4 09/13] rhashtable: use get_random_u32 for hash_rnd

This is much faster and just as secure. It also has the added benefit of probably returning better randomness at early-boot on systems with architectural RNGs. Signed-off-by: Jason A. Donenfeld Cc: Thomas Graf Cc: Herbert Xu ---

Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 6, 2017 at 7:57 PM, Stephan Müller wrote: > Finally, I am very surprised that I get hardly any answers on patches to > random.c let alone that any changes to random.c will be applied at all. FWIW, this is my biggest concern too. You seem willing to work on this

Re: crypto: Work around deallocated stack frame reference gcc bug on sparc.

From: David Miller Date: Fri, 02 Jun 2017 11:28:54 -0400 (EDT) > > On sparc, if we have an alloca() like situation, as is the case with > SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack > memory. The result can be that the value is clobbered if a trap >