date:20151221

Re: [PATCH v2 1/2] crypto: KEYS: convert public key to the akcipher api

2015-12-21 Thread Tadeusz Struk

Hi,
On 12/19/2015 03:49 PM, kbuild test robot wrote:
> Hi Tadeusz,
> 
> [auto build test ERROR on crypto/master]
> [also build test ERROR on v4.4-rc5 next-20151218]
> 
> url:
> https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-KEYS-convert-public-key-to-akcipher-api/20151213-103429
> base:   
> https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git master
> config: x86_64-randconfig-s4-12200710 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from include/crypto/public_key.h:17:0,
> from include/linux/verify_pefile.h:15,
> from arch/x86/kernel/kexec-bzimage64.c:22:
>include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
>>> include/keys/asymmetric-type.h:74:12: error: dereferencing pointer to 
>>> incomplete type 'const struct key'
>  return key->payload.data[asym_key_ids];
>^
> 
> vim +74 include/keys/asymmetric-type.h
> 
> 7901c1a8 David Howells 2014-09-16  68 
> size_t len_1,
> 7901c1a8 David Howells 2014-09-16  69 
> const void *val_2,
> 7901c1a8 David Howells 2014-09-16  70 
> size_t len_2);
> 146aa8b1 David Howells 2015-10-21  71  static inline
> 146aa8b1 David Howells 2015-10-21  72  const struct asymmetric_key_ids 
> *asymmetric_key_ids(const struct key *key)
> 146aa8b1 David Howells 2015-10-21  73  {
> 146aa8b1 David Howells 2015-10-21 @74 return 
> key->payload.data[asym_key_ids];
> 146aa8b1 David Howells 2015-10-21  75  }
> 7901c1a8 David Howells 2014-09-16  76  
> 7901c1a8 David Howells 2014-09-16  77  /*
> 
> :: The code at line 74 was first introduced by commit
> :: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific 
> data with the payload data
> 
> :: TO: David Howells 
> :: CC: David Howells 
> 

The previous patch was broken, re-sending again, sorry.

I think there is something missing in this configuration.
cat .config | grep KEXEC_BZIMAGE_VERIFY_SIG gives nothing.
Anyways, this patch should fix it.

---8<---

From: Tadeusz Struk 

Fix auto build test ERROR on crypto/master

Reported-by: 
Signed-off-by: Tadeusz Struk 

diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 0f8a6bb..23aa625 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -19,9 +19,10 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG
 #include 
 #include 
-
+#endif
 #include 
 #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

Re: [PATCH] crypto: AF_ALG - add support for keys/asymmetric-type

2015-12-21 Thread Stephan Mueller

Am Montag, 21. Dezember 2015, 12:51:07 schrieb Tadeusz Struk:

Hi Tadeusz,

> From: Tadeusz Struk 
> 
> Created on top of patchset from Stephan Mueller 
> https://patchwork.kernel.org/patch/7877921/
> https://patchwork.kernel.org/patch/7877971/
> https://patchwork.kernel.org/patch/7877961/
> 
> This patch adds support for asymmetric key type to AF_ALG.
> It will work as follows: A new PF_ALG socket options will be
> added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
> ALG_SET_PUBKEY_ID and ALG_SET_KEY_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 will be found, the request_key() function will
> return a requested key. Next the asymmetric key subtype will be
> used to obtain the public_key, which can be either a public key
> or a private key from the cryptographic point of view, and the
> key payload will be passed to the akcipher pf_alg subtype.
> Pf_alg code will then call crypto API functions, either the
> crypto_akcipher_set_priv_key or the crypto_akcipher_set_pub_key,
> depending on the used option. Subsequently the asymmetric key
> will be freed and return code returned back to the user.
> 
> Currently the interface will be restricted only to asymmetric
> ciphers, but it can be extended later to work with symmetric
> ciphers if required.
> 
> The assumption is that access rights for a given user will be
> verified by the key subsystem so the pf_alg interface can call
> the request_key() without checking if the user has appropriate
> rights (Please verify this assumption).
> 
> Signed-off-by: Tadeusz Struk 
> ---
>  crypto/af_alg.c |   41
> + include/uapi/linux/if_alg.h |   
> 2 ++
>  2 files changed, 39 insertions(+), 4 deletions(-)
> 
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index 767a134..d2ec357 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -22,6 +22,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  struct alg_type_list {
>   const struct af_alg_type *type;
> @@ -173,7 +175,7 @@ static int alg_bind(struct socket *sock, struct sockaddr
> *uaddr, int addr_len) }
> 
>  static int alg_setkey(struct sock *sk, char __user *ukey,
> -   unsigned int keylen,
> +   unsigned int keylen, bool key_id,
> int (*setkey)(void *private, const u8 *key,
>   unsigned int keylen))
>  {
> @@ -192,7 +194,30 @@ static int alg_setkey(struct sock *sk, char __user
> *ukey, if (copy_from_user(key, ukey, keylen))
>   goto out;
> 
> - err = setkey(ask->private, key, keylen);
> + if (key_id) {

Wouldn't it make sense to rather have a complete separate function for setting 
the key based on the ID? I.e. we have one function for setting the key based 
on a user-given buffer. A second function handles your additional code. As 
both are unrelated, I would not suggest to clutter one function with the logic 
of the other.

> + struct key *keyring;
> + struct public_key *pkey;
> + char key_name[12];
> + u32 keyid = *((u32 *)key);
> +
> + sprintf(key_name, "id:%08x", keyid);
> + keyring = request_key(_type_asymmetric, key_name, NULL);
> +
> + err = -ENOKEY;
> + if (IS_ERR(keyring))
> + goto out;
> +
> + pkey = keyring->payload.data[asym_crypto];
> + if (!pkey) {
> + key_put(keyring);
> + goto out;
> + }
> +
> + err = setkey(ask->private, pkey->key, pkey->keylen);
> + key_put(keyring);
> + } else {
> + err = setkey(ask->private, key, keylen);
> + }
> 
>  out:
>   sock_kzfree_s(sk, key, keylen);
> @@ -207,6 +232,8 @@ static int alg_setsockopt(struct socket *sock, int
> level, int optname, struct alg_sock *ask = alg_sk(sk);
>   const struct af_alg_type *type;
>   int err = -ENOPROTOOPT;
> + bool key_id = ((optname == ALG_SET_PUBKEY_ID) ||
> +(optname == ALG_SET_KEY_ID));
> 
>   lock_sock(sk);
>   type = ask->type;
> @@ -216,16 +243,22 @@ static int alg_setsockopt(struct socket *sock, int
> level, int optname,
> 
>   switch (optname) {
>   case ALG_SET_KEY:
> + case ALG_SET_KEY_ID:
>   if (sock->state == SS_CONNECTED)
>   goto unlock;
> 
> - err = alg_setkey(sk, optval, optlen, type->setkey);
> + /* ALG_SET_KEY_ID is only

Re: use-after-free in skcipher_sock_destruct

2015-12-21 Thread Stephan Mueller

Am Donnerstag, 17. Dezember 2015, 13:56:12 schrieb Dmitry Vyukov:

Hi Dmitry,

> Hello,
> 
> The following program triggers use-after-free in skcipher_sock_destruct:

This issue is not evident after applying  Herbert's patch converting the 
algif_skcipher from using ablkcipher to skcipher API.
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> struct sockaddr_alg {
> unsigned short   salg_family;
> charsalg_type[14];
> unsigned   salg_feat;
> unsigned   salg_mask;
> charsalg_name[64];
> };
> 
> int fd;
> 
> void *thr0(void *arg)
> {
> struct sockaddr_alg sa = {};
> sa.salg_family = 0x26;
> memcpy(sa.salg_type,
> "\x73\x6b\x63\x69\x70\x68\x65\x72\x00\x00\x00\x00\x00\x00", 14);
> sa.salg_feat = 0xf;
> sa.salg_mask = 0x100;
> memcpy(sa.salg_name,
> "\x65\x63\x62\x28\x73\x65\x72\x70\x65\x6e\x74\x29\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00", 64);
> bind(fd, (struct sockaddr*), sizeof(sa));
> return 0;
> }
> 
> void *thr1(void *arg)
> {
> accept4(fd, 0, 0, 0x800ul);
> return 0;
> }
> 
> int main()
> {
> fd = socket(PF_ALG, SOCK_SEQPACKET, 0);
> pthread_t th[4];
> pthread_create([0], 0, thr0, 0);
> pthread_create([1], 0, thr1, 0);
> pthread_create([2], 0, thr0, 0);
> pthread_create([3], 0, thr1, 0);
> pthread_join(th[0], 0);
> pthread_join(th[1], 0);
> pthread_join(th[2], 0);
> pthread_join(th[3], 0);
> return 0;
> }
> 
> 
> ==
> BUG: KASAN: use-after-free in skcipher_sock_destruct+0x39c/0x3e0 at
> addr 8800387a2d38
> Read of size 4 by task executor/27423
> 
> = BUG kmalloc-96 (Not tainted): kasan: bad access detected
> 
> -
> 
> Disabling lock debugging due to kernel taint
> INFO: Allocated in __crypto_alloc_tfm+0xd9/0x470 age=36 cpu=0 pid=27396
> [<  none  >] __kmalloc+0x2d9/0x480 mm/slub.c:3532
> [< inline >] kmalloc include/linux/slab.h:463
> [< inline >] kzalloc include/linux/slab.h:602
> [<  none  >] __crypto_alloc_tfm+0xd9/0x470 crypto/api.c:374
> [<  none  >] crypto_alloc_ablkcipher+0x7b/0x1f0
> crypto/ablkcipher.c:699 [<  none  >] skcipher_bind+0x25/0x30
> crypto/algif_skcipher.c:754 [<  none  >] alg_bind+0x1a9/0x410
> crypto/af_alg.c:155
> [<  none  >] SYSC_bind+0x20a/0x2c0 net/socket.c:1383
> [<  none  >] SyS_bind+0x24/0x30 net/socket.c:1369
> [<  none  >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> 
> INFO: Freed in kzfree+0x28/0x30 age=26 cpu=2 pid=27421
> [<  none  >] kfree+0x26f/0x3e0 mm/slub.c:3632
> [<  none  >] kzfree+0x28/0x30 mm/slab_common.c:1270
> [<  none  >] crypto_destroy_tfm+0xdd/0x1e0 crypto/api.c:596
> [< inline >] crypto_free_tfm include/linux/crypto.h:623
> [< inline >] crypto_free_ablkcipher include/linux/crypto.h:769
> [<  none  >] skcipher_release+0x18/0x20 crypto/algif_skcipher.c:759
> [< inline >] alg_do_release crypto/af_alg.c:116
> [<  none  >] alg_bind+0x26a/0x410 crypto/af_alg.c:170
> [<  none  >] SYSC_bind+0x20a/0x2c0 net/socket.c:1383
> [<  none  >] SyS_bind+0x24/0x30 net/socket.c:1369
> [<  none  >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> 
> INFO: Slab 0xeae1e880 objects=19 used=8 fp=0x8800387a3380
> flags=0x1fffc004080
> INFO: Object 0x8800387a2d00 @offset=3328 fp=0x8800387a3520
> CPU: 0 PID: 27423 Comm: executor Tainted: GB   4.4.0-rc3+ #151
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  880035c67700 82e0f4b8 41b58ab3
> 87a9a265 82e0f406 880037f15a00 87abb3aa
> 88003e804780 0008 8800387a2d00 880035c67700
> 
> Call Trace:
>  [] __asan_report_load4_noabort+0x54/0x70
> mm/kasan/report.c:294
>  [< inline >] crypto_ablkcipher_ivsize include/linux/crypto.h:807
>  [] skcipher_sock_destruct+0x39c/0x3e0
> crypto/algif_skcipher.c:787
>  [] sk_destruct+0xa5/0x5f0 net/core/sock.c:1446
>  [] __sk_free+0x8c/0x260 net/core/sock.c:1474
>  [] sk_free+0x30/0x40 net/core/sock.c:1485
>  [< inline >] sock_put include/net/sock.h:1625
>  [] af_alg_release+0x60/0x90 crypto/af_alg.c:123
>  [] sock_release+0x96/0x260 net/socket.c:571
>  [] sock_close+0x16/0x20 net/socket.c:1022
>  [] __fput+0x244/0x860

[PATCH] crypto: AF_ALG - add support for keys/asymmetric-type

2015-12-21 Thread Tadeusz Struk

From: Tadeusz Struk 

Created on top of patchset from Stephan Mueller 
https://patchwork.kernel.org/patch/7877921/
https://patchwork.kernel.org/patch/7877971/
https://patchwork.kernel.org/patch/7877961/

This patch adds support for asymmetric key type to AF_ALG.
It will work as follows: A new PF_ALG socket options will be
added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
ALG_SET_PUBKEY_ID and ALG_SET_KEY_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 will be found, the request_key() function will
return a requested key. Next the asymmetric key subtype will be
used to obtain the public_key, which can be either a public key
or a private key from the cryptographic point of view, and the
key payload will be passed to the akcipher pf_alg subtype.
Pf_alg code will then call crypto API functions, either the
crypto_akcipher_set_priv_key or the crypto_akcipher_set_pub_key,
depending on the used option. Subsequently the asymmetric key
will be freed and return code returned back to the user.

Currently the interface will be restricted only to asymmetric
ciphers, but it can be extended later to work with symmetric
ciphers if required.

The assumption is that access rights for a given user will be
verified by the key subsystem so the pf_alg interface can call
the request_key() without checking if the user has appropriate
rights (Please verify this assumption).

Signed-off-by: Tadeusz Struk 
---
 crypto/af_alg.c |   41 +
 include/uapi/linux/if_alg.h |2 ++
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 767a134..d2ec357 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct alg_type_list {
const struct af_alg_type *type;
@@ -173,7 +175,7 @@ static int alg_bind(struct socket *sock, struct sockaddr 
*uaddr, int addr_len)
 }
 
 static int alg_setkey(struct sock *sk, char __user *ukey,
- unsigned int keylen,
+ unsigned int keylen, bool key_id,
  int (*setkey)(void *private, const u8 *key,
unsigned int keylen))
 {
@@ -192,7 +194,30 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
if (copy_from_user(key, ukey, keylen))
goto out;
 
-   err = setkey(ask->private, key, keylen);
+   if (key_id) {
+   struct key *keyring;
+   struct public_key *pkey;
+   char key_name[12];
+   u32 keyid = *((u32 *)key);
+
+   sprintf(key_name, "id:%08x", keyid);
+   keyring = request_key(_type_asymmetric, key_name, NULL);
+
+   err = -ENOKEY;
+   if (IS_ERR(keyring))
+   goto out;
+
+   pkey = keyring->payload.data[asym_crypto];
+   if (!pkey) {
+   key_put(keyring);
+   goto out;
+   }
+
+   err = setkey(ask->private, pkey->key, pkey->keylen);
+   key_put(keyring);
+   } else {
+   err = setkey(ask->private, key, keylen);
+   }
 
 out:
sock_kzfree_s(sk, key, keylen);
@@ -207,6 +232,8 @@ static int alg_setsockopt(struct socket *sock, int level, 
int optname,
struct alg_sock *ask = alg_sk(sk);
const struct af_alg_type *type;
int err = -ENOPROTOOPT;
+   bool key_id = ((optname == ALG_SET_PUBKEY_ID) ||
+  (optname == ALG_SET_KEY_ID));
 
lock_sock(sk);
type = ask->type;
@@ -216,16 +243,22 @@ static int alg_setsockopt(struct socket *sock, int level, 
int optname,
 
switch (optname) {
case ALG_SET_KEY:
+   case ALG_SET_KEY_ID:
if (sock->state == SS_CONNECTED)
goto unlock;
 
-   err = alg_setkey(sk, optval, optlen, type->setkey);
+   /* ALG_SET_KEY_ID is only for akcipher */
+   if (!strcmp(type->name, "akcipher") && key_id)
+   goto unlock;
+
+   err = alg_setkey(sk, optval, optlen, key_id, type->setkey);
break;
case ALG_SET_PUBKEY:
+   case ALG_SET_PUBKEY_ID:
if (sock->state == SS_CONNECTED)
goto unlock;
 
-   err = alg_setkey(sk, optval, optlen, type->setpubkey);
+   err = alg_setkey(sk, optval, optlen, key_id, type->setpubkey);

Re: [PATCH] crypto: AF_ALG - add support for keys/asymmetric-type

2015-12-21 Thread Tadeusz Struk

Hi Stephan,
On 12/21/2015 01:27 PM, Stephan Mueller wrote:
>> @@ -192,7 +194,30 @@ static int alg_setkey(struct sock *sk, char __user
>> > *ukey, if (copy_from_user(key, ukey, keylen))
>> >goto out;
>> > 
>> > -  err = setkey(ask->private, key, keylen);
>> > +  if (key_id) {
> Wouldn't it make sense to rather have a complete separate function for 
> setting 
> the key based on the ID? I.e. we have one function for setting the key based 
> on a user-given buffer. A second function handles your additional code. As 
> both are unrelated, I would not suggest to clutter one function with the 
> logic 
> of the other.

Either way is fine with me. I just didn't want to have too many indentation
levels in the alg_setsockopt function.

> 
>> -err = alg_setkey(sk, optval, optlen, type->setkey);
>> > +  /* ALG_SET_KEY_ID is only for akcipher */
>> > +  if (!strcmp(type->name, "akcipher") && key_id)
> Why do you want to limit it to akcipher? I would think it can apply to all 
> types of keys. You mention that you want to restrict it to akcipher, but 
> where 
> do you see the limitation for HMAC / skcipher?
> 
I pass key_type_asymmetric to request_key(), which only works with asymmetric.
To enable symmetric we would need to have a new key type, which would handle
both. 
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: GPF in gf128mul_64k_bbe

2015-12-21 Thread Stephan Mueller

Am Montag, 21. Dezember 2015, 23:53:14 schrieb Stephan Mueller:

Hi,

> Am Donnerstag, 17. Dezember 2015, 14:00:23 schrieb Dmitry Vyukov:
> 
> Hi Dmitry,
> 
> > Hello,
> 
> > The following program causes GPF in gf128mul_64k_bbe:
> This looks very much like the issue you reported for lrw_crypt.

Oops, I was looking at the wrong email. Please disregard this one reply.

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

Re: GPF in gf128mul_64k_bbe

2015-12-21 Thread Stephan Mueller

Am Donnerstag, 17. Dezember 2015, 14:00:23 schrieb Dmitry Vyukov:

Hi Dmitry,

> Hello,
> 
> The following program causes GPF in gf128mul_64k_bbe:

This looks very much like the issue you reported for lrw_crypt.
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> 
> int main()
> {
> long r0 = syscall(SYS_socket, 0x26ul, 0x5ul, 0x0ul, 0, 0, 0);
> long r1 = syscall(SYS_mmap, 0x2000ul, 0x1ul, 0x3ul,
> 0x32ul, 0xul, 0x0ul);
> *(uint16_t*)0x20001000 = 0x26;
> memcpy((void*)0x20001002,
> "\x73\x6b\x63\x69\x70\x68\x65\x72\x00\x00\x00\x00\x00\x00", 14);
> *(uint32_t*)0x20001010 = 0xf;
> *(uint32_t*)0x20001014 = 0x100;
> memcpy((void*)0x20001018,
> "\x6c\x72\x77\x28\x63\x61\x6d\x65\x6c\x6c\x69\x61\x29\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00", 64);
> long r7 = syscall(SYS_bind, r0, 0x20001000ul, 0x58ul, 0, 0, 0);
> long r8 = syscall(SYS_accept4, r0, 0x0ul, 0x200023fdul, 0x800ul, 0,
> 0); *(uint32_t*)0x20002000 = 0x12;
> *(uint32_t*)0x20002004 = 0x8;
> *(uint64_t*)0x20002008 = 0x0;
> *(uint16_t*)0x20002010 = 0x4d;
> long r13 = syscall(SYS_write, r8, 0x20002000ul, 0x12ul, 0, 0, 0);
> memcpy((void*)0x2a56,
> "\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 128);
> long r15 = syscall(SYS_recvfrom, r8, 0x2000ul, 0xb6ul,
> 0x0ul, 0x2a56ul, 0x80ul);
> return 0;
> }
> 
> 
> general protection fault:  [#2] SMP KASAN
> Modules linked in:
> CPU: 0 PID: 6955 Comm: executor Not tainted 4.4.0-rc3+ #151
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88005fc88000 ti: 880062478000 task.ti: 880062478000 RIP:
> 0010:[]
>   [] gf128mul_64k_bbe+0x89/0x3f0 crypto/gf128mul.c:379
> RSP: 0018:88006247f720  EFLAGS: 00010246
> RAX: dc00 RBX: 0001 RCX: 
> RDX: ed000c48fed1 RSI:  RDI: ed000c48fedd
> RBP: 88006247f7e0 R08: 88003dfd1158 R09: 1000
> R10: 0010 R11: 1100075eeb92 R12: 88006247fa00
> R13:  R14:  R15: 11000c48feea
> FS:  7f21e795f700() GS:88003ec0() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 2a56 CR3: 60c4b000 CR4: 06f0
> Stack:
>  88006247f8c0 88006247f8b8 11000c48feea 88006247fa00
>  88006247f8a0  41b58ab3 87ab3a79
>  82bf9580 82bafa9b  88006247f7a0
> Call Trace:
>  [] lrw_crypt+0x29d/0xd20 crypto/lrw.c:248
>  [] lrw_decrypt+0xeb/0x140
> arch/x86/crypto/serpent_avx2_glue.c:270
>  [] async_decrypt+0x1c1/0x2c0 crypto/blkcipher.c:443
>  [< inline >] crypto_ablkcipher_decrypt include/linux/crypto.h:921
>  [< inline >] skcipher_recvmsg_sync crypto/algif_skcipher.c:676
>  [] skcipher_recvmsg+0x1029/0x1f10
> crypto/algif_skcipher.c:706 [< inline >] sock_recvmsg_nosec
> net/socket.c:712
>  [] sock_recvmsg+0xaa/0xe0 net/socket.c:720
>  [] SYSC_recvfrom+0x1e4/0x370 net/socket.c:1707
>  [] SyS_recvfrom+0x40/0x50 net/socket.c:1681
>  [] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> Code: 04 00 00 f4 f4 c7 40 08 f3 f3 f3 f3 e8 d1 e9 a0 fe 4d 85 f6 0f
> 84 f6 01 00 00 4c 89 f1 48 b8 00 00 00 00 00 fc ff df 48 c1 e9 03 <80>
> 3c 01 00 0f 85 48 03 00 00 48 8b 5c 24 18 4d 8b 26 48 83 c3
> RIP  [] gf128mul_64k_bbe+0x89/0x3f0 crypto/gf128mul.c:379
>  RSP 
> ---[ end trace 722d56533c7c99a7 ]---
> 
> 
> On upstream commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8 (Nov 29).
> --
> 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


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

Re: bad page state due to PF_ALG socket

2015-12-21 Thread Cong Wang

On Thu, Dec 17, 2015 at 4:58 AM, Dmitry Vyukov  wrote:
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault:  [#1] SMP KASAN
> Modules linked in:
> CPU: 3 PID: 7168 Comm: a.out Tainted: GB   4.4.0-rc3+ #151
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88003712ad00 ti: 8800331d8000 task.ti: 8800331d8000
> RIP: 0010:[]  []
> skcipher_recvmsg+0x82/0x1f10
> RSP: 0018:8800331dfb80  EFLAGS: 00010203
> RAX: dc00 RBX: 88006b98f300 RCX: 00010040
> RDX: 0002 RSI: 8800331dfdc0 RDI: 0016
> RBP: 8800331dfc80 R08: 8800331dfdd0 R09: 000a
> R10: 00010040 R11: 0246 R12: 0006
> R13: 8800331dfdc0 R14: 8800331dfdc0 R15: 00010040
> FS:  02630880(0063) GS:88006cf0() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 00c8200d73b0 CR3: 64c58000 CR4: 06e0
> Stack:
>  88006aba6024 88006ab24520 88006ab24510 88006aba67e0
>  88006aba602c ed000d574cfc  88006ab24518
>  88006aba602d 1000 88006ab24500 88006aba6a48
> Call Trace:
>  [< inline >] sock_recvmsg_nosec net/socket.c:712
>  [] sock_recvmsg+0xaa/0xe0 net/socket.c:720
>  [] SYSC_recvfrom+0x1e4/0x370 net/socket.c:1707
>  [] SyS_recvfrom+0x40/0x50 net/socket.c:1681
>  [] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185

I think it is probably fixed by:

commit 130ed5d105dde141e7fe60d5440aa53e0a84f13b
Author: tadeusz.st...@intel.com 
Date:   Tue Dec 15 10:46:17 2015 -0800

net: fix uninitialized variable issue
--
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: GPF in lrw_crypt

2015-12-21 Thread Stephan Mueller

Am Donnerstag, 17. Dezember 2015, 13:59:11 schrieb Dmitry Vyukov:

Hi Dmitry,

> Hello,
> 
> The following program causes GPF in lrw_crypt:

Here we are: this problem looks very much like the error reprt about a GFP in 
gf128mul_64_bbe.
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> 
> int main()
> {
> long r0 = syscall(SYS_socket, 0x26ul, 0x5ul, 0x0ul, 0, 0, 0);
> long r1 = syscall(SYS_mmap, 0x2000ul, 0x1ul, 0x2ul,
> 0x32ul, 0xul, 0x0ul);
> *(uint16_t*)0x20001000 = 0x26;
> memcpy((void*)0x20001002,
> "\x73\x6b\x63\x69\x70\x68\x65\x72\x00\x00\x00\x00\x00\x00", 14);
> *(uint32_t*)0x20001010 = 0xf;
> *(uint32_t*)0x20001014 = 0x100;
> memcpy((void*)0x20001018,
> "\x6c\x72\x77\x28\x74\x77\x6f\x66\x69\x73\x68\x29\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00", 64);
> long r7 = syscall(SYS_bind, r0, 0x20001000ul, 0x58ul, 0, 0, 0);
> long r8 = syscall(SYS_accept4, r0, 0x0ul, 0x200023fdul, 0x800ul, 0,
> 0); memcpy((void*)0x20002fd8,
> "\x09\xf1\x98\x36\x3f\x7d\x29\x96\x55\xe6\xa2\x42\x45\x67\x8f\x7c\x27\x44\x5
> 1\x6f\xbe\x4d\x52\x6f\x40\xaf\xe0\xd6\x04\x8d\x86\x36\x08\xc8\x55\xb8\xfe\x6
> e\x89\xef\x15\x2d\x07\x9a\x74\xab\xc7\x47\x26\xb5\x00\x93\x3b\x59\xe2\x1f\x6
> a\x29\x76\x7f\x9d\x3a\x86\x38\xda\x3e\xfb\xbe\x63\x2e\x38\x2f\x5c\x1c\x4d\xb
> 8\x53\xf9\x97\xdb\x4a\xcc\xad\x55\xb3\xb5\xa0\xb4\xad\xfb\x39\xe5\x44\x12\x0
> b\x5f\x03\xbf\xc7\x28\x36\x1a\x7b\x4a\xff\x3e\x71\x17\x44\xf3\x09\xfb\x44\x4
> 1\x55\x1b\x6e\x6c\xcd\x03\x39\x66\xe2\x87\x65\xdd\x66\x7c\x00\x9f\x46\x54\x6
> 6\xf1\xa8\x4b\xd9\x10\xdc\x45\xd0\x57\x5c\x5e\x97\x42\x3a\xc9\x26\x5a\x55\x5
> 7\x65\x5f\x38\x54\xdd\x1e\xd8\x89\xe0\x34\xf0\x9e\x65\xf8\x89\x8e\xe4\x02\xd
> c\xa2\xa8\x45\x9c\xe9\xca\xef\xad\xdc\x74\xb5", 182);
> long r10 = syscall(SYS_write, r8, 0x20002fd8ul, 0xb6ul, 0, 0, 0);
> *(uint64_t*)0x2fb8 = 0x20004fff;
> *(uint64_t*)0x2fc0 = 0x94;
> *(uint64_t*)0x2fc8 = 0x2000;
> *(uint64_t*)0x2fd0 = 0x5d;
> *(uint64_t*)0x2fd8 = 0x2f1b;
> *(uint64_t*)0x2fe0 = 0xe5;
> *(uint64_t*)0x2fe8 = 0x20004b08;
> *(uint64_t*)0x2ff0 = 0xe9;
> *(uint64_t*)0x2ff8 = 0x20002000;
> *(uint64_t*)0x20001000 = 0x1000;
> long r21 = syscall(SYS_readv, r8, 0x2fb8ul, 0x5ul, 0, 0, 0);
> return 0;
> }
> 
> 
> 
>  kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory
> accessgeneral protection fault:  [#1] SMP KASAN
> Modules linked in:
> CPU: 2 PID: 6912 Comm: a.out Not tainted 4.4.0-rc3+ #151
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88005ee61680 ti: 88005fef task.ti: 88005fef RIP:
> 0010:[]  [] gf128mul_64k_bbe+0x89/0x3f0
> RSP: 0018:88005fef7590  EFLAGS: 00010246
> RAX: dc00 RBX: 0001 RCX: 
> RDX: ed000bfdee9f RSI: 88005ee61e40 RDI: ed000bfdeeab
> RBP: 88005fef7650 R08: 0001 R09: 
> R10:  R11:  R12: 88005fef7870
> R13:  R14:  R15: 11000bfdeeb8
> FS:  026a3880(0063) GS:88006ce0() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 2fb8 CR3: 5ffa CR4: 06e0
> Stack:
>  88005fef7730 88000fff 11000bfdeeb8 88005fef7870
>  88005fef7710  41b58ab3 87ab3a79
>  82bf9580 82bafa9b 88005ee61680 0001
> Call Trace:
>  [] lrw_crypt+0x29d/0xd20 crypto/lrw.c:248
>  [] lrw_decrypt+0xf2/0x150
> arch/x86/crypto/serpent_avx2_glue.c:270
>  [] async_decrypt+0x1c1/0x2c0 crypto/blkcipher.c:443
>  [< inline >] crypto_ablkcipher_decrypt include/linux/crypto.h:921
>  [< inline >] skcipher_recvmsg_sync crypto/algif_skcipher.c:676
>  [] skcipher_recvmsg+0x1029/0x1f10
> crypto/algif_skcipher.c:706 [< inline >] sock_recvmsg_nosec
> net/socket.c:712
>  [] sock_recvmsg+0xaa/0xe0 net/socket.c:720
>  [] sock_read_iter+0x273/0x3d0 net/socket.c:797
>  [] do_iter_readv_writev+0x14e/0x2c0 fs/read_write.c:664
>  [] do_readv_writev+0x2e2/0x880 fs/read_write.c:808
>  [] vfs_readv+0x95/0xd0 fs/read_write.c:834
>  [< inline >] SYSC_readv fs/read_write.c:860
>  [] SyS_readv+0x111/0x2f0 fs/read_write.c:852
>  [] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> Code: 04 00 00 f4 f4 c7 40 08 f3 f3 f3 f3 e8 d1 e9 a0 fe 4d 85 f6 0f
> 84 f6 01 00 00 4c 89 f1 48 b8 00 00 00 00 00 fc

Re: GPF in gf128mul_64k_bbe

2015-12-21 Thread Stephan Mueller

Am Donnerstag, 17. Dezember 2015, 14:00:23 schrieb Dmitry Vyukov:

Hi Herbert,

After digging a bit here, I find the following:

- When using the test app on my system, I get a GPF in twofish, which means 
that the problem is not tied to a particular cipher implementation.

- When analyzing gf128mul_64k_bbe, I see that the NULL pointer deference seems 
to be triggered *after* the last operation in that function. Can it be that 
there is some memory corruption in that function where the return pointer is 
somehow overwritten?


> Hello,
> 
> The following program causes GPF in gf128mul_64k_bbe:
> 
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include 
> #include 
> #include 
> 
> int main()
> {
> long r0 = syscall(SYS_socket, 0x26ul, 0x5ul, 0x0ul, 0, 0, 0);
> long r1 = syscall(SYS_mmap, 0x2000ul, 0x1ul, 0x3ul,
> 0x32ul, 0xul, 0x0ul);
> *(uint16_t*)0x20001000 = 0x26;
> memcpy((void*)0x20001002,
> "\x73\x6b\x63\x69\x70\x68\x65\x72\x00\x00\x00\x00\x00\x00", 14);
> *(uint32_t*)0x20001010 = 0xf;
> *(uint32_t*)0x20001014 = 0x100;
> memcpy((void*)0x20001018,
> "\x6c\x72\x77\x28\x63\x61\x6d\x65\x6c\x6c\x69\x61\x29\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00", 64);
> long r7 = syscall(SYS_bind, r0, 0x20001000ul, 0x58ul, 0, 0, 0);
> long r8 = syscall(SYS_accept4, r0, 0x0ul, 0x200023fdul, 0x800ul, 0,
> 0); *(uint32_t*)0x20002000 = 0x12;
> *(uint32_t*)0x20002004 = 0x8;
> *(uint64_t*)0x20002008 = 0x0;
> *(uint16_t*)0x20002010 = 0x4d;
> long r13 = syscall(SYS_write, r8, 0x20002000ul, 0x12ul, 0, 0, 0);
> memcpy((void*)0x2a56,
> "\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
> 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 128);
> long r15 = syscall(SYS_recvfrom, r8, 0x2000ul, 0xb6ul,
> 0x0ul, 0x2a56ul, 0x80ul);
> return 0;
> }
> 
> 
> general protection fault:  [#2] SMP KASAN
> Modules linked in:
> CPU: 0 PID: 6955 Comm: executor Not tainted 4.4.0-rc3+ #151
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88005fc88000 ti: 880062478000 task.ti: 880062478000 RIP:
> 0010:[]
>   [] gf128mul_64k_bbe+0x89/0x3f0 crypto/gf128mul.c:379
> RSP: 0018:88006247f720  EFLAGS: 00010246
> RAX: dc00 RBX: 0001 RCX: 
> RDX: ed000c48fed1 RSI:  RDI: ed000c48fedd
> RBP: 88006247f7e0 R08: 88003dfd1158 R09: 1000
> R10: 0010 R11: 1100075eeb92 R12: 88006247fa00
> R13:  R14:  R15: 11000c48feea
> FS:  7f21e795f700() GS:88003ec0() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: 2a56 CR3: 60c4b000 CR4: 06f0
> Stack:
>  88006247f8c0 88006247f8b8 11000c48feea 88006247fa00
>  88006247f8a0  41b58ab3 87ab3a79
>  82bf9580 82bafa9b  88006247f7a0
> Call Trace:
>  [] lrw_crypt+0x29d/0xd20 crypto/lrw.c:248
>  [] lrw_decrypt+0xeb/0x140
> arch/x86/crypto/serpent_avx2_glue.c:270
>  [] async_decrypt+0x1c1/0x2c0 crypto/blkcipher.c:443
>  [< inline >] crypto_ablkcipher_decrypt include/linux/crypto.h:921
>  [< inline >] skcipher_recvmsg_sync crypto/algif_skcipher.c:676
>  [] skcipher_recvmsg+0x1029/0x1f10
> crypto/algif_skcipher.c:706 [< inline >] sock_recvmsg_nosec
> net/socket.c:712
>  [] sock_recvmsg+0xaa/0xe0 net/socket.c:720
>  [] SYSC_recvfrom+0x1e4/0x370 net/socket.c:1707
>  [] SyS_recvfrom+0x40/0x50 net/socket.c:1681
>  [] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> Code: 04 00 00 f4 f4 c7 40 08 f3 f3 f3 f3 e8 d1 e9 a0 fe 4d 85 f6 0f
> 84 f6 01 00 00 4c 89 f1 48 b8 00 00 00 00 00 fc ff df 48 c1 e9 03 <80>
> 3c 01 00 0f 85 48 03 00 00 48 8b 5c 24 18 4d 8b 26 48 83 c3
> RIP  [] gf128mul_64k_bbe+0x89/0x3f0 crypto/gf128mul.c:379
>  RSP 
> ---[ end trace 722d56533c7c99a7 ]---
> 
> 
> On upstream commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8 (Nov 29).
> --
> 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


-- 
Ciao
Stephan

[PATCH] crypto: 842 - remove WARN inside printk

2015-12-21 Thread Dan Streetman

Remove the WARN() from the beN_to_cpu macro, which is used as a param to a
pr_debug() call.  With a certain kernel config, this printk-in-printk
results in the no_printk() macro trying to recursively call the
no_printk() macro, and since macros can't recursively call themselves
a build error results.

Reported-by: Randy Dunlap 
Signed-off-by: Dan Streetman 
---
 lib/842/842_decompress.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/lib/842/842_decompress.c b/lib/842/842_decompress.c
index 8881dad..a7f278d 100644
--- a/lib/842/842_decompress.c
+++ b/lib/842/842_decompress.c
@@ -69,7 +69,7 @@ struct sw842_param {
((s) == 2 ? be16_to_cpu(get_unaligned((__be16 *)d)) :   \
 (s) == 4 ? be32_to_cpu(get_unaligned((__be32 *)d)) :   \
 (s) == 8 ? be64_to_cpu(get_unaligned((__be64 *)d)) :   \
-WARN(1, "pr_debug param err invalid size %x\n", s))
+0)
 
 static int next_bits(struct sw842_param *p, u64 *d, u8 n);
 
@@ -202,10 +202,14 @@ static int __do_index(struct sw842_param *p, u8 size, u8 
bits, u64 fsize)
return -EINVAL;
}
 
-   pr_debug("index%x to %lx off %lx adjoff %lx tot %lx data %lx\n",
-size, (unsigned long)index, (unsigned long)(index * size),
-(unsigned long)offset, (unsigned long)total,
-(unsigned long)beN_to_cpu(>ostart[offset], size));
+   if (size != 2 && size != 4 && size != 8)
+   WARN(1, "__do_index invalid size %x\n", size);
+   else
+   pr_debug("index%x to %lx off %lx adjoff %lx tot %lx data %lx\n",
+size, (unsigned long)index,
+(unsigned long)(index * size), (unsigned long)offset,
+(unsigned long)total,
+(unsigned long)beN_to_cpu(>ostart[offset], size));
 
memcpy(p->out, >ostart[offset], size);
p->out += size;
-- 
2.5.0

--
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] Renaming dh895xcc mmp fw

2015-12-21 Thread Atta, Ahsan

Renaming dh895xcc mmp fw

Signed-off-by: Ahsan Atta 
---
 .../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h 
b/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h
index 72eacfd..f3c5de9 100644
--- a/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h
+++ b/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h
@@ -82,7 +82,7 @@
 #define ADF_DH895XCC_VINTMSK_OFFSET(i) (0x3A000 + 0x200 + ((i) * 0x04))
 /* FW names */
 #define ADF_DH895XCC_FW "qat_895xcc.bin"
-#define ADF_DH895XCC_MMP "qat_mmp.bin"
+#define ADF_DH895XCC_MMP "qat_dh895xcc_mmp.bin"
 
 void adf_init_hw_data_dh895xcc(struct adf_hw_device_data *hw_data);  void 
adf_clean_hw_data_dh895xcc(struct adf_hw_device_data *hw_data);
--
1.7.4.1

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

--
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] Renaming dh895xcc mmp fw

2015-12-21 Thread Atta, Ahsan

Renaming dh895xcc mmp fw

Signed-off-by: Ahsan Atta 
---
 .../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h 
b/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h
index 72eacfd..f3c5de9 100644
--- a/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h
+++ b/drivers/crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h
@@ -82,7 +82,7 @@
 #define ADF_DH895XCC_VINTMSK_OFFSET(i) (0x3A000 + 0x200 + ((i) * 0x04))
 /* FW names */
 #define ADF_DH895XCC_FW "qat_895xcc.bin"
-#define ADF_DH895XCC_MMP "qat_mmp.bin"
+#define ADF_DH895XCC_MMP "qat_dh895xcc_mmp.bin"
 
 void adf_init_hw_data_dh895xcc(struct adf_hw_device_data *hw_data);  void 
adf_clean_hw_data_dh895xcc(struct adf_hw_device_data *hw_data);
--
1.7.4.1

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

--
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] Renaming dh895xcc mmp fw

2015-12-21 Thread Greg KH

On Mon, Dec 21, 2015 at 02:36:57PM +, Atta, Ahsan wrote:
> Renaming dh895xcc mmp fw
> 
> Signed-off-by: Ahsan Atta 
> ---
>  .../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.


--
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 1/2] crypto: KEYS: convert public key to the akcipher api

Re: [PATCH] crypto: AF_ALG - add support for keys/asymmetric-type

Re: use-after-free in skcipher_sock_destruct

[PATCH] crypto: AF_ALG - add support for keys/asymmetric-type

Re: [PATCH] crypto: AF_ALG - add support for keys/asymmetric-type

Re: GPF in gf128mul_64k_bbe

Re: GPF in gf128mul_64k_bbe

Re: bad page state due to PF_ALG socket

Re: GPF in lrw_crypt

Re: GPF in gf128mul_64k_bbe

[PATCH] crypto: 842 - remove WARN inside printk

[PATCH] Renaming dh895xcc mmp fw

[PATCH] Renaming dh895xcc mmp fw

Re: [PATCH] Renaming dh895xcc mmp fw

14 matches

Site Navigation

Mail list logo

Footer information