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

[Jamie Heilman]

Tadeusz Struk wrote:
> On 05/03/2016 07:26 PM, Jamie Heilman wrote:
> >>> Alrighty, presumably relevant bits:
> >>> > >
> >>> > > X.509: Cert Issuer: Build time autogenerated kernel key
> >>> > > X.509: Cert Subject: Build time autogenerated kernel key
> >>> > > X.509: Cert Key Algo: rsa
> >>> > > X.509: Cert Valid period: 1461826791-4615426791
> >>> > > X.509: Cert Signature: rsa + sha512
> >>> > > X.509: ==>x509_check_signature()
> >>> > > X.509: ==>x509_get_sig_params()
> >>> > > X.509: <==x509_get_sig_params() = 0
> >>> > > PKEY: ==>public_key_verify_signature()
> >>> > > X.509: Cert Verification: -2
> >> > 
> >> > Hmmm...  Okay, the only ways out of public_key_verify_signature() without
> >> > printing a leaving message are for snprintf() to overrun (which would 
> >> > return
> >> > error -22) or for crypto_alloc_akcipher() to have failed; everything 
> >> > else must
> >> > go through the kleave() at the pr_devel() at the bottom of the function.
> >> > 
> >> > Can you stick:
> >> > 
> >> >  pr_devel("ALGO: %s\n", alg_name);
> >> > 
> >> > immediately before this line:
> >> > 
> >> >  tfm = crypto_alloc_akcipher(alg_name, 0, 0);
> >> > 
> >> > and try it again?
> > PKEY: ALGO: pkcs1pad(rsa,sha512)
> 
> 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/Kconfig
> @@ -96,6 +96,7 @@ config CRYPTO_AKCIPHER
>  config CRYPTO_RSA
>   tristate "RSA algorithm"
>   select CRYPTO_AKCIPHER
> + select CRYPTO_MANAGER
>   select MPILIB
>   select ASN1
>   help

Yep, that does indeed make everything work again.

-- 
Jamie Heilman http://audible.transient.net/~jamie/
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tadeusz Struk]

On 05/03/2016 07:26 PM, Jamie Heilman wrote:
>>> Alrighty, presumably relevant bits:
>>> > >
>>> > > X.509: Cert Issuer: Build time autogenerated kernel key
>>> > > X.509: Cert Subject: Build time autogenerated kernel key
>>> > > X.509: Cert Key Algo: rsa
>>> > > X.509: Cert Valid period: 1461826791-4615426791
>>> > > X.509: Cert Signature: rsa + sha512
>>> > > X.509: ==>x509_check_signature()
>>> > > X.509: ==>x509_get_sig_params()
>>> > > X.509: <==x509_get_sig_params() = 0
>>> > > PKEY: ==>public_key_verify_signature()
>>> > > X.509: Cert Verification: -2
>> > 
>> > Hmmm...  Okay, the only ways out of public_key_verify_signature() without
>> > printing a leaving message are for snprintf() to overrun (which would 
>> > return
>> > error -22) or for crypto_alloc_akcipher() to have failed; everything else 
>> > must
>> > go through the kleave() at the pr_devel() at the bottom of the function.
>> > 
>> > Can you stick:
>> > 
>> >pr_devel("ALGO: %s\n", alg_name);
>> > 
>> > immediately before this line:
>> > 
>> >tfm = crypto_alloc_akcipher(alg_name, 0, 0);
>> > 
>> > and try it again?
> PKEY: ALGO: pkcs1pad(rsa,sha512)

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/Kconfig
@@ -96,6 +96,7 @@ config CRYPTO_AKCIPHER
 config CRYPTO_RSA
tristate "RSA algorithm"
select CRYPTO_AKCIPHER
+   select CRYPTO_MANAGER
select MPILIB
select ASN1
help

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: algif_skcipher: replace sg++ with sg_next()

[Herbert Xu]

Muhammad Falak R Wani  wrote:
> Never use sg++, always use sg = sg_next(sg). Scatterlist entries can
> be combined if the memory is contiguous but sg++ won't know about
> that. It sure would run on the slower side.
> But regardless, sg++ should never be used, only sg_next is safe.
> 
> Signed-off-by: Muhammad Falak R Wani 

No please the only difference between sg_next and sg++ is chaining,
which is irrelevant here.

Patch rejected.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [crypto / sparc64] cryptomgr_test OOPS

[Herbert Xu]

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 please look at 
>> https://bugzilla.kernel.org/show_bug.cgi?id=117551 ?
> 
> The lib/mpi/ code hasn't been touched in a long time, so I can only see that 
> it might
> be the crypto/rsa.c changes that happened this release.
> 
> Can you possibly bisect this or at least tell us that 4.5 doesn't have this 
> problem?

It would also be helpful to test the latest cryptodev tree which
has a large number of MPI fixes from Nicolai Stange.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Herbert Xu]

On Tue, May 03, 2016 at 06:19:15AM -0400, Sowmini Varadhan wrote:
> On (05/03/16 16:12), Herbert Xu wrote:
> > 
> > Sorry, but your patch doesn't apply against the current tree at all.
> > Please rebase it if it is still needed.
> 
> Hello,
> 
> I had based my patch off of net-next, which is where I do my work.

Please base it on cryptodev.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jamie Heilman]

David Howells wrote:
> (cc'ing Tadeusz as he did the pkcs1 padding function)
> 
> Jamie Heilman  wrote:
> 
> > > > Problem loading in-kernel X.509 certificate (-2)
> > > 
> > > ENOENT?  Hmmm...  The only place that is generated is in the crypto layer.
> > > That suggests missing crypto of some sort.
> > > 
> > > The attached patch enables some debugging in some relevant files if you 
> > > can
> > > try applying it to your kernel.
> > 
> > Alrighty, presumably relevant bits:
> >
> > X.509: Cert Issuer: Build time autogenerated kernel key
> > X.509: Cert Subject: Build time autogenerated kernel key
> > X.509: Cert Key Algo: rsa
> > X.509: Cert Valid period: 1461826791-4615426791
> > X.509: Cert Signature: rsa + sha512
> > X.509: ==>x509_check_signature()
> > X.509: ==>x509_get_sig_params()
> > X.509: <==x509_get_sig_params() = 0
> > PKEY: ==>public_key_verify_signature()
> > X.509: Cert Verification: -2
> 
> Hmmm...  Okay, the only ways out of public_key_verify_signature() without
> printing a leaving message are for snprintf() to overrun (which would return
> error -22) or for crypto_alloc_akcipher() to have failed; everything else must
> go through the kleave() at the pr_devel() at the bottom of the function.
> 
> Can you stick:
> 
>   pr_devel("ALGO: %s\n", alg_name);
> 
> immediately before this line:
> 
>   tfm = crypto_alloc_akcipher(alg_name, 0, 0);
> 
> and try it again?

PKEY: ALGO: pkcs1pad(rsa,sha512)

-- 
Jamie Heilman http://audible.transient.net/~jamie/
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jamie Heilman]

Tadeusz Struk wrote:
> Could you please check if this one fixes the problem for you:
> https://patchwork.kernel.org/patch/8766361/

That patch is already present by 4.6-rc5 and the problem still exists,
so no, it doesn't.

-- 
Jamie Heilman http://audible.transient.net/~jamie/
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Tadeusz Struk]

Hi Jamie,
On 05/03/2016 01:35 PM, David Howells wrote:
> (cc'ing Tadeusz as he did the pkcs1 padding function)
> 
> Jamie Heilman  wrote:
> 
 Problem loading in-kernel X.509 certificate (-2)
>>>
>>> ENOENT?  Hmmm...  The only place that is generated is in the crypto layer.
>>> That suggests missing crypto of some sort.
>>>
>>> The attached patch enables some debugging in some relevant files if you can
>>> try applying it to your kernel.
>>
>> Alrighty, presumably relevant bits:
>>
>> X.509: Cert Issuer: Build time autogenerated kernel key
>> X.509: Cert Subject: Build time autogenerated kernel key
>> X.509: Cert Key Algo: rsa
>> X.509: Cert Valid period: 1461826791-4615426791
>> X.509: Cert Signature: rsa + sha512
>> X.509: ==>x509_check_signature()
>> X.509: ==>x509_get_sig_params()
>> X.509: <==x509_get_sig_params() = 0
>> PKEY: ==>public_key_verify_signature()
>> X.509: Cert Verification: -2
> 
> Hmmm...  Okay, the only ways out of public_key_verify_signature() without
> printing a leaving message are for snprintf() to overrun (which would return
> error -22) or for crypto_alloc_akcipher() to have failed; everything else must
> go through the kleave() at the pr_devel() at the bottom of the function.
> 
> Can you stick:
> 
>   pr_devel("ALGO: %s\n", alg_name);
> 
> immediately before this line:
> 
>   tfm = crypto_alloc_akcipher(alg_name, 0, 0);
> 
> and try it again?
> 

Could you please check if this one fixes the problem for you:
https://patchwork.kernel.org/patch/8766361/
Thanks,
-- 
TS
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

(cc'ing Tadeusz as he did the pkcs1 padding function)

Jamie Heilman  wrote:

> > > Problem loading in-kernel X.509 certificate (-2)
> > 
> > ENOENT?  Hmmm...  The only place that is generated is in the crypto layer.
> > That suggests missing crypto of some sort.
> > 
> > The attached patch enables some debugging in some relevant files if you can
> > try applying it to your kernel.
> 
> Alrighty, presumably relevant bits:
>
> X.509: Cert Issuer: Build time autogenerated kernel key
> X.509: Cert Subject: Build time autogenerated kernel key
> X.509: Cert Key Algo: rsa
> X.509: Cert Valid period: 1461826791-4615426791
> X.509: Cert Signature: rsa + sha512
> X.509: ==>x509_check_signature()
> X.509: ==>x509_get_sig_params()
> X.509: <==x509_get_sig_params() = 0
> PKEY: ==>public_key_verify_signature()
> X.509: Cert Verification: -2

Hmmm...  Okay, the only ways out of public_key_verify_signature() without
printing a leaving message are for snprintf() to overrun (which would return
error -22) or for crypto_alloc_akcipher() to have failed; everything else must
go through the kleave() at the pr_devel() at the bottom of the function.

Can you stick:

pr_devel("ALGO: %s\n", alg_name);

immediately before this line:

tfm = crypto_alloc_akcipher(alg_name, 0, 0);

and try it again?

Thanks,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: algif_skcipher: replace sg++ with sg_next()

[Muhammad Falak R Wani]

Never use sg++, always use sg = sg_next(sg). Scatterlist entries can
be combined if the memory is contiguous but sg++ won't know about
that. It sure would run on the slower side.
But regardless, sg++ should never be used, only sg_next is safe.

Signed-off-by: Muhammad Falak R Wani 
---
 crypto/algif_skcipher.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 28556fc..a668867 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -489,7 +489,7 @@ static int skcipher_all_sg_nents(struct skcipher_ctx *ctx)
sg = sgl->sg;
 
while (!sg->length)
-   sg++;
+   sg = sg_next(sg);
 
nents += sg_nents(sg);
}
@@ -553,7 +553,7 @@ static int skcipher_recvmsg_async(struct socket *sock, 
struct msghdr *msg,
sg = sgl->sg;
 
while (!sg->length)
-   sg++;
+   sg = sg_next(sg);
 
used = min_t(unsigned long, ctx->used,
 iov_iter_count(>msg_iter));
@@ -676,7 +676,7 @@ static int skcipher_recvmsg_sync(struct socket *sock, 
struct msghdr *msg,
sg = sgl->sg;
 
while (!sg->length)
-   sg++;
+   sg = sg_next(sg);
 
skcipher_request_set_crypt(>req, sg, ctx->rsgl.sg, used,
   ctx->iv);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jamie Heilman]

Herbert Xu wrote:
> On Sat, Apr 30, 2016 at 08:32:48AM +, Jamie Heilman wrote:
> > I usually build my kernels to require module signatures and use
> > automatic signing.  As of v4.6-rc1 I'm getting this on boot:
> > 
> > Problem loading in-kernel X.509 certificate (-2)
> > 
> > I bisected that to commit d43de6c780a84def056afaf4fb3e66bdaa1efc00
> > (akcipher: Move the RSA DER encoding check to the crypto layer)
> > 
> > For some reason after this commit my system keyring always ends up
> > empty.  I use the deb-pkg make target.  My kernel config can
> > be found at
> > http://audible.transient.net/~jamie/k/modsign.config-4.6.0-rc5-guest
> > 
> > Let me know if you need anything else.
> 
> David, any ideas on this problem? If we can't get a quick fix
> on this then we'll have to revert.
> 
> Jamie, does reverting this patch by itself resolve the problem?

Haven't tried that, given the nature of the change I just assumed
it would break too much, but I'll give it a shot this evening after
work.

-- 
Jamie Heilman http://audible.transient.net/~jamie/
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jamie Heilman]

David Howells wrote:
> > Problem loading in-kernel X.509 certificate (-2)
> 
> ENOENT?  Hmmm...  The only place that is generated is in the crypto layer.
> That suggests missing crypto of some sort.
> 
> The attached patch enables some debugging in some relevant files if you can
> try applying it to your kernel.

Alrighty, presumably relevant bits:

X.509: Cert Issuer: Build time autogenerated kernel key
X.509: Cert Subject: Build time autogenerated kernel key
X.509: Cert Key Algo: rsa
X.509: Cert Valid period: 1461826791-4615426791
X.509: Cert Signature: rsa + sha512
X.509: ==>x509_check_signature()
X.509: ==>x509_get_sig_params()
X.509: <==x509_get_sig_params() = 0
PKEY: ==>public_key_verify_signature()
X.509: Cert Verification: -2
Problem loading in-kernel X.509 certificate (-2)
...
PKCS7: ==> pkcs7_verify()
PKCS7: ==> pkcs7_verify_one(,1)
PKCS7: ==> pkcs7_digest(,1,sha512)
PKCS7: MsgDigest = [0b f2 1f 7e f0 37 12 e6]
PKCS7: <== pkcs7_digest() = 0
PKCS7: ==> pkcs7_find_key(1)
PKCS7: Sig 1: Issuing X.509 cert not found 
(#008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579)
PKCS7: <== pkcs7_verify() = 0
X.509: Look up: 
"ex:008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579"
X.509: Request for key 
'ex:008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579'
 err -11
PKCS7: ==> pkcs7_verify()
PKCS7: ==> pkcs7_verify_one(,1)
PKCS7: ==> pkcs7_digest(,1,sha512)
PKCS7: MsgDigest = [5b b5 bb 52 28 05 ba 55]
PKCS7: <== pkcs7_digest() = 0
PKCS7: ==> pkcs7_find_key(1)
PKCS7: Sig 1: Issuing X.509 cert not found 
(#008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579)
PKCS7: <== pkcs7_verify() = 0
X.509: Look up: 
"ex:008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579"
X.509: Request for key 
'ex:008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579'
 err -11
PKCS7: ==> pkcs7_verify()
PKCS7: ==> pkcs7_verify_one(,1)
PKCS7: ==> pkcs7_digest(,1,sha512)
PKCS7: MsgDigest = [94 a4 59 31 7f a9 d0 3a]
PKCS7: <== pkcs7_digest() = 0
PKCS7: ==> pkcs7_find_key(1)
PKCS7: Sig 1: Issuing X.509 cert not found 
(#008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579)
PKCS7: <== pkcs7_verify() = 0
X.509: Look up: 
"ex:008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579"
X.509: Request for key 
'ex:008a32081403f1709a312c302a06035504030c234275696c642074696d65206175746f67656e657261746564206b65726e656c206b6579'
 err -11

full dmesg at http://audible.transient.net/~jamie/k/modsign.dmesg-debugging


-- 
Jamie Heilman http://audible.transient.net/~jamie/
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [crypto / sparc64] cryptomgr_test OOPS

[David Miller]

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 please look at https://bugzilla.kernel.org/show_bug.cgi?id=117551 
> ?

The lib/mpi/ code hasn't been touched in a long time, so I can only see that it 
might
be the crypto/rsa.c changes that happened this release.

Can you possibly bisect this or at least tell us that 4.5 doesn't have this 
problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[Nikos Mavrogiannopoulos]

On Tue, May 3, 2016 at 4:48 PM,   wrote:
> On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote:
>> I believe their main concern is that they want to protect applications
>> which do not check error codes of system calls, when running on a
>> kernel which does not provide getrandom().  That way, they have an
>> almost impossible task to simulate getrandom() on kernel which do not
>> support it.
>
> The whole *point* of creating the getrandom(2) system call is that it
> can't be simulated/emulated in userspace.  If it can be, then there's
> no reason why the system call should exist.  This is one of the
> reasons why haven't implemented mysql or TLS inside the kernel.   :-)
> So if their standard is "we need to simulate getrandom(2) on a kernel
> which does not have it", we'll **never** see glibc support for it.  By
> definition, this is *impossible*.

I know, and I share this opinion. To their defense they will have to
provide a call which doesn't make applications fail in the following
scenario:
1. crypto/ssl libraries are compiled to use getrandom() because it is
available in libc and and in kernel
2. everything works fine
3. the administrator downgrades the kernel to a version without
getrandom() because his network card works better with that version
4. Mayhem as applications fail

However I don't see a way to avoid issues - though limited to corner
cases - with any imperfect emulation. It would be much clear for glibc
to just require a kernel with getrandom().

regards,
Nikos
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[Austin S. Hemmelgarn]

On 2016-05-03 09:57, Nikos Mavrogiannopoulos wrote:

On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o  wrote:

On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:

That's far from a solution and I wouldn't recommend to anyone doing
that. We cannot expect each and every program to do glibc's job. The
purpose of a system call like getrandom is to simplify the complex use
of /dev/urandom and eliminate it, not to make code handling randomness
in applications even worse.

Yes, but if glibc is falling down on the job and refusing to export
the system call (I think for political reasons; it's a Linux-only
interface, so Hurd wouldn't have it),


I believe their main concern is that they want to protect applications
which do not check error codes of system calls, when running on a
kernel which does not provide getrandom().  That way, they have an
almost impossible task to simulate getrandom() on kernel which do not
support it.
If it had an existing call, then I could reasonably understand this. 
They have no existing wrapper for it, so this really is just BS.  If an 
application isn't checking error codes, then either:

1. They are intentionally ignoring error codes.
2. It's a bug in the application that needs to be fixed.

The fact that they feel they need to support poorly coded applications 
in _new_ system call wrappers is itself somewhat disturbing.  There are 
no existing applications using this function in glibc because it doesn't 
exist in glibc, which means they can't claim legacy support and 
therefore they want to actively enable people to write stupid programs.

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[tytso]

On Tue, May 03, 2016 at 03:57:15PM +0200, Nikos Mavrogiannopoulos wrote:
> 
> I believe their main concern is that they want to protect applications
> which do not check error codes of system calls, when running on a
> kernel which does not provide getrandom().  That way, they have an
> almost impossible task to simulate getrandom() on kernel which do not
> support it.

The whole *point* of creating the getrandom(2) system call is that it
can't be simulated/emulated in userspace.  If it can be, then there's
no reason why the system call should exist.  This is one of the
reasons why haven't implemented mysql or TLS inside the kernel.   :-)

So if their standard is "we need to simulate getrandom(2) on a kernel
which does not have it", we'll **never** see glibc support for it.  By
definition, this is *impossible*.

What they can do is do something which is as good as you can get for
someone who is open-coding /dev/urandom support in userspace.  That
means that you won't be able to (a) tell if the urandom pool is has
been adequately initialized right after boot, (b) you will need to
somehow deal with the case where the file descriptors have been
exhausted, (c) or if you are running in a chroot where the system
administrator didn't bother to include /dev/urandom.  About the best
you can do is call abort(0), or if you want, you can let the
application author specify some kind of "I want to run in insecure
mode", via some magic glibc setting.  You could probably default this
to "true" without a huge net reduction of security, because most
application authors weren't getting this right anyway.  And then ones
who do care, can set some kind of flag saying, "I promise to check the
error return from getrandom(2) as implemented by glibc".

 - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[Nikos Mavrogiannopoulos]

On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o  wrote:
> On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
>> That's far from a solution and I wouldn't recommend to anyone doing
>> that. We cannot expect each and every program to do glibc's job. The
>> purpose of a system call like getrandom is to simplify the complex use
>> of /dev/urandom and eliminate it, not to make code handling randomness
>> in applications even worse.
> Yes, but if glibc is falling down on the job and refusing to export
> the system call (I think for political reasons; it's a Linux-only
> interface, so Hurd wouldn't have it),

I believe their main concern is that they want to protect applications
which do not check error codes of system calls, when running on a
kernel which does not provide getrandom().  That way, they have an
almost impossible task to simulate getrandom() on kernel which do not
support it.

One may agree with their concerns, but the end result is that we have
not available that system call at all, several years after it is
there.

Anyway it seems that there is some activity now, so hopefully we may
have it sometime soon:
https://sourceware.org/ml/libc-help/2016-04/msg8.html

regards,
Nikos
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[crypto / sparc64] cryptomgr_test OOPS

[Anatoly Pugachev]

Hello!

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 please look at https://bugzilla.kernel.org/show_bug.cgi?id=117551 ?

Thanks.

There's attached kernel config on bugzilla.

kernel OOPS:


SPARC Enterprise T5120, No Keyboard
Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved.
OpenBoot 4.33.6.f, 16256 MB memory available, Serial #78400024.
Ethernet address 0:14:4f:ac:4a:18, Host ID: 84ac4a18.



Boot device: disk1  File and args:
SILO Version 1.4.14
boot:
LinuxLinuxOLD 6
boot: 6
Allocated 64 Megs of memory at 0x4000 for kernel
Uncompressing image...
Loaded kernel version 4.6.0
Loading initial ramdisk (14627617 bytes at 0xC80 phys, 0x40C0 virt)...
/
[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.33.6.f 2014/07/10 10:23'
[0.00] PROMLIB: Root node compatible: sun4v
[0.00] Linux version 4.6.0-rc6+ (mator@deb4g) (gcc version
6.0.1 20160423 (prerelease) (Debian 6.0.1-2) ) #1 SMP Tue May 3
13:49:36 MSK 2016
[0.00] debug: skip boot console de-registration.
[0.00] bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4V
[0.00] Ethernet address: 00:14:4f:ac:4a:18
[0.00] MM: PAGE_OFFSET is 0x8000 (max_phys_bits == 39)
[0.00] MM: VMALLOC [0x0001 --> 0x6000]
[0.00] MM: VMEMMAP [0x6000 --> 0xc000]
[0.00] Kernel: Using 3 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... done.
[0.00] OF stdout device is: /virtual-devices@100/console@1
[0.00] PROM: Built device tree with 195069 bytes of memory.
[0.00] MDESC: Size is 61728 bytes.
[0.00] PLATFORM: banner-name [SPARC Enterprise T5120]
[0.00] PLATFORM: name [SUNW,SPARC-Enterprise-T5120]
[0.00] PLATFORM: hostid [84ac4a18]
[0.00] PLATFORM: serial# [00ab4130]
[0.00] PLATFORM: stick-frequency [457646c0]
[0.00] PLATFORM: mac-address [144fac4a18]
[0.00] PLATFORM: watchdog-resolution [1000 ms]
[0.00] PLATFORM: watchdog-max-timeout [3153600 ms]
[0.00] PLATFORM: max-cpus [64]
[0.00] Top of RAM: 0x3ffb16000, Total RAM: 0x3f76ac000
[0.00] Memory hole size: 132MB
[0.00] Allocated 16384 bytes for kernel page tables.
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x0840-0x0003ffb15fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0840-0x0003ffa89fff]
[0.00]   node   0: [mem 0x0003ffa9a000-0x0003ffaadfff]
[0.00]   node   0: [mem 0x0003ffb08000-0x0003ffb15fff]
[0.00] Initmem setup node 0 [mem 0x0840-0x0003ffb15fff]
[0.00] Booting Linux...
[0.00] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32]
[0.00] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit]
[0.00] percpu: Embedded 9 pages/cpu @8003ff00 s29528
r8192 d36008 u131072
[0.00] SUN4V: Mondo queue sizes [cpu(8192) dev(16384) r(8192) nr(256)]
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 2061296
[0.00] Kernel command line: root=/dev/mapper/vg1-root ro
keep_bootcon console=ttyS0
[0.00] log_buf_len individual max cpu contribution: 4096 bytes
[0.00] log_buf_len total cpu_extra contributions: 258048 bytes
[0.00] log_buf_len min size: 131072 bytes
[0.00] log_buf_len: 524288 bytes
[0.00] early log buf free: 127592(97%)
[0.00] PID hash table entries: 4096 (order: 2, 32768 bytes)
[0.00] Dentry cache hash table entries: 2097152 (order: 11,
16777216 bytes)
[0.00] Inode-cache hash table entries: 1048576 (order: 10,
8388608 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 16433448K/16636592K available (5565K kernel
code, 733K rwdata, 1392K rodata, 456K init, 742K bss, 203144K
reserved, 0K cma-reserved)
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 64.
[0.00]  RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=64.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=64
[0.00] NR_IRQS:2048 nr_irqs:2048 1
[0.00] SUN4V: Using IRQ API major 1, cookie only virqs disabled
[ 7218.283063] clocksource: stick: mask: 0x
max_cycles: 0x10cc5ac4c8a, max_idle_ns: 440795218862 ns
[ 7218.283875] clocksource: mult[dbabc5] shift[24]
[ 7218.284206] clockevent: mult[952b25d1] shift[31]
[ 7218.286792] Console: colour dummy device 80x25
[ 7218.364903] Calibrating delay using timer specific routine..
2337.22 BogoMIPS (lpj=4674457)
[ 7218.365869] pid_max: default: 65536 minimum: 512
[ 7218.367733] Security Framework initialized
[ 

[PATCH 1/3] crypto: Key-agreement Protocol Primitives API (KPP)

[Salvatore Benedetto]

Add key-agreement protocol primitives (kpp) API which allows to
implement primitives required by protocols such as DH and ECDH.
The API is composed mainly by the following functions
 * set_params() - It allows the user to set the parameters known to
   both parties involved in the key-agreement session
 * set_secret() - It allows the user to set his secret, also
   referred to as his private key
 * generate_public_key() - It generates the public key to be sent to
   the other counterpart involved in the key-agreement session. The
   function has to be called after set_params() and set_secret()
 * generate_secret() - It generates the shared secret for the session

Other functions such as init() and exit() are provided for allowing
cryptographic hardware to be inizialized properly before use

Signed-off-by: Salvatore Benedetto 
---
 crypto/Kconfig  |  10 ++
 crypto/Makefile |   1 +
 crypto/crypto_user.c|  20 +++
 crypto/kpp.c| 123 +++
 include/crypto/internal/kpp.h   |  64 
 include/crypto/kpp.h| 333 
 include/linux/crypto.h  |   1 +
 include/uapi/linux/cryptouser.h |   5 +
 8 files changed, 557 insertions(+)
 create mode 100644 crypto/kpp.c
 create mode 100644 include/crypto/internal/kpp.h
 create mode 100644 include/crypto/kpp.h

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 93a1fdc..31bf962 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -93,6 +93,15 @@ config CRYPTO_AKCIPHER
select CRYPTO_AKCIPHER2
select CRYPTO_ALGAPI
 
+config CRYPTO_KPP2
+   tristate
+   select CRYPTO_ALGAPI2
+
+config CRYPTO_KPP
+   tristate
+   select CRYPTO_ALGAPI
+   select CRYPTO_KPP2
+
 config CRYPTO_RSA
tristate "RSA algorithm"
select CRYPTO_AKCIPHER
@@ -114,6 +123,7 @@ config CRYPTO_MANAGER2
select CRYPTO_HASH2
select CRYPTO_BLKCIPHER2
select CRYPTO_AKCIPHER2
+   select CRYPTO_KPP2
 
 config CRYPTO_USER
tristate "Userspace cryptographic algorithm configuration"
diff --git a/crypto/Makefile b/crypto/Makefile
index 4f4ef7e..5b60890 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -30,6 +30,7 @@ crypto_hash-y += shash.o
 obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
 
 obj-$(CONFIG_CRYPTO_AKCIPHER2) += akcipher.o
+obj-$(CONFIG_CRYPTO_KPP2) += kpp.o
 
 $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
 $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index 43fe85f..d28513fb 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -126,6 +127,21 @@ nla_put_failure:
return -EMSGSIZE;
 }
 
+static int crypto_report_kpp(struct sk_buff *skb, struct crypto_alg *alg)
+{
+   struct crypto_report_kpp rkpp;
+
+   strncpy(rkpp.type, "kpp", sizeof(rkpp.type));
+
+   if (nla_put(skb, CRYPTOCFGA_REPORT_KPP,
+   sizeof(struct crypto_report_kpp), ))
+   goto nla_put_failure;
+   return 0;
+
+nla_put_failure:
+   return -EMSGSIZE;
+}
+
 static int crypto_report_one(struct crypto_alg *alg,
 struct crypto_user_alg *ualg, struct sk_buff *skb)
 {
@@ -176,6 +192,10 @@ static int crypto_report_one(struct crypto_alg *alg,
goto nla_put_failure;
 
break;
+   case CRYPTO_ALG_TYPE_KPP:
+   if (crypto_report_kpp(skb, alg))
+   goto nla_put_failure;
+   break;
}
 
 out:
diff --git a/crypto/kpp.c b/crypto/kpp.c
new file mode 100644
index 000..d36ce05
--- /dev/null
+++ b/crypto/kpp.c
@@ -0,0 +1,123 @@
+/*
+ * Key-agreement Protocol Primitives (KPP)
+ *
+ * Copyright (c) 2016, Intel Corporation
+ * Authors: Salvatore Benedetto 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "internal.h"
+
+#ifdef CONFIG_NET
+static int crypto_kpp_report(struct sk_buff *skb, struct crypto_alg *alg)
+{
+   struct crypto_report_kpp rkpp;
+
+   strncpy(rkpp.type, "kpp", sizeof(rkpp.type));
+
+   if (nla_put(skb, CRYPTOCFGA_REPORT_KPP,
+   sizeof(struct crypto_report_kpp), ))
+   goto nla_put_failure;
+   return 0;
+
+nla_put_failure:
+   return -EMSGSIZE;
+}
+#else
+static int crypto_kpp_report(struct sk_buff *skb, struct crypto_alg *alg)
+{
+   return -ENOSYS;
+}
+#endif
+
+static void 

[PATCH 2/3] crypto: kpp - Add DH software implementation

[Salvatore Benedetto]

 * Implement MPI based Diffie-Hellman under kpp API
 * Test provided uses data generad by OpenSSL

Signed-off-by: Salvatore Benedetto 
---
 crypto/Kconfig  |   8 ++
 crypto/Makefile |   2 +
 crypto/dh.c | 224 
 crypto/testmgr.c| 157 
 crypto/testmgr.h| 208 
 include/crypto/dh.h |  23 ++
 6 files changed, 622 insertions(+)
 create mode 100644 crypto/dh.c
 create mode 100644 include/crypto/dh.h

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 31bf962..89db25c 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -110,6 +110,14 @@ config CRYPTO_RSA
help
  Generic implementation of the RSA public key algorithm.
 
+config CRYPTO_DH
+   tristate "Diffie-Hellman algorithm"
+   select CRYPTO_KPP
+   select MPILIB
+   help
+ Generic implementation of the Diffie-Hellman algorithm.
+
+
 config CRYPTO_MANAGER
tristate "Cryptographic algorithm manager"
select CRYPTO_MANAGER2
diff --git a/crypto/Makefile b/crypto/Makefile
index 5b60890..101f8fd 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -32,6 +32,8 @@ obj-$(CONFIG_CRYPTO_HASH2) += crypto_hash.o
 obj-$(CONFIG_CRYPTO_AKCIPHER2) += akcipher.o
 obj-$(CONFIG_CRYPTO_KPP2) += kpp.o
 
+obj-$(CONFIG_CRYPTO_DH) += dh.o
+
 $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
 $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
 clean-files += rsapubkey-asn1.c rsapubkey-asn1.h
diff --git a/crypto/dh.c b/crypto/dh.c
new file mode 100644
index 000..06e4805
--- /dev/null
+++ b/crypto/dh.c
@@ -0,0 +1,224 @@
+/*  Diffie-Hellman Key Agreement Method [RFC2631]
+ *
+ * Copyright (c) 2016, Intel Corporation
+ * Authors: Salvatore Benedetto 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dh_ctx {
+   MPI p;
+   MPI g;
+   MPI xa;
+};
+
+static void dh_free_ctx(struct dh_ctx *ctx)
+{
+   mpi_free(ctx->p);
+   mpi_free(ctx->g);
+   mpi_free(ctx->xa);
+   ctx->p = NULL;
+   ctx->g = NULL;
+   ctx->xa = NULL;
+}
+
+/*
+ * Public key generation function [RFC2631 sec 2.1.1]
+ * ya = g^xa mod p;
+ */
+static int _generate_public_key(const struct dh_ctx *ctx, MPI ya)
+{
+   /* ya = g^xa mod p */
+   return mpi_powm(ya, ctx->g, ctx->xa, ctx->p);
+}
+
+/*
+ * ZZ generation function [RFC2631 sec 2.1.1]
+ * ZZ = yb^xa mod p;
+ */
+static int _compute_shared_secret(const struct dh_ctx *ctx, MPI yb,
+ MPI zz)
+{
+   /* ZZ = yb^xa mod p */
+   return mpi_powm(zz, yb, ctx->xa, ctx->p);
+}
+
+static inline struct dh_ctx *dh_get_ctx(struct crypto_kpp *tfm)
+{
+   return kpp_tfm_ctx(tfm);
+}
+
+static int dh_check_params_length(unsigned int p_len)
+{
+   return (p_len < 1536) ? -EINVAL : 0;
+}
+
+static int dh_set_params(struct crypto_kpp *tfm, void *buffer,
+unsigned int len)
+{
+   struct dh_ctx *ctx = dh_get_ctx(tfm);
+   struct dh_params *params = (struct dh_params *)buffer;
+
+   if (unlikely(!buffer || !len))
+   return -EINVAL;
+
+   if (unlikely(!params->p || !params->g))
+   return -EINVAL;
+
+   if (dh_check_params_length(params->p_size << 3))
+   return -EINVAL;
+
+   ctx->p = mpi_read_raw_data(params->p, params->p_size);
+   if (!ctx->p)
+   return -EINVAL;
+
+   ctx->g = mpi_read_raw_data(params->g, params->g_size);
+   if (!ctx->g) {
+   mpi_free(ctx->p);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int dh_set_secret(struct crypto_kpp *tfm, void *buffer,
+unsigned int len)
+{
+   struct dh_ctx *ctx = dh_get_ctx(tfm);
+
+   if (unlikely(!buffer || !len))
+   return -EINVAL;
+
+   ctx->xa = mpi_read_raw_data(buffer, len);
+
+   if (!ctx->xa)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int dh_generate_public_key(struct kpp_request *req)
+{
+   struct crypto_kpp *tfm = crypto_kpp_reqtfm(req);
+   const struct dh_ctx *ctx = dh_get_ctx(tfm);
+   MPI ya = mpi_alloc(0);
+   int ret = 0;
+   int sign;
+
+   if (!ya)
+   return -ENOMEM;
+
+   if (unlikely(!ctx->p || !ctx->g || !ctx->xa)) {
+   ret = -EINVAL;
+   goto err_free_ya;
+   }
+   ret = _generate_public_key(ctx, ya);
+   if (ret)
+   goto err_free_ya;
+
+   ret = mpi_write_to_sgl(ya, req->dst, >dst_len, );
+   if (ret)
+ 

[PATCH 3/3] crypto: kpp - Add ECDH software support

[Salvatore Benedetto]

 * Implement ECDH under kpp API
 * Provide ECC software support for curve P-192 and
   P-256.
 * Add kpp test for ECDH with data generated by OpenSSL

Signed-off-by: Salvatore Benedetto 
---
 crypto/Kconfig  |5 +
 crypto/Makefile |3 +
 crypto/ecc.c| 1037 +++
 crypto/ecc.h|   74 
 crypto/ecc_curve_defs.h |   57 +++
 crypto/ecdh.c   |  171 
 crypto/testmgr.c|  136 ++-
 crypto/testmgr.h|   73 
 include/crypto/ecdh.h   |   20 +
 9 files changed, 1567 insertions(+), 9 deletions(-)
 create mode 100644 crypto/ecc.c
 create mode 100644 crypto/ecc.h
 create mode 100644 crypto/ecc_curve_defs.h
 create mode 100644 crypto/ecdh.c
 create mode 100644 include/crypto/ecdh.h

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 89db25c..08a1a3b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -117,6 +117,11 @@ config CRYPTO_DH
help
  Generic implementation of the Diffie-Hellman algorithm.
 
+config CRYPTO_ECDH
+   tristate "ECDH algorithm"
+   select CRYTPO_KPP
+   help
+ Generic implementation of the ECDH algorithm
 
 config CRYPTO_MANAGER
tristate "Cryptographic algorithm manager"
diff --git a/crypto/Makefile b/crypto/Makefile
index 101f8fd..ba03079 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -33,6 +33,9 @@ obj-$(CONFIG_CRYPTO_AKCIPHER2) += akcipher.o
 obj-$(CONFIG_CRYPTO_KPP2) += kpp.o
 
 obj-$(CONFIG_CRYPTO_DH) += dh.o
+ecdh_generic-y := ecc.o
+ecdh_generic-y += ecdh.o
+obj-$(CONFIG_CRYPTO_ECDH) += ecdh_generic.o
 
 $(obj)/rsapubkey-asn1.o: $(obj)/rsapubkey-asn1.c $(obj)/rsapubkey-asn1.h
 $(obj)/rsaprivkey-asn1.o: $(obj)/rsaprivkey-asn1.c $(obj)/rsaprivkey-asn1.h
diff --git a/crypto/ecc.c b/crypto/ecc.c
new file mode 100644
index 000..ec5b378
--- /dev/null
+++ b/crypto/ecc.c
@@ -0,0 +1,1037 @@
+/*
+ * Copyright (c) 2013, Kenneth MacKay
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met:
+ *  * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ *  * Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+
+#include "ecc.h"
+#include "ecc_curve_defs.h"
+
+#define MAX_TRIES 16
+
+typedef struct {
+   u64 m_low;
+   u64 m_high;
+} uint128_t;
+
+static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
+{
+   switch (curve_id) {
+   case ECC_CURVE_NIST_P192: return _p192;
+   case ECC_CURVE_NIST_P256: return _p256;
+   default: return NULL;
+   }
+}
+
+static u64 *ecc_alloc_digits_space(unsigned int ndigits)
+{
+   size_t len = ndigits * sizeof(u64);
+
+   if (!len)
+   return NULL;
+
+   return kmalloc(len, GFP_KERNEL);
+}
+
+static void ecc_free_digits_space(u64 *space)
+{
+   kzfree(space);
+}
+
+static struct ecc_point *ecc_alloc_point(unsigned int ndigits)
+{
+   struct ecc_point *p = kmalloc(sizeof(*p), GFP_KERNEL);
+
+   if (!p)
+   return NULL;
+
+   p->x = ecc_alloc_digits_space(ndigits);
+   if (!p->x)
+   goto err_alloc_x;
+
+   p->y = ecc_alloc_digits_space(ndigits);
+   if (!p->y)
+   goto err_alloc_y;
+
+   p->ndigits = ndigits;
+
+   return p;
+
+err_alloc_y:
+   ecc_free_digits_space(p->x);
+err_alloc_x:
+   kfree(p);
+   return NULL;
+}
+
+static void ecc_free_point(struct ecc_point *p)
+{
+   if (!p)
+   return;
+
+   kzfree(p->x);
+   kzfree(p->y);
+   kzfree(p);
+}
+
+static void vli_clear(u64 *vli, unsigned int ndigits)
+{
+   int i;
+
+   for (i = 0; i < ndigits; i++)
+   vli[i] = 0;
+}
+
+/* Returns true if vli == 0, false otherwise. */
+static bool vli_is_zero(const u64 *vli, unsigned 

[PATCH 0/3 v3] Key-agreement Protocol Primitives (KPP) API

[Salvatore Benedetto]

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 Protocol Primitives).

Regards,
Salvatore

Changes from v1:
 * Change check in dh_check_params_length based on Stephan review

Changed from v2:
 * Add support for ECDH (curve P192 and P256). I reused the ecc module
   already present in net/bluetooth and extended it in order to select
   different curves at runtime. Code for P192 was taken from tinycrypt.

Salvatore Benedetto (3):
  crypto: Key-agreement Protocol Primitives API (KPP)
  crypto: kpp - Add DH software implementation
  crypto: kpp - Add ECDH software support

 crypto/Kconfig  |   23 +
 crypto/Makefile |6 +
 crypto/crypto_user.c|   20 +
 crypto/dh.c |  224 +
 crypto/ecc.c| 1037 +++
 crypto/ecc.h|   74 +++
 crypto/ecc_curve_defs.h |   57 +++
 crypto/ecdh.c   |  171 +++
 crypto/kpp.c|  123 +
 crypto/testmgr.c|  275 +++
 crypto/testmgr.h|  281 +++
 include/crypto/dh.h |   23 +
 include/crypto/ecdh.h   |   20 +
 include/crypto/internal/kpp.h   |   64 +++
 include/crypto/kpp.h|  333 +
 include/linux/crypto.h  |1 +
 include/uapi/linux/cryptouser.h |5 +
 17 files changed, 2737 insertions(+)
 create mode 100644 crypto/dh.c
 create mode 100644 crypto/ecc.c
 create mode 100644 crypto/ecc.h
 create mode 100644 crypto/ecc_curve_defs.h
 create mode 100644 crypto/ecdh.c
 create mode 100644 crypto/kpp.c
 create mode 100644 include/crypto/dh.h
 create mode 100644 include/crypto/ecdh.h
 create mode 100644 include/crypto/internal/kpp.h
 create mode 100644 include/crypto/kpp.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[cryptodev:master 56/77] ccp-dmaengine.c:undefined reference to `dma_async_tx_descriptor_init'

[kbuild test robot]

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head:   bc197b2a9c7e0129fa0ec1961881e2a0b3bef967
commit: 58ea8abf490415c390e0cc671e875510c9b66318 [56/77] crypto: ccp - Register 
the CCP as a DMA resource
config: x86_64-randconfig-s4-05031628 (attached as .config)
compiler: gcc-5 (Debian 5.3.1-14) 5.3.1 20160409
reproduce:
git checkout 58ea8abf490415c390e0cc671e875510c9b66318
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the cryptodev/master HEAD bc197b2a9c7e0129fa0ec1961881e2a0b3bef967 builds 
fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

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

[Sowmini Varadhan]

On (05/03/16 16:12), Herbert Xu wrote:
> 
> Sorry, but your patch doesn't apply against the current tree at all.
> Please rebase it if it is still needed.

Hello,

I had based my patch off of net-next, which is where I do my work.

I'd be happy to rebase it on the "current tree", 
but given that mpicoder.c does not have an entry in MAINTAINERS, 
please clarify what you mean by "current tree" in this case.

do you mean

 git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
or
 git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or 
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

(which are the three possible candidates I can see in MAINTAINERS).

It would be nice to get this bug fixed, since the fix is fairly
obvious, and the nuisance factor from the generated "unaligned
access" messages on the impacted non-intel platforms is quite high, 

thanks,
--Sowmini
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

crypto: hash - Fix page length clamping in hash walk

[Herbert Xu]

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 because we
> exit the loop in shash_ahash_update() in this case.

I see.  Does this patch help?

---8<---
The length clamping in the crypto hash walk code is broken if
supplied with an offset greater than or equal to PAGE_SIZE.  This
patch fixes it by borrowing the code from scatterwalk.

Cc: 
Reported-by: Steffen Klassert 
Signed-off-by: Herbert Xu 

diff --git a/crypto/ahash.c b/crypto/ahash.c
index 5fc1f17..2d6c4f1 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -44,8 +44,8 @@ static int hash_walk_next(struct crypto_hash_walk *walk)
 {
unsigned int alignmask = walk->alignmask;
unsigned int offset = walk->offset;
-   unsigned int nbytes = min(walk->entrylen,
- ((unsigned int)(PAGE_SIZE)) - offset);
+   unsigned int nbytes = min_t(unsigned int, walk->entrylen,
+   offset_in_page(~offset) + 1);
 
if (walk->flags & CRYPTO_ALG_ASYNC)
walk->data = kmap(walk->pg);
@@ -91,8 +91,8 @@ int crypto_hash_walk_done(struct crypto_hash_walk *walk, int 
err)
walk->offset = ALIGN(walk->offset, alignmask + 1);
walk->data += walk->offset;
 
-   nbytes = min(nbytes,
-((unsigned int)(PAGE_SIZE)) - walk->offset);
+   nbytes = min_t(unsigned int, nbytes,
+  offset_in_page(~walk->offset) + 1);
walk->entrylen -= nbytes;
 
return nbytes;
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stephan Mueller]

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o:

Hi Theodore,

One more item.

> 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 | 282
> ++ include/crypto/chacha20.h | 
>  1 +
>  lib/Makefile  |   2 +-
>  lib/chacha20.c|  79 +
>  5 files changed, 294 insertions(+), 131 deletions(-)
>  create mode 100644 lib/chacha20.c
> 
> diff --git a/crypto/chacha20_generic.c b/crypto/chacha20_generic.c
> index da9c899..1cab831 100644
> --- a/crypto/chacha20_generic.c
> +++ b/crypto/chacha20_generic.c
> @@ -15,72 +15,11 @@
>  #include 
>  #include 
> 
> -static inline u32 rotl32(u32 v, u8 n)
> -{
> - return (v << n) | (v >> (sizeof(v) * 8 - n));
> -}
> -
>  static inline u32 le32_to_cpuvp(const void *p)
>  {
>   return le32_to_cpup(p);
>  }
> 
> -static void chacha20_block(u32 *state, void *stream)
> -{
> - u32 x[16], *out = stream;
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(x); i++)
> - x[i] = state[i];
> -
> - for (i = 0; i < 20; i += 2) {
> - x[0]  += x[4];x[12] = rotl32(x[12] ^ x[0],  16);
> - x[1]  += x[5];x[13] = rotl32(x[13] ^ x[1],  16);
> - x[2]  += x[6];x[14] = rotl32(x[14] ^ x[2],  16);
> - x[3]  += x[7];x[15] = rotl32(x[15] ^ x[3],  16);
> -
> - x[8]  += x[12];   x[4]  = rotl32(x[4]  ^ x[8],  12);
> - x[9]  += x[13];   x[5]  = rotl32(x[5]  ^ x[9],  12);
> - x[10] += x[14];   x[6]  = rotl32(x[6]  ^ x[10], 12);
> - x[11] += x[15];   x[7]  = rotl32(x[7]  ^ x[11], 12);
> -
> - x[0]  += x[4];x[12] = rotl32(x[12] ^ x[0],   8);
> - x[1]  += x[5];x[13] = rotl32(x[13] ^ x[1],   8);
> - x[2]  += x[6];x[14] = rotl32(x[14] ^ x[2],   8);
> - x[3]  += x[7];x[15] = rotl32(x[15] ^ x[3],   8);
> -
> - x[8]  += x[12];   x[4]  = rotl32(x[4]  ^ x[8],   7);
> - x[9]  += x[13];   x[5]  = rotl32(x[5]  ^ x[9],   7);
> - x[10] += x[14];   x[6]  = rotl32(x[6]  ^ x[10],  7);
> - x[11] += x[15];   x[7]  = rotl32(x[7]  ^ x[11],  7);
> -
> - x[0]  += x[5];x[15] = rotl32(x[15] ^ x[0],  16);
> - x[1]  += x[6];x[12] = rotl32(x[12] ^ x[1],  16);
> - x[2]  += x[7];x[13] = rotl32(x[13] ^ x[2],  16);
> - x[3]  += x[4];x[14] = rotl32(x[14] ^ x[3],  16);
> -
> - x[10] += x[15];   x[5]  = rotl32(x[5]  ^ x[10], 12);
> - x[11] += x[12];   x[6]  = rotl32(x[6]  ^ x[11], 12);
> - x[8]  += x[13];   x[7]  = rotl32(x[7]  ^ x[8],  12);
> - x[9]  += x[14];   x[4]  = rotl32(x[4]  ^ x[9],  12);
> -
> - x[0]  += x[5];x[15] = rotl32(x[15] ^ x[0],   8);
> - x[1]  += x[6];x[12] = rotl32(x[12] ^ x[1],   8);
> - x[2]  += x[7];x[13] = rotl32(x[13] ^ x[2],   8);
> - x[3]  += x[4];x[14] = rotl32(x[14] ^ x[3],   8);
> -
> - x[10] += x[15];   x[5]  = rotl32(x[5]  ^ x[10],  7);
> - x[11] += x[12];   x[6]  = rotl32(x[6]  ^ x[11],  7);
> - x[8]  += x[13];   x[7]  = rotl32(x[7]  ^ x[8],   7);
> - x[9]  += x[14];   x[4]  = rotl32(x[4]  ^ x[9],   7);
> - }
> -
> - for (i = 0; i < ARRAY_SIZE(x); i++)
> - out[i] = cpu_to_le32(x[i] + state[i]);
> -
> - state[12]++;
> -}
> -
>  static void chacha20_docrypt(u32 *state, u8 *dst, const u8 *src,
>unsigned int bytes)
>  {
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index b583e53..95f4451 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -260,6 +260,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -412,6 +413,15 @@ static struct fasync_struct *fasync;
>  static DEFINE_SPINLOCK(random_ready_list_lock);
>  static LIST_HEAD(random_ready_list);
> 
> +/*
> + * crng_init =  0 --> Uninitialized
> + *   2 --> Initialized
> + *   3 --> Initialized from input_pool
> + */
> +static int crng_init = 0;
> +#define crng_ready() (likely(crng_init >= 2))
> +static void process_random_ready_list(void);
> +
>  /**
>   *
>   * OS independent entropy store.   Here are the functions which handle
> @@ -441,10 +451,13 @@ struct entropy_store {
>   __u8 last_data[EXTRACT_SIZE];
>  };
> 
> +static ssize_t extract_entropy(struct entropy_store *r, void *buf,
> +size_t nbytes, int min, int rsvd);
> +
> +static int crng_reseed(struct entropy_store *r);
>  static void push_to_pool(struct work_struct *work);
>  static __u32 input_pool_data[INPUT_POOL_WORDS];
>  static __u32 

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

[David Howells]

> Problem loading in-kernel X.509 certificate (-2)

ENOENT?  Hmmm...  The only place that is generated is in the crypto layer.
That suggests missing crypto of some sort.

The attached patch enables some debugging in some relevant files if you can
try applying it to your kernel.

David
---
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c 
b/crypto/asymmetric_keys/pkcs7_verify.c
index 50be2a15e531..573b3960867b 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -8,7 +8,7 @@
  * as published by the Free Software Foundation; either version
  * 2 of the Licence, or (at your option) any later version.
  */
-
+#define DEBUG
 #define pr_fmt(fmt) "PKCS7: "fmt
 #include 
 #include 
diff --git a/crypto/asymmetric_keys/public_key.c 
b/crypto/asymmetric_keys/public_key.c
index 0f8b264b3961..99f297129381 100644
--- a/crypto/asymmetric_keys/public_key.c
+++ b/crypto/asymmetric_keys/public_key.c
@@ -10,7 +10,7 @@
  * as published by the Free Software Foundation; either version
  * 2 of the Licence, or (at your option) any later version.
  */
-
+#define DEBUG
 #define pr_fmt(fmt) "PKEY: "fmt
 #include 
 #include 
diff --git a/crypto/asymmetric_keys/x509_public_key.c 
b/crypto/asymmetric_keys/x509_public_key.c
index 733c046aacc6..373d472022ef 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -8,7 +8,7 @@
  * as published by the Free Software Foundation; either version
  * 2 of the Licence, or (at your option) any later version.
  */
-
+#define DEBUG
 #define pr_fmt(fmt) "X.509: "fmt
 #include 
 #include 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] crypto: Add a flag allowing the self-tests to be disabled at runtime.

[Richard W.M. Jones]

v2 -> v3:

 - Ignore the flag if FIPS mode is enabled.

v1 -> v2:

 - Use printk_once.  Because the serial console is so slow, printing
   the message multiple times actually consumed about 6ms extra later
   on during the boot.

- - -

I'm trying to reduce the time taken in the kernel in initcalls, with
my aim being to reduce the current ~700ms spent in initcalls before
userspace, down to something like 100ms.  All times on my Broadwell-U
laptop, under virtualization.  The purpose of this is to be able to
launch VMs around containers with minimal overhead, like Intel Clear
Containers, but using standard distro kernels and qemu.

Currently the kernel spends 28ms (on my laptop) running crypto
algorithm self-tests.  Although it's possibe to disable these at
compile time, Fedora kernel maintainers want to maintain a single
kernel image for all uses.

So this commit adds a runtime flag which callers can set to skip the
self-tests in the fast container/virtualization case.

Rich.


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[David Howells]

Jamie Heilman  wrote:

> I usually build my kernels to require module signatures and use
> automatic signing.  As of v4.6-rc1 I'm getting this on boot:
> 
> Problem loading in-kernel X.509 certificate (-2)
> 
> I bisected that to commit d43de6c780a84def056afaf4fb3e66bdaa1efc00
> (akcipher: Move the RSA DER encoding check to the crypto layer)
> 
> For some reason after this commit my system keyring always ends up
> empty.  I use the deb-pkg make target.  My kernel config can
> be found at
> http://audible.transient.net/~jamie/k/modsign.config-4.6.0-rc5-guest

Do you have an example malfunctioning certificate that I can have a look at?

David
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Stephan Mueller]

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o:

Hi Theodore,

> The CRNG is faster, and we don't pretend to track entropy usage in the
> CRNG any more.

In general, I have no concerns with this approach either. And thank you that 
some of my concerns are addressed.

There are few more concerns left open. I would suggest I would write them up 
with a proposal on how to address them.

Some comments inlne:
> 
> Signed-off-by: Theodore Ts'o 
> ---
>  crypto/chacha20_generic.c |  61 --
>  drivers/char/random.c | 282
> ++ include/crypto/chacha20.h | 
>  1 +
>  lib/Makefile  |   2 +-
>  lib/chacha20.c|  79 +
>  5 files changed, 294 insertions(+), 131 deletions(-)
>  create mode 100644 lib/chacha20.c
> 
> diff --git a/crypto/chacha20_generic.c b/crypto/chacha20_generic.c
> index da9c899..1cab831 100644
> --- a/crypto/chacha20_generic.c
> +++ b/crypto/chacha20_generic.c
> @@ -15,72 +15,11 @@
>  #include 
>  #include 
> 
> -static inline u32 rotl32(u32 v, u8 n)
> -{
> - return (v << n) | (v >> (sizeof(v) * 8 - n));
> -}
> -
>  static inline u32 le32_to_cpuvp(const void *p)
>  {
>   return le32_to_cpup(p);
>  }
> 
> -static void chacha20_block(u32 *state, void *stream)
> -{
> - u32 x[16], *out = stream;
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(x); i++)
> - x[i] = state[i];
> -
> - for (i = 0; i < 20; i += 2) {
> - x[0]  += x[4];x[12] = rotl32(x[12] ^ x[0],  16);
> - x[1]  += x[5];x[13] = rotl32(x[13] ^ x[1],  16);
> - x[2]  += x[6];x[14] = rotl32(x[14] ^ x[2],  16);
> - x[3]  += x[7];x[15] = rotl32(x[15] ^ x[3],  16);
> -
> - x[8]  += x[12];   x[4]  = rotl32(x[4]  ^ x[8],  12);
> - x[9]  += x[13];   x[5]  = rotl32(x[5]  ^ x[9],  12);
> - x[10] += x[14];   x[6]  = rotl32(x[6]  ^ x[10], 12);
> - x[11] += x[15];   x[7]  = rotl32(x[7]  ^ x[11], 12);
> -
> - x[0]  += x[4];x[12] = rotl32(x[12] ^ x[0],   8);
> - x[1]  += x[5];x[13] = rotl32(x[13] ^ x[1],   8);
> - x[2]  += x[6];x[14] = rotl32(x[14] ^ x[2],   8);
> - x[3]  += x[7];x[15] = rotl32(x[15] ^ x[3],   8);
> -
> - x[8]  += x[12];   x[4]  = rotl32(x[4]  ^ x[8],   7);
> - x[9]  += x[13];   x[5]  = rotl32(x[5]  ^ x[9],   7);
> - x[10] += x[14];   x[6]  = rotl32(x[6]  ^ x[10],  7);
> - x[11] += x[15];   x[7]  = rotl32(x[7]  ^ x[11],  7);
> -
> - x[0]  += x[5];x[15] = rotl32(x[15] ^ x[0],  16);
> - x[1]  += x[6];x[12] = rotl32(x[12] ^ x[1],  16);
> - x[2]  += x[7];x[13] = rotl32(x[13] ^ x[2],  16);
> - x[3]  += x[4];x[14] = rotl32(x[14] ^ x[3],  16);
> -
> - x[10] += x[15];   x[5]  = rotl32(x[5]  ^ x[10], 12);
> - x[11] += x[12];   x[6]  = rotl32(x[6]  ^ x[11], 12);
> - x[8]  += x[13];   x[7]  = rotl32(x[7]  ^ x[8],  12);
> - x[9]  += x[14];   x[4]  = rotl32(x[4]  ^ x[9],  12);
> -
> - x[0]  += x[5];x[15] = rotl32(x[15] ^ x[0],   8);
> - x[1]  += x[6];x[12] = rotl32(x[12] ^ x[1],   8);
> - x[2]  += x[7];x[13] = rotl32(x[13] ^ x[2],   8);
> - x[3]  += x[4];x[14] = rotl32(x[14] ^ x[3],   8);
> -
> - x[10] += x[15];   x[5]  = rotl32(x[5]  ^ x[10],  7);
> - x[11] += x[12];   x[6]  = rotl32(x[6]  ^ x[11],  7);
> - x[8]  += x[13];   x[7]  = rotl32(x[7]  ^ x[8],   7);
> - x[9]  += x[14];   x[4]  = rotl32(x[4]  ^ x[9],   7);
> - }
> -
> - for (i = 0; i < ARRAY_SIZE(x); i++)
> - out[i] = cpu_to_le32(x[i] + state[i]);
> -
> - state[12]++;
> -}
> -
>  static void chacha20_docrypt(u32 *state, u8 *dst, const u8 *src,
>unsigned int bytes)
>  {
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index b583e53..95f4451 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -260,6 +260,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -412,6 +413,15 @@ static struct fasync_struct *fasync;
>  static DEFINE_SPINLOCK(random_ready_list_lock);
>  static LIST_HEAD(random_ready_list);
> 
> +/*
> + * crng_init =  0 --> Uninitialized
> + *   2 --> Initialized
> + *   3 --> Initialized from input_pool
> + */
> +static int crng_init = 0;

shouldn't that be an atomic_t ?

> +#define crng_ready() (likely(crng_init >= 2))
> +static void process_random_ready_list(void);
> +
>  /**
>   *
>   * OS independent entropy store.   Here are the functions which handle
> @@ -441,10 +451,13 @@ struct entropy_store {
>   __u8 last_data[EXTRACT_SIZE];
>  };
> 
> +static ssize_t extract_entropy(struct entropy_store 

RE: [PATCH] crypto: talitos: fix driver init

[Alexandru Ardelean]

I was notified by a fellow member of the OpenWrt list that the talitos was 
already fixed in the crypto-dev repo so I backported that patch into our tree.

He also pointed out (gracefully) that I was a bit naive with regard to the fact 
that just setting the statesize is not enough.

Sorry for the noise.

Thanks
Alex


From: Kim Phillips [kim.phill...@arm.com]
Sent: Saturday, April 30, 2016 1:55 AM
To: Alexandru Ardelean
Cc: linux-crypto@vger.kernel.org; Alexandru Ardelean
Subject: Re: [PATCH] crypto: talitos: fix driver init

On Thu, 28 Apr 2016 17:15:30 +0300
Alexandru Ardelean  wrote:

> From: Alexandru Ardelean 
>
> Crypto hash algorithms must provide the statesize sometime
> from kernel 4.2 onwards.
> Since commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a
>
> Signed-off-by: Alexandru Ardelean 
> ---

This should already have been fixed here:

www.spinics.net/lists/linux-crypto/msg19225.html

> @@ -2458,6 +2458,7 @@ static struct talitos_alg_template driver_algs[] = {
>   {   .type = CRYPTO_ALG_TYPE_AHASH,
>   .alg.hash = {
>   .halg.digestsize = MD5_DIGEST_SIZE,
> + .halg.statesize  = sizeof(struct talitos_ahash_req_ctx),

although I'm not sure why these statesize assignments aren't being
done in talitos_alg_alloc() there either

Thanks,

Kim
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] crypto: Use dma_pool_zalloc

[Herbert Xu]

On Fri, Apr 29, 2016 at 10:09:11PM +0200, Julia Lawall wrote:
> Dma_pool_zalloc combines dma_pool_alloc and memset 0.  The semantic patch
> that makes this transformation is as follows: (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> expression d,e;
> statement S;
> @@
> 
> d =
> -dma_pool_alloc
> +dma_pool_zalloc
>  (...);
> if (!d) S
> -   memset(d, 0, sizeof(*d));
> // 
> 
> Signed-off-by: Julia Lawall 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: constify ccp_actions structure

[Herbert Xu]

On Sun, May 01, 2016 at 01:52:55PM +0200, Julia Lawall wrote:
> The ccp_actions structure is never modified, so declare it as const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: qat - fix adf_ctl_drv.c:undefined reference to adf_init_pf_wq

[Herbert Xu]

On Fri, Apr 29, 2016 at 10:43:40AM -0700, Tadeusz Struk wrote:
> Fix undefined reference issue reported by kbuild test robot.
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Tadeusz Struk 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: omap-des: Integrate with the crypto engine framework

[Herbert Xu]

On Thu, Apr 28, 2016 at 02:11:51PM +0800, Baolin wrote:
> Since the crypto engine framework had been merged, thus this patch integrates
> with the newly added crypto engine framework to make the crypto hardware
> engine under utilized as each block needs to be processed before the crypto
> hardware can start working on the next block.
> 
> The crypto engine framework can manage and process the requests automatically,
> so remove the 'queue' and 'queue_task' things in omap des driver.
> 
> Signed-off-by: Baolin 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: omap-aes: Use dma_request_chan() for requesting DMA channel

[Herbert Xu]

On Fri, Apr 29, 2016 at 04:02:18PM +0300, Peter Ujfalusi wrote:
> With the new dma_request_chan() the client driver does not need to look for
> the DMA resource and it does not need to pass filter_fn anymore.
> By switching to the new API the driver can now support deferred probing
> against DMA.
> 
> Signed-off-by: Peter Ujfalusi 
> CC: Herbert Xu 
> CC: David S. Miller 
> CC: Lokesh Vutla 

All applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] crypto: qat - Fix typo in comments

[Herbert Xu]

On Fri, Apr 29, 2016 at 10:59:59AM -0700, Tadeusz Struk wrote:
> Fix copy and paste typo adf_isr.c
> 
> Signed-off-by: Tadeusz Struk 

Both applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: vmx - comply with ABIs that specify vrsave as reserved.

[Herbert Xu]

On Fri, Apr 29, 2016 at 11:03:05AM -0300, Paulo Flabiano Smorigo wrote:
> It gives significant improvements ( ~+15%) on some modes.
> 
> These code has been adopted from OpenSSL project in collaboration
> with the original author (Andy Polyakov ).

No sign-off.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Herbert Xu]

On Wed, Apr 27, 2016 at 09:08:27PM -0400, Sowmini Varadhan wrote:
> On (04/28/16 09:01), Herbert Xu wrote:
> > Subject: Re: [PATCH v2] lib/mpi: Fix kernel unaligned access in
> >  mpi_write_to_sgl
> > 
> > Please cc linux-crypto.
> 
> Just bounced the message to linux-crypto as well. 
> I think get_maintainers.pl might also need to be updated to 
> generate this automatically.

Sorry, but your patch doesn't apply against the current tree at all.
Please rebase it if it is still needed.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: rsa - return raw integer for the ASN.1 parser

[Herbert Xu]

On Fri, Apr 29, 2016 at 03:51:46PM +0300, Tudor Ambarus wrote:
>
>  struct rsa_key {
> + u8 *n;
> + u8 *e;
> + u8 *d;
> + dma_addr_t dma_n;
> + dma_addr_t dma_e;
> + dma_addr_t dma_d;
> + size_t n_sz;
> + size_t e_sz;
> + bool coherent;
> + gfp_t flags;

Please don't put the DMA primitives in the generic helper.  They
should stay in the driver for now.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Herbert Xu]

On Sat, Apr 30, 2016 at 08:32:48AM +, Jamie Heilman wrote:
> I usually build my kernels to require module signatures and use
> automatic signing.  As of v4.6-rc1 I'm getting this on boot:
> 
> Problem loading in-kernel X.509 certificate (-2)
> 
> I bisected that to commit d43de6c780a84def056afaf4fb3e66bdaa1efc00
> (akcipher: Move the RSA DER encoding check to the crypto layer)
> 
> For some reason after this commit my system keyring always ends up
> empty.  I use the deb-pkg make target.  My kernel config can
> be found at
> http://audible.transient.net/~jamie/k/modsign.config-4.6.0-rc5-guest
> 
> Let me know if you need anything else.

David, any ideas on this problem? If we can't get a quick fix
on this then we'll have to revert.

Jamie, does reverting this patch by itself resolve the problem?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Regarding mechanism to store/retrive the private data structure in any SHA/AEAD/ablkcipher algos

[Herbert Xu]

On Thu, Apr 28, 2016 at 10:38:39AM +0530, Pramod Kumar wrote:
> Hi Herbert Xu/ James Morris/ David
> 
> 
> 
> I was writing driver for one of my secure processing unit(SPU) which
> offloads all SHA/AEAD/ablkciphers.
> 
> 
> 
> While registering algos for crypto subsystem I could not find any way where
> I could store my SPU private data structure and retrieve it in any alog
> callback to maintain things related to SPU like we have in platform or
> other drivers where we could store our private structure and retrieve it in
> its callback?

Other drivers don't seem to have any issues with storing device
data, e.g., talitos.c.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Use dma_pool_zalloc

[Vinod Koul]

On Fri, Apr 29, 2016 at 10:09:07PM +0200, Julia Lawall wrote:
> Dma_pool_zalloc combines dma_pool_alloc and memset 0.  The semantic patch
> that makes this transformation is as follows: (http://coccinelle.lip6.fr/)

Applied all dmaengine patches

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html