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
> --- a/crypto/Kconfig
> +++ b/crypto/K
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
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
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 find
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
t
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 origi
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 tem
> +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.
sta
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 I set the following kernel option:
>>>
>>> CONFIG_CRYPTO_MANAGER_DISAB
>> + chacha20_block(&crng->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 gi
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(-)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm6
This will allow device drivers to consistently use io{read,write}XX
also for 64-bit accesses.
Signed-off-by: Horia Geantă
---
arch/powerpc/kernel/iomap.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index
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
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ă
---
drivers/crypto/caam/desc.h | 2 +-
drivers/crypto/caam/sg_sw_sec4.h | 8 -
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 100644
--- a/drivers/crypto
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
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
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| 43 +++
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 insertions(+)
diff --git a/i
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 s
On May 4, 2016 10:30:41 AM PDT, ty...@mit.edu wrote:
>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 cr
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 it's never called
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 >> (sizeof(v) * 8 - n));
>>> > +}
>>>
>>> That
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 fr
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:
>>
>> CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
>>
>> Can someone
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 init
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 +
lib/Makefile
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 collector is not trigger
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 it
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
+++ b/drivers/char/random.c
@@ -8
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 line
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 | 283
>
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
> CONFIG_CRYPTO_RNG2=y
> CONFIG_CRYPT
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 th
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 ror32(,shi
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 ba83b16d8430ee6104aa1fee
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, I
>would sugges
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 wr
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 __iome
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 t
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 clea
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 told
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, we're *trying* to
On Wed, May 04, 2016 at 10:28:24PM +0200, Stephan Mueller wrote:
> > +out:
> > + spin_unlock_irqrestore(&primary_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.
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.
>>
>> > This construct has b
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 amount >= the number of bits in the
>>> >> wo
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, commit it.
Its
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 would make
>>> things more consistent
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 seven functions were not
upgraded. I suggest the
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:
On 05/04/2016 02:42 PM, I wrote:
> I find it very odd that th
>>> 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, whic
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 v
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 undefined behavior
On Tue, May 03, 2016 at 12:44:00PM +0100, Salvatore Benedetto wrote:
> Hi Herb,
>
> the following patchset introduces a new API for abstracting key-agreement
> protocols such as DH and ECDH. It provides the primitives required for
> implementing
> the protocol, thus the name KPP (Key-agreement Pr
On 05/04/16 21:03, Jeffrey Walton wrote:
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 s
On Tue, May 03, 2016 at 10:00:17AM +0100, Richard W.M. Jones wrote:
> Running self-tests for a short-lived KVM VM takes 28ms on my laptop.
> This commit adds a flag 'cryptomgr.notests' which allows them to be
> disabled.
>
> However if fips=1 as well, we ignore this flag as FIPS mode mandates
> th
On Wed, May 04, 2016 at 06:38:46AM -0700, Tadeusz Struk wrote:
> 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.
>
57 matches
Mail list logo
