Re: [PATCH 3/3] crypto: brcm: Add Broadcom SPU driver DT entry.

Hi Rob, [auto build test ERROR on cryptodev/master] [also build test ERROR on v4.9-rc8] [cannot apply to next-20161209] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

cc: Viro because I'm talking about iov_iter. On Sat, Dec 10, 2016 at 6:45 AM, Jason A. Donenfeld wrote: > Hi Herbert, > > On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu > wrote: >> As for AEAD we never had a sync interface to begin with and I >> don't

Re: [PATCH] siphash: add cryptographically secure hashtable function

> There's a 32-bit secret random salt (inet_ehash_secret) which means > that in practice, inet_ehashfn() will select 1 out of 2^32 different > hash functions at random each time you boot the kernel; without > knowing which one it selected, how can a local or remote attacker can > force IPv4

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

Hi Herbert, On Sat, Dec 10, 2016 at 6:37 AM, Herbert Xu wrote: > As for AEAD we never had a sync interface to begin with and I > don't think I'm going to add one. That's too bad to hear. I hope you'll reconsider. Modern cryptographic design is heading more and more

Re: [PATCH] siphash: add cryptographically secure hashtable function

On 9 December 2016 at 19:36, Jason A. Donenfeld wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. > > SipHash isn't just some

Re: [kernel-hardening] [PATCH] siphash: add cryptographically secure hashtable function

On Fri, Dec 09, 2016 at 07:36:59PM +0100, Jason A. Donenfeld wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. > > SipHash isn't just some new

RE: [PATCH v6 1/2] sparc: fix a building error reported by kbuild

Regards, -Gonglei > -Original Message- > From: linux-crypto-ow...@vger.kernel.org > [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Sam Ravnborg > Sent: Saturday, December 10, 2016 5:59 AM > To: Gonglei (Arei) > Cc: linux-ker...@vger.kernel.org; qemu-de...@nongnu.org; >

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Sat, Dec 10, 2016 at 04:16:43PM +0800, Herbert Xu wrote: > Why did you drop me from the CC list when you were replying to > my email? > Sorry --- this thread is Cc'ed to the kernel-hardening mailing list (which was somewhat recently revived), and I replied to the email that reached me from

Re: [kernel-hardening] Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

Why did you drop me from the CC list when you were replying to my email? Eric Biggers wrote: > On Sat, Dec 10, 2016 at 01:32:08PM +0800, Herbert Xu wrote: > >> Are you sure? Any instance of *_ON_STACK must only be used with >> sync algorithms and most drivers under

Re: scatterwalk_map_and_copy incorrect optimization

Jason A. Donenfeld wrote: > Hah, looks like I missed [1] by a couple weeks. Looks like it's been > settled then. > > Is this a stable@ candidate? Not really since it shouldn't cause any problems unless the stack is vmalloced. Cheers, -- Email: Herbert Xu

Re: algif for compression?

abed mohammad kamaluddin wrote: > > We are also looking for user-space access to the kernel crypto layer > compression algorithms. I have gone through AF_ALG but couldn’t find > support for compression ops through it. This is required for our > hardware zip engines whose

Re: scatterwalk_map_and_copy incorrect optimization

On Fri, Dec 09, 2016 at 02:18:01PM +0100, Jason A. Donenfeld wrote: > Hi Herbert, > > The scatterwalk_map_and_copy function copies ordinary buffers to and > from scatterlists. These buffers can, of course, be on the stack, and > this remains the most popular use of this function -- getting info >