Re: linux/bitops.h

2016-05-06 Thread H. Peter Anvin 
On May 6, 2016 1:07:13 PM PDT, Sasha Levin  wrote:
>On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
>> 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 in commit d7e35dfa?
>>> Is the story wrong?
>>>
>>> At the very least, something inconsistent is going on.  There
>>> are 8 functions.  Why did d7e35dfa change one of them but
>>> not the other 7?
>> 
>> Yes. d7e35dfa is baloney IMNSHO.  All it does is produce worse code,
>and the description even says so.
>
>No, the description says that it produces worse code for *really
>really* ancient
>GCC versions.
>
>> As I said, gcc has treated the former code as idiomatic since gcc 2,
>so that support is beyond ancient.
>
>Because something works in a specific way on one compiler isn't a
>reason to
>ignore this noncompliance with the standard.
>
>
>Thanks,
>Sasha

When the compiler in question is our flagship target and our reference 
compiler, then yes, it matters.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
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: linux/bitops.h

2016-05-06 Thread H. Peter Anvin 
On May 6, 2016 1:07:13 PM PDT, Sasha Levin  wrote:
>On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
>> 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 in commit d7e35dfa?
>>> Is the story wrong?
>>>
>>> At the very least, something inconsistent is going on.  There
>>> are 8 functions.  Why did d7e35dfa change one of them but
>>> not the other 7?
>> 
>> Yes. d7e35dfa is baloney IMNSHO.  All it does is produce worse code,
>and the description even says so.
>
>No, the description says that it produces worse code for *really
>really* ancient
>GCC versions.
>
>> As I said, gcc has treated the former code as idiomatic since gcc 2,
>so that support is beyond ancient.
>
>Because something works in a specific way on one compiler isn't a
>reason to
>ignore this noncompliance with the standard.
>
>
>Thanks,
>Sasha

4.6.2 is not "really, really ancient."
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
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: linux/bitops.h

2016-05-06 Thread Sasha Levin 
On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
> 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 in commit d7e35dfa?
>> Is the story wrong?
>>
>> At the very least, something inconsistent is going on.  There
>> are 8 functions.  Why did d7e35dfa change one of them but
>> not the other 7?
> 
> Yes. d7e35dfa is baloney IMNSHO.  All it does is produce worse code, and the 
> description even says so.

No, the description says that it produces worse code for *really really* ancient
GCC versions.

> As I said, gcc has treated the former code as idiomatic since gcc 2, so that 
> support is beyond ancient.

Because something works in a specific way on one compiler isn't a reason to
ignore this noncompliance with the standard.


Thanks,
Sasha
--
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

2016-05-06 Thread David Miller 
From: Herbert Xu 
Date: Thu, 5 May 2016 16:42:49 +0800

> Subject: crypto: testmgr - Use kmalloc memory for RSA input
> 
> As akcipher uses an SG interface, you must not use vmalloc memory
> as input for it.  This patch fixes testmgr to copy the vmalloc
> test vectors to kmalloc memory before running the test.
> 
> This patch also removes a superfluous sg_virt call in do_test_rsa.
> 
> Cc: 
> Reported-by: Anatoly Pugachev 
> Signed-off-by: Herbert Xu 

I'm really surprised this didn't trigger on non-sparc64 systems, but
what do I know :-)
--
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 RESEND v5 6/6] crypto: AF_ALG - add support for key_id

2016-05-06 Thread Stephan Mueller 
Am Donnerstag, 5. Mai 2016, 12:51:20 schrieb Tadeusz Struk:

Hi Tadeusz,

> This patch adds support for asymmetric key type to AF_ALG.
> It will work as follows: A new PF_ALG socket options are
> added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
> ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID for setting public and
> private keys respectively. When these new options will be used
> the user, instead of providing the key material, will provide a
> key id and the key itself will be obtained from kernel keyring
> subsystem. The user will use the standard tools (keyctl tool
>   or the keyctl syscall) for key instantiation and to obtain the
> key id. The key id can also be obtained by reading the
> /proc/keys file.
> 
> When a key corresponding to the given keyid is found, it is stored
> in the socket context and subsequent crypto operation invoked by the
> user will use the new asymmetric accessor functions instead of akcipher
> api. The asymmetric subtype can internally use akcipher api or
> invoke operations defined by a given subtype, depending on the
> key type.
> 
> Signed-off-by: Tadeusz Struk 
> ---
>  crypto/af_alg.c |   10 ++
>  crypto/algif_akcipher.c |  207
> ++- include/crypto/if_alg.h |  
>  1
>  include/uapi/linux/if_alg.h |2
>  4 files changed, 215 insertions(+), 5 deletions(-)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 24dc082..59c8244 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -260,6 +260,16 @@ static int alg_setsockopt(struct socket *sock, int
> level, int optname,
> 
>   err = alg_setkey(sk, optval, optlen, type->setpubkey);
>   break;
> +
> + case ALG_SET_KEY_ID:
> + case ALG_SET_PUBKEY_ID:
> + /* ALG_SET_KEY_ID is only for akcipher */
> + if (!strcmp(type->name, "akcipher") ||
> + sock->state == SS_CONNECTED)
> + goto unlock;
> +
> + err = alg_setkey(sk, optval, optlen, type->setkeyid);
> + break;
>   case ALG_SET_AEAD_AUTHSIZE:
>   if (sock->state == SS_CONNECTED)
>   goto unlock;
> diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
> index e00793d..f486b6d 100644
> --- a/crypto/algif_akcipher.c
> +++ b/crypto/algif_akcipher.c
> @@ -14,6 +14,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +31,7 @@ struct akcipher_sg_list {
> 
>  struct akcipher_tfm {
>   struct crypto_akcipher *akcipher;
> + char keyid[12];
>   bool has_key;
>  };
> 
> @@ -37,6 +40,7 @@ struct akcipher_ctx {
>   struct af_alg_sgl rsgl[ALG_MAX_PAGES];
> 
>   struct af_alg_completion completion;
> + struct key *key;
> 
>   unsigned long used;
> 
> @@ -322,6 +326,153 @@ unlock:
>   return err ? err : size;
>  }
> 
> +static int asym_key_encrypt(const struct key *key, struct akcipher_request
> *req) +{
> + struct kernel_pkey_params params = {0};
> + char *src = NULL, *dst = NULL, *in, *out;
> + int ret;
> +
> + if (!sg_is_last(req->src)) {
> + src = kmalloc(req->src_len, GFP_KERNEL);
> + if (!src)
> + return -ENOMEM;
> + scatterwalk_map_and_copy(src, req->src, 0, req->src_len, 0);
> + in = src;
> + } else {
> + in = sg_virt(req->src);
> + }
> + if (!sg_is_last(req->dst)) {
> + dst = kmalloc(req->dst_len, GFP_KERNEL);
> + if (!dst) {
> + kfree(src);
> + return -ENOMEM;
> + }
> + out = dst;
> + } else {
> + out = sg_virt(req->dst);
> + }
> + params.key = (struct key *)key;
> + params.data_len = req->src_len;
> + params.enc_len = req->dst_len;
> + ret = encrypt_blob(, in, out);
> + if (ret)
> + goto free;
> +
> + if (dst)
> + scatterwalk_map_and_copy(dst, req->dst, 0, req->dst_len, 1);
> +free:
> + kfree(src);
> + kfree(dst);
> + return ret;
> +}
> +
> +static int asym_key_decrypt(const struct key *key, struct akcipher_request
> *req) +{
> + struct kernel_pkey_params params = {0};
> + char *src = NULL, *dst = NULL, *in, *out;
> + int ret;
> +
> + if (!sg_is_last(req->src)) {
> + src = kmalloc(req->src_len, GFP_KERNEL);
> + if (!src)
> + return -ENOMEM;
> + scatterwalk_map_and_copy(src, req->src, 0, req->src_len, 0);
> + in = src;
> + } else {
> + in = sg_virt(req->src);
> + }
> + if (!sg_is_last(req->dst)) {
> + dst = kmalloc(req->dst_len, GFP_KERNEL);
> + if (!dst) {
> + kfree(src);
> + return -ENOMEM;
> + }
> + out = dst;
> + } else {
> + out =

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

2016-05-06 Thread Stephan Mueller 
Am Donnerstag, 5. Mai 2016, 10:17:37 schrieb Salvatore Benedetto:

Hi Salvatore,

>  * 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| 1038
> +++ crypto/ecc.h|  
> 70 
>  crypto/ecc_curve_defs.h |   57 +++
>  crypto/ecdh.c   |  171 
>  crypto/testmgr.c|  136 ++-
>  crypto/testmgr.h|   73 
>  include/crypto/ecdh.h   |   24 ++
>  9 files changed, 1568 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..c50f9c8
> --- /dev/null
> +++ b/crypto/ecc.c
> @@ -0,0 +1,1038 @@
> +/*
> + * 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 
> +
> +#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)
> +

[PATCH] crypto: caam: fix caam_jr_alloc() ret code

2016-05-06 Thread Catalin Vasile 
caam_jr_alloc() used to return NULL if a JR device could not be
allocated for a session. In turn, every user of this function used
IS_ERR() function to verify if anything went wrong, which does NOT look
for NULL values. This made the kernel crash if the sanity check failed,
because the driver continued to think it had allocated a valid JR dev
instance to the session and at some point it tries to do a caam_jr_free()
on a NULL JR dev pointer.
This patch is a fix for this issue.

Signed-off-by: Catalin Vasile 
---
 drivers/crypto/caam/jr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 6fd63a6..5ef4be2 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -248,7 +248,7 @@ static void caam_jr_dequeue(unsigned long devarg)
 struct device *caam_jr_alloc(void)
 {
struct caam_drv_private_jr *jrpriv, *min_jrpriv = NULL;
-   struct device *dev = NULL;
+   struct device *dev = ERR_PTR(-ENODEV);
int min_tfm_cnt = INT_MAX;
int tfm_cnt;
 
-- 
1.8.3.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

[PATCH] crypto: caam: add backlogging support

2016-05-06 Thread Catalin Vasile 
caam_jr_enqueue() function returns -EBUSY once there are no more slots
available in the JR, but it doesn't actually save the current request.
This breaks the functionality of users that expect that even if there is
no more space for the request, it is at least queued for later
execution. In other words, all crypto transformations that request
backlogging (i.e. have CRYPTO_TFM_REQ_MAY_BACKLOG set), will hang. Such
an example is dm-crypt. The current patch solves this issue by setting a
threshold after which caam_jr_enqueue() returns -EBUSY, but since the HW
job ring isn't actually full, the job is enqueued.

Signed-off-by: Alexandru Porosanu 
Tested-by: Catalin Vasile 
---
 drivers/crypto/caam/caamalg.c  |  88 --
 drivers/crypto/caam/caamhash.c | 101 +++--
 drivers/crypto/caam/intern.h   |   7 ++
 drivers/crypto/caam/jr.c   | 196 +
 drivers/crypto/caam/jr.h   |   5 ++
 5 files changed, 343 insertions(+), 54 deletions(-)

diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index ea8189f..62bce17 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -1921,6 +1921,9 @@ static void aead_encrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
edesc = container_of(desc, struct aead_edesc, hw_desc[0]);
 
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -1928,6 +1931,7 @@ static void aead_encrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
kfree(edesc);
 
+out_bklogged:
aead_request_complete(req, err);
 }
 
@@ -1943,6 +1947,9 @@ static void aead_decrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
edesc = container_of(desc, struct aead_edesc, hw_desc[0]);
 
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -1956,6 +1963,7 @@ static void aead_decrypt_done(struct device *jrdev, u32 
*desc, u32 err,
 
kfree(edesc);
 
+out_bklogged:
aead_request_complete(req, err);
 }
 
@@ -1974,6 +1982,9 @@ static void ablkcipher_encrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
edesc = (struct ablkcipher_edesc *)((char *)desc -
 offsetof(struct ablkcipher_edesc, hw_desc));
 
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -1989,6 +2000,7 @@ static void ablkcipher_encrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
ablkcipher_unmap(jrdev, edesc, req);
kfree(edesc);
 
+out_bklogged:
ablkcipher_request_complete(req, err);
 }
 
@@ -2006,6 +2018,10 @@ static void ablkcipher_decrypt_done(struct device 
*jrdev, u32 *desc, u32 err,
 
edesc = (struct ablkcipher_edesc *)((char *)desc -
 offsetof(struct ablkcipher_edesc, hw_desc));
+
+   if (err == -EINPROGRESS)
+   goto out_bklogged;
+
if (err)
caam_jr_strstatus(jrdev, err);
 
@@ -2021,6 +2037,7 @@ static void ablkcipher_decrypt_done(struct device *jrdev, 
u32 *desc, u32 err,
ablkcipher_unmap(jrdev, edesc, req);
kfree(edesc);
 
+out_bklogged:
ablkcipher_request_complete(req, err);
 }
 
@@ -2394,7 +2411,15 @@ static int gcm_encrypt(struct aead_request *req)
 #endif
 
desc = edesc->hw_desc;
-   ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req);
+   if (req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG) {
+   ret = caam_jr_enqueue_bklog(jrdev, desc, aead_encrypt_done,
+   req);
+   if (ret == -EBUSY)
+   return ret;
+   } else {
+   ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req);
+   }
+
if (!ret) {
ret = -EINPROGRESS;
} else {
@@ -2438,7 +2463,15 @@ static int aead_encrypt(struct aead_request *req)
 #endif
 
desc = edesc->hw_desc;
-   ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req);
+   if (req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG) {
+   ret = caam_jr_enqueue_bklog(jrdev, desc, aead_encrypt_done,
+   req);
+   if (ret == -EBUSY)
+   return ret;
+   } else {
+   ret = caam_jr_enqueue(jrdev, desc, aead_encrypt_done, req);
+   }
+
if (!ret) {
ret = -EINPROGRESS;
} else {
@@ -2473,7 +2506,15 @@ static int gcm_decrypt(struct aead_request *req)
 #endif
 
desc = edesc->hw_desc;
-   ret = caam_jr_enqueue(jrdev, desc, aead_decrypt_done, req);
+   if (req->base.flags & CRYPTO_TFM_REQ_MAY_BACKLOG) {
+   ret = caam_jr_enqueue_bklog(jrdev, desc, aead_decrypt_done,
+

Re: [PATCH RESEND v5 1/6] crypto: AF_ALG -- add sign/verify API

2016-05-06 Thread Stephan Mueller 
Am Donnerstag, 5. Mai 2016, 12:50:54 schrieb Tadeusz Struk:

Hi Tadeusz, David,

> From: Stephan Mueller 
> 
> Add the flags for handling signature generation and signature
> verification.
> 
> Also, the patch adds the interface for setting a public key.
> 
> Signed-off-by: Stephan Mueller 
> Signed-off-by: Tadeusz Struk 

All four patches from me:

Acked-by: Stephan Mueller 

> ---
>  include/uapi/linux/if_alg.h |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
> index f2acd2f..02e6162 100644
> --- a/include/uapi/linux/if_alg.h
> +++ b/include/uapi/linux/if_alg.h
> @@ -34,9 +34,12 @@ struct af_alg_iv {
>  #define ALG_SET_OP   3
>  #define ALG_SET_AEAD_ASSOCLEN4
>  #define ALG_SET_AEAD_AUTHSIZE5
> +#define ALG_SET_PUBKEY   6
> 
>  /* Operations */
>  #define ALG_OP_DECRYPT   0
>  #define ALG_OP_ENCRYPT   1
> +#define ALG_OP_SIGN  2
> +#define ALG_OP_VERIFY3
> 
>  #endif   /* _LINUX_IF_ALG_H */


Ciao
Stephan
--
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

[RESEND PATCH v2 1/8] asm-generic/io.h: allow barriers in io{read,write}{16,32}be

2016-05-06 Thread Horia Geantă 
While reviewing the addition of io{read,write}64be accessors, Arnd

-finds a potential problem:
"If an architecture overrides readq/writeq to have barriers but does
not override ioread64be/iowrite64be, this will lack the barriers and
behave differently from the little-endian version. I think the only
affected architecture is ARC, since ARM and ARM64 both override the
big-endian accessors to have the correct barriers, and all others
don't use barriers at all."

-suggests a fix for the same problem in existing code (16/32-bit
accessors); the fix leads "to a double-swap on architectures that
don't override the io{read,write}{16,32}be accessors, but it will
work correctly on all architectures without them having to override
these accessors."

Suggested-by: Arnd Bergmann 
Signed-off-by: Horia Geantă 
---

Herbert, I forgot to add you and/or linux-crypto in the loop,
so I am resending this patch. Apologies for the noise.

Current patch got the Ack from Arnd:
https://lkml.org/lkml/2016/5/5/376

As the cover letter mentions, I am looking to go with patches 1-4
through cryptodev tree.

 include/asm-generic/io.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index eed3bbe88c8a..b79fb2c248a1 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -613,7 +613,7 @@ static inline void iowrite32(u32 value, volatile void 
__iomem *addr)
 #define ioread16be ioread16be
 static inline u16 ioread16be(const volatile void __iomem *addr)
 {
-   return __be16_to_cpu(__raw_readw(addr));
+   return swab16(readw(addr));
 }
 #endif
 
@@ -621,7 +621,7 @@ static inline u16 ioread16be(const volatile void __iomem 
*addr)
 #define ioread32be ioread32be
 static inline u32 ioread32be(const volatile void __iomem *addr)
 {
-   return __be32_to_cpu(__raw_readl(addr));
+   return swab32(readl(addr));
 }
 #endif
 
@@ -629,7 +629,7 @@ static inline u32 ioread32be(const volatile void __iomem 
*addr)
 #define iowrite16be iowrite16be
 static inline void iowrite16be(u16 value, void volatile __iomem *addr)
 {
-   __raw_writew(__cpu_to_be16(value), addr);
+   writew(swab16(value), addr);
 }
 #endif
 
@@ -637,7 +637,7 @@ static inline void iowrite16be(u16 value, void volatile 
__iomem *addr)
 #define iowrite32be iowrite32be
 static inline void iowrite32be(u32 value, volatile void __iomem *addr)
 {
-   __raw_writel(__cpu_to_be32(value), addr);
+   writel(swab32(value), addr);
 }
 #endif
 
-- 
2.4.4

--
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