[RFC PATCH 2/2] crypto: caam - fix k*alloc if called from own cipher callback

There are cases (e.g. the cts mode) where a cipher can be called again from its own callback. In our case this callback is executed from within a tasklet in the jobring, we must not sleep when allocating memory. This patch detects such cases by using in_interrupt() to properly set the k*alloc

[RFC PATCH 0/2] crypto: caam - fix cts(cbc(aes)) with CAAM driver

Hi! While testing fscrypt's filename encryption, I noticed that the implementation of cts(cbc(aes)) is broken when the CAAM hardware crypto driver is enabled. Some digging showed that the refactoring of crypto/cts.c in v4.8 (commit 0605c41cc53ca) exposed some problems with CAAM's aes-cbc

Re: [PATCH v3 13/13] ARM: dts: sunxi: add SoC specific compatibles for the crypto nodes

On Thu, Jun 01, 2017 at 09:39:05PM +0200, Antoine Tenart wrote: > Add SoC specific compatibles for all sunXi crypto nodes, in addition to > the one already used (allwinner,sun4i-a10-crypto). > > Signed-off-by: Antoine Tenart Applied, thanks! Maxime -- Maxime

Re: [PATCH v3 12/13] ARM: sun5i: add a cryptographic engine node

On Thu, Jun 01, 2017 at 09:39:04PM +0200, Antoine Tenart wrote: > Add a node for the cryptographic engine that can be found on sun5i SoCs. > This cryptographic engine is compatible with the Allwinner cryptographic > accelerator driver. > > Signed-off-by: Antoine Tenart

[RFC PATCH 1/2] crypto: caam - properly set IV after {en,de}crypt

Certain cipher modes like CTS expect the IV (req->info) of ablkcipher_request (or equivalently req->iv of skcipher_request) to contain the last ciphertext block when the {en,de}crypt operation is done. This is currently not the case for the CAAM driver which in turn breaks e.g. cts(cbc(aes)) when

Re: [PATCH v3 2/5] crypto : stm32 - Add STM32F4 CRC32 support

Hi Fabien, Thanks for your review. On Mon, May 29, 2017 at 07:56:48AM +, Fabien DESSENNE wrote: > Hi Cosar, > > Thank you for the patch > > On 22/05/17 16:34, Cosar Dindar wrote: > > This patch adds CRC (CRC32 Crypto) support for STM32F4 series. > > > > As an hardware limitation polynomial

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

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 or interrupt arrives at just the right instruction. It only occurs if the function ends

get_random_bytes returns bad randomness before seeding is complete

Hi folks, This email is about an issue with get_random_bytes(), the CSPRNG used inside the kernel for generating keys and nonces and whatnot. However, I will begin with an aside: /dev/urandom will return bad randomness before its seeded, rather than blocking, and despite years and years of

Re: get_random_bytes returns bad randomness before seeding is complete

Further investigations: if the whack-a-mole approach is desirable, perhaps many of those get_random_bytes calls should be converted to get_blocking_random_bytes. In that case, this commit, which removed this helpful API, should be reverted: commit c2719503f5e1e6213d716bb078bdad01e28ebcbf Author:

Re: get_random_bytes returns bad randomness before seeding is complete

(Meanwhile...) In my own code, I'm currently playing with a workaround that looks like this: --- a/src/main.c +++ b/src/main.c +#include +#include +struct rng_initializer { + struct completion done; + struct random_ready_callback cb; +}; +static void

Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 02, 2017 at 04:59:56PM +0200, Jason A. Donenfeld wrote: > /dev/urandom will return bad randomness before its seeded, rather than > blocking, and despite years and years of discussion and bike shedding, > this behavior hasn't changed, and the vast majority of cryptographers > and

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 2, 2017 at 7:41 PM, Daniel Micay wrote: > One of the early uses is initializing the stack canary value for SSP in > very early boot. If that blocks, it's going to be blocking nearly > anything else from happening. > > On x86, that's only the initial canary since

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

From: "Darrick J. Wong" Date: Fri, 2 Jun 2017 11:08:08 -0700 > ext4/jbd2's crc32c implementations will also need a fix like this for > {ext4,jbd2}_chksum. Note that both of these modules call the crypto api > directly to avoid a static dependence on libcrc32c; this was

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 2, 2017 at 10:41 AM, Daniel Micay wrote: > On Fri, 2017-06-02 at 17:53 +0200, Jason A. Donenfeld wrote: >> (Meanwhile...) >> >> In my own code, I'm currently playing with a workaround that looks >> like this: >> >> --- a/src/main.c >> +++ b/src/main.c >> >>

Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 02, 2017 at 07:44:04PM +0200, Jason A. Donenfeld wrote: > On Fri, Jun 2, 2017 at 7:26 PM, Theodore Ts'o wrote: > > I tried making /dev/urandom block. > > So if you're a security focused individual who is kvetching > > And if we're breaking > > Yes yes, bla bla,

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

[add ext4 list to cc] On Fri, Jun 02, 2017 at 11:28:54AM -0400, David Miller wrote: > > 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 >

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, 2017-06-02 at 17:53 +0200, Jason A. Donenfeld wrote: > (Meanwhile...) > > In my own code, I'm currently playing with a workaround that looks > like this: > > --- a/src/main.c > +++ b/src/main.c > > +#include > +#include > > +struct rng_initializer { > + struct completion done;

Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 2, 2017 at 7:26 PM, Theodore Ts'o wrote: > I tried making /dev/urandom block. > So if you're a security focused individual who is kvetching > And if we're breaking Yes yes, bla bla, predictable response. I don't care. Your API is still broken. Excuses excuses. Yes,

[PATCH] Staging: ccree: ssi_aead.h: Fixed a pointer declaration error.

Fixed a pointer declaration error , the dereferencing operator was misplaced. Signed-off-by: srishti sharma --- drivers/staging/ccree/ssi_aead.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/ccree/ssi_aead.h

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

From: David Miller Date: Fri, 02 Jun 2017 14:39:06 -0400 (EDT) > From: "Darrick J. Wong" > Date: Fri, 2 Jun 2017 11:08:08 -0700 > >> ext4/jbd2's crc32c implementations will also need a fix like this for >> {ext4,jbd2}_chksum. Note that both of

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

The only sensible & general solution for the initialisation problem that I have seen is John Denker's. http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image If I read that right, it would require only minor kernel changes & none to the API Ted & others are worrying about. It would be

[PATCH RFC 0/3] get_random_bytes seed blocking

Per the other thread on this mailing list, here's an initial stab at what we discussed -- adding a blocking API for the RNG, and adding a default-on dmesg Kconfig value for when things go wrong. Let me know what you think of this general implementation strategy, and if you like it, I'll move

[PATCH RFC 1/3] 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 | 46

[PATCH RFC 3/3] 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 RFC 2/3] random: add get_random_{bytes,u32,u64,int,long}_wait family

These functions are simple convience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/random.h | 30 ++ 1 file changed, 30 insertions(+) diff --git

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 03, 2017 at 01:58:25AM +0200, Jason A. Donenfeld wrote: > Hi Ted, > > Based on the tone of your last email, before I respond to your > individual points May I gently point out that *your* tone that started this whole thread has been pretty terrible? Quoting your your first

Re: get_random_bytes returns bad randomness before seeding is complete

Hi Ted, Based on the tone of your last email, before I respond to your individual points, I think it's worth noting that the intent of this thread is to get a sampling of opinions of the issue of get_random_bytes, so that I can write a patch that fixes this issue (or a series of issues) using