Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > ... > But instead of arguing over what works and doesn't, let's just create > the the test set and just try it on a wide range of compilers and > architectures, hmmm? What are the requirements? Here's a short list: * No

Re: better patch for linux/bitops.h

Instead of arguing over who's "sane" or "insane", can we come up with a agreed upon set of tests, and a set of compiler and compiler versions for which these tests must achieve at least *working* code? Bonus points if they achieve optimal code, but what's important is that for a wide range of GCC

Re: better patch for linux/bitops.h

>>> So you are actually saying outright that we should sacrifice *actual* >>portability in favor of *theoretical* portability? What kind of >>twilight zone did we just step into?! >> >>I'm not sure what you mean. It will be well defined on all platforms. >>Clang may not recognize the pattern,

Re: better patch for linux/bitops.h

On May 4, 2016 7:54:12 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: >> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton >wrote: >>>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote:

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: > On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >>> On 05/04/2016 02:42 PM, I wrote: >>> I find it very odd that the other

Re: better patch for linux/bitops.h

On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >> On 05/04/2016 02:42 PM, I wrote: >> >>> I find it very odd that the other seven functions were not >>> upgraded. I suggest the attached fix-others.diff

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: > On 05/04/2016 02:42 PM, I wrote: > >> I find it very odd that the other seven functions were not >> upgraded. I suggest the attached fix-others.diff would make >> things more consistent. > > Here's a replacement patch. > ... +1,

Re: linux/bitops.h

On May 4, 2016 6:20:32 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote: >> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>> >> Beware that shifting by an

Re: linux/bitops.h

On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote: > On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >> >> Beware that shifting by an amount >= the number of bits in the >> >> word remains Undefined Behavior. >> >>

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 04, 2016 at 10:28:24PM +0200, Stephan Mueller wrote: > > +out: > > + spin_unlock_irqrestore(_crng.lock, flags); > > + return ret; > > Where did you add the memzero_explict of tmp? Oops, sorry, somehow that change got lost in the patch updates. Fixed now.

Re: linux/bitops.h

On Wed, May 4, 2016 at 5:30 PM, H. Peter Anvin wrote: > > Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, and the > description even says so. > > As I said, gcc has treated the former code as idiomatic since gcc 2, so that > support is beyond ancient. Well,

Re: linux/bitops.h

On 05/04/16 15:06, John Denker wrote: On 05/04/2016 02:56 PM, H. Peter Anvin wrote: Beware that shifting by an amount >= the number of bits in the word remains Undefined Behavior. This construct has been supported as a rotate since at least gcc2. How then should we understand the story

Re: linux/bitops.h

On 05/04/2016 04:06 PM, Andi Kleen wrote: > gcc always converts it before it could [make a difference]. At the moment, current versions of gcc treat the idiomatic ror/rol code as something they support ... but older versions do not, and future version may not. The gcc guys have made it very

Re: linux/bitops.h

On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: > On 05/04/2016 02:56 PM, H. Peter Anvin wrote: > >> Beware that shifting by an amount >= the number of bits in the > >> word remains Undefined Behavior. > > > This construct has been supported as a rotate since at least gcc2. > > How

Re: [PATCH 1/7] asm-generic/io.h: add io{read,write}64 accessors

On Wednesday 04 May 2016 20:16:19 Horia Geantă wrote: > @@ -625,6 +645,16 @@ static inline u32 ioread32be(const volatile void __iomem > *addr) > } > #endif > > +#ifdef CONFIG_64BIT > +#ifndef ioread64be > +#define ioread64be ioread64be > +static inline u64 ioread64be(const volatile void

Re: linux/bitops.h

On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >> Beware that shifting by an amount >= the number of bits in the >> word remains Undefined Behavior. > This construct has been supported as a rotate since at least gcc2. How then should we understand the story told in commit d7e35dfa? Is the story

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On May 4, 2016 2:42:53 PM PDT, John Denker wrote: >On 05/04/2016 12:07 PM, ty...@thunk.org wrote: > >> it doesn't hit the >> UB case which Jeffrey was concerned about. > >That should be good enough for present purposes > >However, in the interests of long-term maintainability,

Re: better patch for linux/bitops.h

On 05/04/2016 02:42 PM, I wrote: > I find it very odd that the other seven functions were not > upgraded. I suggest the attached fix-others.diff would make > things more consistent. Here's a replacement patch. Same idea, less brain damage. Sorry for the confusion. commit

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On 05/04/2016 12:07 PM, ty...@thunk.org wrote: > it doesn't hit the > UB case which Jeffrey was concerned about. That should be good enough for present purposes However, in the interests of long-term maintainability, I would suggest sticking in a comment or assertion saying that

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On 05/04/2016 12:07 PM, ty...@thunk.org wrote: > > If we are all agreed that what is in bitops.h is considered valid, > then we can start converting people over to using the version defined > in bitops.h, and if there is some compiler issue we need to work > around, at least we only need to put

Re: [crypto / sparc64] cryptomgr_test OOPS

From: Anatoly Pugachev Date: Wed, 4 May 2016 22:10:47 +0300 > Here's a quick diff related to crypto for debian kernel configs: > > $ diff -u /boot/config-4.5.0-2-sparc64-smp /boot/config-4.6.0-rc5-sparc64-smp > @@ -5299,10 +5380,9 @@ > CONFIG_CRYPTO_RNG=m >

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

Am Mittwoch, 4. Mai 2016, 15:25:48 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- > drivers/char/random.c |

Re: [crypto / sparc64] cryptomgr_test OOPS

Hi Anatoly, On 05/04/2016 12:10 PM, Anatoly Pugachev wrote: > we're using 4.5.2 debian kernel here without this problem. I'm not > sure I would be able to bisect, never did it before, but I could > try... On 4.5.2 could you try "modprobe rsa" -- TS -- To unsubscribe from this list: send the

[PATCH 3/4] random: add interrupt callback to VMBus IRQ handler

From: Stephan Mueller The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy

[PATCH 2/4] random: make /dev/urandom scalable for silly userspace programs

On a system with a 4 socket (NUMA) system where a large number of application threads were all trying to read from /dev/urandom, this can result in the system spending 80% of its time contending on the global urandom spinlock. The application should have used its own PRNG, but let's try to help

[PATCH 4/4] random: add backtracking protection to the CRNG

Signed-off-by: Theodore Ts'o --- drivers/char/random.c | 35 +-- 1 file changed, 33 insertions(+), 2 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 897c75e..028d085 100644 --- a/drivers/char/random.c +++

[PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. Signed-off-by: Theodore Ts'o --- crypto/chacha20_generic.c | 61 -- drivers/char/random.c | 283 +++--- include/crypto/chacha20.h | 1 +

[PATCH -v2 0/4] random: replace urandom pool with a CRNG

By using a CRNG to replace the urandom pool, we address a number of complaints which Stephan Mueller has been concerned about. We now use a much more aggressive interrupt sampling system to quickly initialize a CRNG which gets used in place of the original non-blocking pool. This tends to get

Re: [crypto / sparc64] cryptomgr_test OOPS

On Tue, May 3, 2016 at 7:33 PM, David Miller wrote: > From: Anatoly Pugachev > Date: Tue, 3 May 2016 16:54:18 +0300 > >> I have git kernel OOPS (4.6.0-rc6) on sparc64. This OOPS does not >> happen, if I set the following kernel option: >> >>

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 04, 2016 at 11:29:57AM -0700, H. Peter Anvin wrote: > > We don't care about UB, we care about gcc, and to a lesser extent > LLVM and ICC. If bitops.h doesn't do the right thing, we need to > fix bitops.h. I'm going to suggest that we treat the ro[rl]{32,64}() question as separable

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On May 4, 2016 11:22:25 AM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 1:49 PM, wrote: >> On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >>> > +static inline u32 rotl32(u32 v, u8 n) >>> > +{ >>> > + return (v << n) | (v >>

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 4, 2016 at 1:49 PM, wrote: > On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >> > +static inline u32 rotl32(u32 v, u8 n) >> > +{ >> > + return (v << n) | (v >> (sizeof(v) * 8 - n)); >> > +} >> >> That's undefined behavior when n=0. > > Sure, but

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: > > +static inline u32 rotl32(u32 v, u8 n) > > +{ > > + return (v << n) | (v >> (sizeof(v) * 8 - n)); > > +} > > That's undefined behavior when n=0. Sure, but it's never called with n = 0; I've double checked and the compiler

[PATCH 1/7] asm-generic/io.h: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Signed-off-by: Horia Geantă --- include/asm-generic/io.h| 63 + include/asm-generic/iomap.h | 8 ++ 2 files changed, 71

[PATCH 7/7] arm64: dts: ls1043a: add crypto node

LS1043A has a SEC v5.4 security engine. For now don't add rtic or sec_mon subnodes, since these features haven't been tested yet. Signed-off-by: Horia Geantă --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 4 +++ arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi|

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On Tue, May 03, 2016 at 10:50:25AM +0200, Stephan Mueller wrote: > > +/* > > + * crng_init = 0 --> Uninitialized > > + * 2 --> Initialized > > + * 3 --> Initialized from input_pool > > + */ > > +static int crng_init = 0; > > shouldn't that be an atomic_t ? The crng_init variable

[PATCH 0/7] crypto: caam - add support for LS1043A SoC

Hi, [Patches 1-3 add io{read,write}64[be] accessors (generic, arm64, ppc64), such that CAAM's accessors in regs.h are simplified a bit. Patch 7 adds crypto node for LS1043A platform. Let me know if it's ok to go with these through the cryptodev-2.6 tree.] This is a follow-up on the following RFC

[PATCH 6/7] crypto: caam - add ARCH_LAYERSCAPE to supported architectures

This basically adds support for ls1043a platform. Signed-off-by: Horia Geantă --- drivers/crypto/caam/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig index d2c2909a4020..ff54c42e6e51

[PATCH 5/7] crypto: caam - handle core endianness != caam endianness

There are SoCs like LS1043A where CAAM endianness (BE) does not match the default endianness of the core (LE). Moreover, there are requirements for the driver to handle cases like CPU_BIG_ENDIAN=y on ARM-based SoCs. This requires for a complete rewrite of the I/O accessors. PPC-specific accessors

[PATCH 4/7] crypto: caam - fix offset field in hw sg entries

From: Cristian Stoica The offset field is 13 bits wide; make sure we don't overwrite more than that in the caam hardware scatter gather structure. Signed-off-by: Cristian Stoica Signed-off-by: Horia Geantă ---

[PATCH 2/7] arm64: add io{read,write}64be accessors

This will allow device drivers to consistently use io{read,write}XXbe also for 64-bit accesses. Signed-off-by: Alex Porosanu Signed-off-by: Horia Geantă --- arch/arm64/include/asm/io.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

>> + chacha20_block(>state[0], out); >> + if (crng->state[12] == 0) >> + crng->state[13]++; > > state[12]++? Or why do you increment the nonce? In Bernstein's Salsa and ChaCha, the counter is 64-bit. It appears ChaCha-TLS uses a 32-bit counter, and the other 32-bits is given

Re: [crypto / sparc64] cryptomgr_test OOPS

On Wed, May 4, 2016 at 7:07 AM, Herbert Xu wrote: > David Miller wrote: >> From: Anatoly Pugachev >> Date: Tue, 3 May 2016 16:54:18 +0300 >> >>> I have git kernel OOPS (4.6.0-rc6) on sparc64. This OOPS does not >>> happen, if

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

> +static inline u32 rotl32(u32 v, u8 n) > +{ > + return (v << n) | (v >> (sizeof(v) * 8 - n)); > +} That's undefined behavior when n=0. I think the portable way to do a rotate that avoids UB is the following. GCC, Clang and ICC recognize the pattern, and emit a rotate instruction.

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Hi David On 05/04/2016 02:01 AM, David Howells wrote: > Do you want to push this via Herbert's tree? > Yes, I think Herbert has some more patches queued for rc-7. Let me also send a proper one with the signed-off tag. ---8<--- Subject: crypto: rsa - select crypto mgr dependency The pkcs1pad

Re: [PATCH v2] crypto: hash - Fix page length clamping in hash walk

On (05/04/16 12:08), Steffen Klassert wrote: > > > Sowmini, could you please doublecheck with your test setup? > > > > Don't bother, my patch was crap. Here's one that's more likely > > to work: > > This one is much better, works here :) The patch seems to work, but the caveat is that the

Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in mpi_write_to_sgl

On (05/04/16 10:32), Herbert Xu wrote: > > Please base it on cryptodev. > Looks like this got fixed in cryptodev by commit cece762f6f3c ("lib/mpi: mpi_write_sgl(): fix out-of-bounds stack access") Thanks, --Sowmini -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in

Re: [PATCH v2] crypto: hash - Fix page length clamping in hash walk

On Wed, May 04, 2016 at 05:52:56PM +0800, Herbert Xu wrote: > On Wed, May 04, 2016 at 11:34:20AM +0200, Steffen Klassert wrote: > > > > Hmm, the 'sleeping while atomic' because of not unmapping > > the page goes away, but now I see a lot of IPsec ICV fails > > on the receive side. I'll try to

[PATCH v2] crypto: hash - Fix page length clamping in hash walk

On Wed, May 04, 2016 at 11:34:20AM +0200, Steffen Klassert wrote: > > Hmm, the 'sleeping while atomic' because of not unmapping > the page goes away, but now I see a lot of IPsec ICV fails > on the receive side. I'll try to find out what's going on. > > Sowmini, could you please doublecheck with

Re: crypto: hash - Fix page length clamping in hash walk

On Tue, May 03, 2016 at 05:55:31PM +0800, Herbert Xu wrote: > On Thu, Apr 28, 2016 at 10:27:43AM +0200, Steffen Klassert wrote: > > > > The problem was that if offset (in a superpage) equals > > PAGE_SIZE in hash_walk_next(), nbytes becomes zero. So > > we map the page, but we don't hash and unmap

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Tadeusz Struk wrote: > I think the problem is that pkcs1pad template needs CRYPTO_MANAGER, but > your configuration doesn't enable CRYPTO_MANAGER. Could you try this > please: > > diff --git a/crypto/Kconfig b/crypto/Kconfig > index 93a1fdc..1d33beb 100644 > ---

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Dienstag, 3. Mai 2016, 11:36:12 schrieb Stephan Mueller: Hi Ted, > > + > > +static ssize_t extract_crng_user(void __user *buf, size_t nbytes) > > +{ > > + ssize_t ret = 0, i; > > + __u8 tmp[CHACHA20_BLOCK_SIZE]; > > + int large_request = (nbytes > 256); > > + > > + while (nbytes) { >