[PATCH 1/3] crypto: cavium: Downgrade the annoying misc interrupt print from dev_err to dev_dbg

[George Cherian]

Mailbox interrupt is common and it is not an error interrupt.
So downgrade the print from dev_err to  dev_dbg.

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c 
b/drivers/crypto/cavium/cpt/cptvf_main.c
index 6ffc740..5c796ed 100644
--- a/drivers/crypto/cavium/cpt/cptvf_main.c
+++ b/drivers/crypto/cavium/cpt/cptvf_main.c
@@ -525,7 +525,7 @@ static irqreturn_t cptvf_misc_intr_handler(int irq, void 
*cptvf_irq)
intr = cptvf_read_vf_misc_intr_status(cptvf);
/*Check for MISC interrupt types*/
if (likely(intr & CPT_VF_INTR_MBOX_MASK)) {
-   dev_err(>dev, "Mailbox interrupt 0x%llx on CPT VF %d\n",
+   dev_dbg(>dev, "Mailbox interrupt 0x%llx on CPT VF %d\n",
intr, cptvf->vfid);
cptvf_handle_mbox_intr(cptvf);
cptvf_clear_mbox_intr(cptvf);
-- 
2.1.4

[PATCH 3/3] crypto: cavium: Add more algorithms

[George Cherian]

Add more algorithm support for the driver.
Add support for ecb(aes), cfb(aes) and ecb(des3_ede).

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_algs.c | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c 
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index c365fc6..b980d13 100644
--- a/drivers/crypto/cavium/cpt/cptvf_algs.c
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.c
@@ -385,6 +385,48 @@ struct crypto_alg algs[] = { {
.cra_module = THIS_MODULE,
 }, {
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_enc_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "ecb(aes)",
+   .cra_driver_name = "cavium-ecb-aes",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .ivsize = AES_BLOCK_SIZE,
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = AES_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_enc_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "cfb(aes)",
+   .cra_driver_name = "cavium-cfb-aes",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .ivsize = AES_BLOCK_SIZE,
+   .min_keysize = AES_MIN_KEY_SIZE,
+   .max_keysize = AES_MAX_KEY_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
.cra_blocksize = DES3_EDE_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct cvm_des3_ctx),
.cra_alignmask = 7,
@@ -404,6 +446,27 @@ struct crypto_alg algs[] = { {
},
.cra_init = cvm_enc_dec_init,
.cra_module = THIS_MODULE,
+}, {
+   .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
+   .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+   .cra_ctxsize = sizeof(struct cvm_des3_ctx),
+   .cra_alignmask = 7,
+   .cra_priority = 4001,
+   .cra_name = "ecb(des3_ede)",
+   .cra_driver_name = "cavium-ecb-des3_ede",
+   .cra_type = _ablkcipher_type,
+   .cra_u = {
+   .ablkcipher = {
+   .min_keysize = DES3_EDE_KEY_SIZE,
+   .max_keysize = DES3_EDE_KEY_SIZE,
+   .ivsize = DES_BLOCK_SIZE,
+   .setkey = cvm_enc_dec_setkey,
+   .encrypt = cvm_encrypt,
+   .decrypt = cvm_decrypt,
+   },
+   },
+   .cra_init = cvm_enc_dec_init,
+   .cra_module = THIS_MODULE,
 } };
 
 static inline int cav_register_algs(void)
-- 
2.1.4

[PATCH 2/3] crypto: cavium: Remove the individual encrypt/decrypt function for each algorithm

[George Cherian]

Remove the individual encrypt/decrypt function for easch algorithm.
This is in prepration of adding more crypto algorithms supported by
hardware. While at that simplify create_ctx_hdr/create_input_list
function interfaces.

Signed-off-by: George Cherian 
---
 drivers/crypto/cavium/cpt/cptvf_algs.c | 133 +
 drivers/crypto/cavium/cpt/cptvf_algs.h |   7 ++
 2 files changed, 77 insertions(+), 63 deletions(-)

diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c 
b/drivers/crypto/cavium/cpt/cptvf_algs.c
index cc853f9..c365fc6 100644
--- a/drivers/crypto/cavium/cpt/cptvf_algs.c
+++ b/drivers/crypto/cavium/cpt/cptvf_algs.c
@@ -98,7 +98,6 @@ static inline void update_output_data(struct cpt_request_info 
*req_info,
 }
 
 static inline u32 create_ctx_hdr(struct ablkcipher_request *req, u32 enc,
-u32 cipher_type, u32 aes_key_type,
 u32 *argcnt)
 {
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
@@ -124,11 +123,11 @@ static inline u32 create_ctx_hdr(struct 
ablkcipher_request *req, u32 enc,
req_info->req.param1 = req->nbytes; /* Encryption Data length */
req_info->req.param2 = 0; /*Auth data length */
 
-   fctx->enc.enc_ctrl.e.enc_cipher = cipher_type;
-   fctx->enc.enc_ctrl.e.aes_key = aes_key_type;
+   fctx->enc.enc_ctrl.e.enc_cipher = ctx->cipher_type;
+   fctx->enc.enc_ctrl.e.aes_key = ctx->key_type;
fctx->enc.enc_ctrl.e.iv_source = FROM_DPTR;
 
-   if (cipher_type == AES_XTS)
+   if (ctx->cipher_type == AES_XTS)
memcpy(fctx->enc.encr_key, ctx->enc_key, ctx->key_len * 2);
else
memcpy(fctx->enc.encr_key, ctx->enc_key, ctx->key_len);
@@ -154,14 +153,13 @@ static inline u32 create_ctx_hdr(struct 
ablkcipher_request *req, u32 enc,
 }
 
 static inline u32 create_input_list(struct ablkcipher_request  *req, u32 enc,
-   u32 cipher_type, u32 aes_key_type,
u32 enc_iv_len)
 {
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
struct cpt_request_info *req_info = >cpt_req;
u32 argcnt =  0;
 
-   create_ctx_hdr(req, enc, cipher_type, aes_key_type, );
+   create_ctx_hdr(req, enc, );
update_input_iv(req_info, req->info, enc_iv_len, );
update_input_data(req_info, req->src, req->nbytes, );
req_info->incnt = argcnt;
@@ -177,7 +175,6 @@ static inline void store_cb_info(struct ablkcipher_request 
*req,
 }
 
 static inline void create_output_list(struct ablkcipher_request *req,
- u32 cipher_type,
  u32 enc_iv_len)
 {
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
@@ -197,12 +194,9 @@ static inline void create_output_list(struct 
ablkcipher_request *req,
req_info->outcnt = argcnt;
 }
 
-static inline int cvm_enc_dec(struct ablkcipher_request *req, u32 enc,
- u32 cipher_type)
+static inline int cvm_enc_dec(struct ablkcipher_request *req, u32 enc)
 {
struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req);
-   struct cvm_enc_ctx *ctx = crypto_ablkcipher_ctx(tfm);
-   u32 key_type = AES_128_BIT;
struct cvm_req_ctx *rctx = ablkcipher_request_ctx(req);
u32 enc_iv_len = crypto_ablkcipher_ivsize(tfm);
struct fc_context *fctx = >fctx;
@@ -210,36 +204,10 @@ static inline int cvm_enc_dec(struct ablkcipher_request 
*req, u32 enc,
void *cdev = NULL;
int status;
 
-   switch (ctx->key_len) {
-   case 16:
-   key_type = AES_128_BIT;
-   break;
-   case 24:
-   key_type = AES_192_BIT;
-   break;
-   case 32:
-   if (cipher_type == AES_XTS)
-   key_type = AES_128_BIT;
-   else
-   key_type = AES_256_BIT;
-   break;
-   case 64:
-   if (cipher_type == AES_XTS)
-   key_type = AES_256_BIT;
-   else
-   return -EINVAL;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   if (cipher_type == DES3_CBC)
-   key_type = 0;
-
memset(req_info, 0, sizeof(struct cpt_request_info));
memset(fctx, 0, sizeof(struct fc_context));
-   create_input_list(req, enc, cipher_type, key_type, enc_iv_len);
-   create_output_list(req, cipher_type, enc_iv_len);
+   create_input_list(req, enc, enc_iv_len);
+   create_output_list(req, enc_iv_len);
store_cb_info(req, req_info);
cdev = dev_handle.cdev[smp_processor_id()];
status = cptvf_do_request(cdev, req_info);
@@ -254,34 +222,41 @@ static inline int cvm_enc_dec(struct ablkcipher_request 
*req, u32 enc,
return -EINPROGRESS;
 }
 
-int cvm_des3_encrypt_cbc(struct 

[PATCH 0/3] Add more algorithms and some misc cleanups

[George Cherian]

This series adds more algorithem support for CPT.
Add support for
-ecb(aes) 
-cfb(aes) 
-ecb(des3_ede)

Some cleanups too.

George Cherian (3):
  crypto: cavium: Downgrade the annoying misc interrupt print from
dev_err to dev_dbg
  crypto: cavium: Remove the individual encrypt/decrypt function for
each algorithm
  crypto: cavium: Add more algorithms

 drivers/crypto/cavium/cpt/cptvf_algs.c | 196 ++---
 drivers/crypto/cavium/cpt/cptvf_algs.h |   7 ++
 drivers/crypto/cavium/cpt/cptvf_main.c |   2 +-
 3 files changed, 141 insertions(+), 64 deletions(-)

-- 
2.1.4

Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

[Eric Biggers]

Hi Stephan,

On Thu, Apr 20, 2017 at 08:38:30PM +0200, Stephan Müller wrote:
> > 
> > By the way: do we really need this in the kernel at all, given that it's
> > just doing some math on data which userspace has access to?
> 
> It is the question about how we want the keys subsystem to operate. The DH 
> shared secret shall not be used as a key. But the DH operation is part of the 
> key subsystem. If there is never a case where the result of the DH operation 
> is used in the kernel, then the KDF can be removed and my patches could be 
> reverted. However, in this case, the entire DH business could be questioned 
> as 
> this can easily be done in user space as well.
> 

Well, who exactly is asking for Diffie-Hellman in the kernel at all?  If it can
be done in userspace then it should be done there.  Having it in the kernel
means having yet another API that's callable by unprivileged users and needs to
be audited for security vulnerabilities.  Just because the kernel can support
doing hashes or has an arbitrary-precision arithmetic library or whatever
doesn't mean it's the right place to do random crypto stuff.

- Eric

Re: [Patch V5 1/7] crypto: Multi-buffer encryption infrastructure support

[kbuild test robot]

Hi Megha,

[auto build test ERROR on next-20170420]
[also build test ERROR on v4.11-rc7]
[cannot apply to crypto/master sparc-next/master v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Megha-Dey/crypto-AES-CBC-multibuffer-implementation/20170421-064210
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   crypto/built-in.o: In function `simd_skcipher_exit_mb':
>> crypto/simd.c:267: undefined reference to `mcryptd_free_skcipher'
   crypto/simd.c:267:(.text+0x12624): relocation truncated to fit: 
R_AARCH64_CALL26 against undefined symbol `mcryptd_free_skcipher'
   crypto/built-in.o: In function `simd_skcipher_init_mb':
>> crypto/simd.c:282: undefined reference to `mcryptd_alloc_skcipher'
   crypto/simd.c:282:(.text+0x12650): relocation truncated to fit: 
R_AARCH64_CALL26 against undefined symbol `mcryptd_alloc_skcipher'

vim +267 crypto/simd.c

   261  }
   262  
   263  static void simd_skcipher_exit_mb(struct crypto_skcipher *tfm)
   264  {
   265  struct simd_skcipher_ctx_mb *ctx = crypto_skcipher_ctx(tfm);
   266  
 > 267  mcryptd_free_skcipher(ctx->mcryptd_tfm);
   268  }
   269  
   270  static int simd_skcipher_init_mb(struct crypto_skcipher *tfm)
   271  {
   272  struct simd_skcipher_ctx_mb *ctx = crypto_skcipher_ctx(tfm);
   273  struct mcryptd_skcipher *mcryptd_tfm;
   274  struct simd_skcipher_alg *salg;
   275  struct skcipher_alg *alg;
   276  unsigned reqsize;
   277  struct mcryptd_skcipher_ctx *mctx;
   278  
   279  alg = crypto_skcipher_alg(tfm);
   280  salg = container_of(alg, struct simd_skcipher_alg, alg);
   281  
 > 282  mcryptd_tfm = mcryptd_alloc_skcipher(salg->ialg_name,
   283 CRYPTO_ALG_INTERNAL,
   284 CRYPTO_ALG_INTERNAL);
   285  if (IS_ERR(mcryptd_tfm))

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


.config.gz
Description: application/gzip

Re: [Patch V5 7/7] crypto: AES CBC multi-buffer tcrypt

[kbuild test robot]

Hi Megha,

[auto build test WARNING on next-20170420]
[also build test WARNING on v4.11-rc7]
[cannot apply to crypto/master sparc-next/master v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Megha-Dey/crypto-AES-CBC-multibuffer-implementation/20170421-064210
config: parisc-c3000_defconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/crypto.h:21,
from include/crypto/aead.h:16,
from crypto/tcrypt.c:27:
   crypto/tcrypt.c: In function 'test_mb_acipher_cycles':
>> include/linux/kern_levels.h:4:18: warning: format '%llu' expects argument of 
>> type 'long long unsigned int', but argument 2 has type 'long unsigned int' 
>> [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:23:19: note: in expansion of macro 'KERN_SOH'
#define KERN_CONT KERN_SOH "c"
  ^~~~
>> include/linux/printk.h:315:9: note: in expansion of macro 'KERN_CONT'
 printk(KERN_CONT fmt, ##__VA_ARGS__)
^
>> crypto/tcrypt.c:1082:3: note: in expansion of macro 'pr_cont'
  pr_cont("1 operation in %llu cycles (%d bytes)\n",
  ^~~

vim +/KERN_CONT +315 include/linux/printk.h

a0cba217 Linus Torvalds 2016-08-09  299 printk(KERN_CRIT pr_fmt(fmt), 
##__VA_ARGS__)
a0cba217 Linus Torvalds 2016-08-09  300  #define pr_err(fmt, ...) \
a0cba217 Linus Torvalds 2016-08-09  301 printk(KERN_ERR pr_fmt(fmt), 
##__VA_ARGS__)
a0cba217 Linus Torvalds 2016-08-09  302  #define pr_warning(fmt, ...) \
a0cba217 Linus Torvalds 2016-08-09  303 printk(KERN_WARNING 
pr_fmt(fmt), ##__VA_ARGS__)
a0cba217 Linus Torvalds 2016-08-09  304  #define pr_warn pr_warning
a0cba217 Linus Torvalds 2016-08-09  305  #define pr_notice(fmt, ...) \
a0cba217 Linus Torvalds 2016-08-09  306 printk(KERN_NOTICE pr_fmt(fmt), 
##__VA_ARGS__)
a0cba217 Linus Torvalds 2016-08-09  307  #define pr_info(fmt, ...) \
a0cba217 Linus Torvalds 2016-08-09  308 printk(KERN_INFO pr_fmt(fmt), 
##__VA_ARGS__)
7b1460ec Steven Rostedt 2015-04-15  309  /*
7b1460ec Steven Rostedt 2015-04-15  310   * Like KERN_CONT, pr_cont() should 
only be used when continuing
7b1460ec Steven Rostedt 2015-04-15  311   * a line with no newline ('\n') 
enclosed. Otherwise it defaults
7b1460ec Steven Rostedt 2015-04-15  312   * back to KERN_DEFAULT.
7b1460ec Steven Rostedt 2015-04-15  313   */
968ab183 Linus Torvalds 2010-11-15  314  #define pr_cont(fmt, ...) \
968ab183 Linus Torvalds 2010-11-15 @315 printk(KERN_CONT fmt, 
##__VA_ARGS__)
968ab183 Linus Torvalds 2010-11-15  316  
968ab183 Linus Torvalds 2010-11-15  317  /* pr_devel() should produce zero code 
unless DEBUG is defined */
968ab183 Linus Torvalds 2010-11-15  318  #ifdef DEBUG
968ab183 Linus Torvalds 2010-11-15  319  #define pr_devel(fmt, ...) \
968ab183 Linus Torvalds 2010-11-15  320 printk(KERN_DEBUG pr_fmt(fmt), 
##__VA_ARGS__)
968ab183 Linus Torvalds 2010-11-15  321  #else
968ab183 Linus Torvalds 2010-11-15  322  #define pr_devel(fmt, ...) \
5264f2f7 Joe Perches2011-01-12  323 no_printk(KERN_DEBUG 
pr_fmt(fmt), ##__VA_ARGS__)

:: The code at line 315 was first introduced by commit
:: 968ab1838a5d48f02f5b471aa1d0e59e2cc2ccbc include/linux/kernel.h: Move 
logging bits to include/linux/printk.h

:: TO: Linus Torvalds <torva...@linux-foundation.org>
:: CC: Linus Torvalds <torva...@linux-foundation.org>

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


.config.gz
Description: application/gzip

Re: [Patch V5 7/7] crypto: AES CBC multi-buffer tcrypt

[kbuild test robot]

Hi Megha,

[auto build test WARNING on next-20170420]
[also build test WARNING on v4.11-rc7]
[cannot apply to crypto/master sparc-next/master v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Megha-Dey/crypto-AES-CBC-multibuffer-implementation/20170421-064210
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

   crypto/tcrypt.c: In function 'test_mb_acipher_cycles':
>> crypto/tcrypt.c:1082:3: warning: format '%llu' expects argument of type 
>> 'long long unsigned int', but argument 2 has type 'long unsigned int' 
>> [-Wformat=]
  pr_cont("1 operation in %llu cycles (%d bytes)\n",
  ^

vim +1082 crypto/tcrypt.c

  1066   * Initiate a maximum of MB_WIDTH operations per loop
  1067   * Measure performance over MB_WIDTH iterations
  1068   * Let do_multi_acipher_op count the cycles
  1069   */
  1070  for (i = 0; i < ITR; i++) {
  1071  mb_start = get_cycles();
  1072  ret = do_multi_acipher_op(req, enc);
  1073  
  1074  mb_end = get_cycles();
  1075  cycles += mb_end - mb_start;
  1076  if (ret)
  1077  goto out;
  1078  }
  1079  
  1080  out:
  1081  if (ret == 0)
> 1082  pr_cont("1 operation in %llu cycles (%d bytes)\n",
  1083  (cycles + 4) / (ITR*MB_WIDTH), blen);
  1084  
  1085  return ret;
  1086  }
  1087  
  1088  static void test_mb_acipher_speed(const char *algo, int enc, unsigned 
int secs,
  1089  struct cipher_speed_template *template,
  1090  unsigned int tcount, u8 *keysize)

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


.config.gz
Description: application/gzip

Re: [Patch V5 1/7] crypto: Multi-buffer encryption infrastructure support

[kbuild test robot]

Hi Megha,

[auto build test ERROR on next-20170420]
[also build test ERROR on v4.11-rc7]
[cannot apply to crypto/master sparc-next/master v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Megha-Dey/crypto-AES-CBC-multibuffer-implementation/20170421-064210
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "mcryptd_alloc_skcipher" [crypto/crypto_simd.ko] undefined!
>> ERROR: "mcryptd_free_skcipher" [crypto/crypto_simd.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH 6/6] ima: Support appended signatures for appraisal

[Thiago Jung Bauermann]

Am Donnerstag, 20. April 2017, 11:04:40 BRT schrieb kbuild test robot:
>In file included from security/integrity/ima/ima_appraise.c:19:0:
> 
>include/keys/asymmetric-type.h: In function 'asymmetric_key_ids':
> >> include/keys/asymmetric-type.h:76:12: error: dereferencing pointer to
> >> incomplete type 'const struct key'
>  return key->payload.data[asym_key_ids];
>^~

This happens with CONFIG_IMA_APPRAISE=y and CONFIG_KEYS=n.
Fixed by only including the new header files in ima_appraise.c if 
CONFIG_IMA_APPRAISE_APPENDED_SIG=y

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


>From e2d3143b13d6601f6a1f4936dfb569a04a1ce0cc Mon Sep 17 00:00:00 2001
From: Thiago Jung Bauermann 
Date: Mon, 20 Mar 2017 11:08:21 -0300
Subject: [PATCH 6/6] ima: Support appended signatures for appraisal

This patch introduces the appended_imasig keyword to the IMA policy syntax
to specify that a given hook should expect the file to have the IMA
signature appended to it. Here is how it can be used in a rule:

appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig
appraise func=KEXEC_KERNEL_CHECK appraise_type=appended_imasig|imasig

In the second form, IMA will accept either an appended signature or a
signature stored in the extended attribute. In that case, it will first
check whether there is an appended signature, and if not it will read it
from the extended attribute.

The format of the appended signature is the same used for signed kernel
modules. This means that the file can be signed with the scripts/sign-file
tool, with a command line such as this:

$ sign-file sha256 privkey_ima.pem x509_ima.der vmlinux

This code only works for files that are hashed from a memory buffer, not
for files that are read from disk at the time of hash calculation. In other
words, only hooks that use kernel_read_file can support appended
signatures.

The change in CONFIG_INTEGRITY_SIGNATURE to select CONFIG_KEYS instead of
depending on it is to avoid a dependency recursion in
CONFIG_IMA_APPRAISE_APPENDED_SIG, because CONFIG_MODULE_SIG_FORMAT selects
CONFIG_KEYS and Kconfig complains that CONFIG_INTEGRITY_SIGNATURE depends
on it.

Signed-off-by: Thiago Jung Bauermann 
---
 crypto/asymmetric_keys/asymmetric_type.c |  1 +
 crypto/asymmetric_keys/pkcs7_parser.c| 12 +
 crypto/asymmetric_keys/pkcs7_verify.c| 13 +
 include/crypto/pkcs7.h   |  3 ++
 include/linux/verification.h |  1 +
 security/integrity/Kconfig   |  2 +-
 security/integrity/ima/Kconfig   | 13 +
 security/integrity/ima/ima.h |  8 +++
 security/integrity/ima/ima_appraise.c| 86 +++-
 security/integrity/ima/ima_main.c| 30 +--
 security/integrity/ima/ima_policy.c  | 29 ---
 security/integrity/integrity.h   | 20 +---
 12 files changed, 199 insertions(+), 19 deletions(-)

diff --git a/crypto/asymmetric_keys/asymmetric_type.c 
b/crypto/asymmetric_keys/asymmetric_type.c
index e4b0ed386bc8..0d58ecfba2ea 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -28,6 +28,7 @@ const char *const key_being_used_for[NR__KEY_BEING_USED_FOR] 
= {
[VERIFYING_KEXEC_PE_SIGNATURE]  = "kexec PE sig",
[VERIFYING_KEY_SIGNATURE]   = "key sig",
[VERIFYING_KEY_SELF_SIGNATURE]  = "key self sig",
+   [VERIFYING_KEXEC_CMS_SIGNATURE] = "kexec CMS sig",
[VERIFYING_UNSPECIFIED_SIGNATURE]   = "unspec sig",
 };
 EXPORT_SYMBOL_GPL(key_being_used_for);
diff --git a/crypto/asymmetric_keys/pkcs7_parser.c 
b/crypto/asymmetric_keys/pkcs7_parser.c
index af4cd8649117..e41beda297a8 100644
--- a/crypto/asymmetric_keys/pkcs7_parser.c
+++ b/crypto/asymmetric_keys/pkcs7_parser.c
@@ -673,3 +673,15 @@ int pkcs7_note_signed_info(void *context, size_t hdrlen,
return -ENOMEM;
return 0;
 }
+
+/**
+ * pkcs7_get_message_sig - get signature in @pkcs7
+ *
+ * This function doesn't meaningfully support messages with more than one
+ * signature. It will always return the first signature.
+ */
+const struct public_key_signature *pkcs7_get_message_sig(
+   const struct pkcs7_message *pkcs7)
+{
+   return pkcs7->signed_infos ? pkcs7->signed_infos->sig : NULL;
+}
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c 
b/crypto/asymmetric_keys/pkcs7_verify.c
index 2d93d9eccb4d..eee78074580a 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -420,6 +420,19 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
return -EKEYREJECTED;
}
break;
+   case VERIFYING_KEXEC_CMS_SIGNATURE:
+   /* Shipping certificates in the CMS message is not allowed. */
+   if (pkcs7->certs) {
+   

Re: [PATCH V3 1/2] crypto: ccp - Use only the relevant interrupt bits

[Gary R Hook]

On 04/20/2017 03:20 PM, Hook, Gary wrote:

Each CCP queue can product interrupts for 4 conditions:
operation complete, queue empty, error, and queue stopped.
This driver only works with completion and error events.



Apologies for this errant submission. Please ignore one of these (V3 1/2);
the proper pair, with cover letter, is right behind this one.

Not that there's anything wrong with this one, only that it
went out without a cover letter.

...and now I see that there's a typo. Dang it.



Cc:  # 4.9.x-

Signed-off-by: Gary R Hook 
---

Re: [PATCH 5/6] MODSIGN: Export module signature definitions.

[Thiago Jung Bauermann]

Am Donnerstag, 20. April 2017, 15:37:37 BRT schrieb David Howells:
> Mimi Zohar  wrote:
> > On Tue, 2017-04-18 at 17:17 -0300, Thiago Jung Bauermann wrote:
> > > IMA will use the module_signature format for append signatures, so
> > > export
> > > the relevant definitions and factor out the code which verifies that the
> > > appended signature trailer is valid.
> > > 
> > > Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
> > > and be able to use validate_module_signature without having to depend on
> > > CONFIG_MODULE_SIG.
> > 
> > Basically we want to generalize the concept of an appended signature.
> >  Referring to it as a "module signature format" seems a bit confusing.
> > 
> > David, would you have a problem with changing the appended string from
> > "~Module signature appended~\n" to something more generic?
> 
> Conceptually, no.  Is it possible that doing so could break someone's module
> that they load on multiple versions of the kernel?  Say a module that only
> exports things and doesn't use anything from the core or any other module.

I think that changing the appended string has limited value because very few 
people actually see them. It's just a marker. We could s/module_signature/
appended_signature/ in the code but keep the actual string unchanged. What do 
you think?

Alternatively, we could change the string but accept both the old and the new 
string for backwards compatibility.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

[Patch V5 1/7] crypto: Multi-buffer encryption infrastructure support

[Megha Dey]

In this patch, the infrastructure needed to support multibuffer
encryption implementation is added:

a) Enhance mcryptd daemon to support skcipher requests.

b) Add multi-buffer simd skcipher helper which presents the
   top-level algorithm as an skcipher.

b) Update configuration to include multi-buffer encryption build
support.

For an introduction to the multi-buffer implementation, please see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 crypto/Kconfig |  15 +++
 crypto/mcryptd.c   | 298 +
 crypto/simd.c  | 164 +++
 include/crypto/internal/simd.h |   3 +
 include/crypto/mcryptd.h   |  35 +
 5 files changed, 515 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index aac4bc9..d172459 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1008,6 +1008,21 @@ config CRYPTO_AES_NI_INTEL
  ECB, CBC, LRW, PCBC, XTS. The 64 bit version has additional
  acceleration for CTR.
 
+config CRYPTO_AES_CBC_MB
+tristate "AES CBC algorithm (x86_64 Multi-Buffer, Experimental)"
+depends on X86 && 64BIT
+select CRYPTO_SIMD
+select CRYPTO_MCRYPTD
+help
+  AES CBC encryption implemented using multi-buffer technique.
+  This algorithm computes on multiple data lanes concurrently with
+  SIMD instructions for better throughput. It should only be used
+  when we expect many concurrent crypto requests to keep all the
+  data lanes filled to realize the performance benefit. If the data
+  lanes are unfilled, a flush operation will be initiated after some
+  delay to process the exisiting crypto jobs, adding some extra
+  latency to low load case.
+
 config CRYPTO_AES_SPARC64
tristate "AES cipher algorithms (SPARC64)"
depends on SPARC64
diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index 4e64726..4e4830e 100644
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -273,6 +273,266 @@ static inline bool mcryptd_check_internal(struct rtattr 
**tb, u32 *type,
return false;
 }
 
+static int mcryptd_enqueue_skcipher_request(struct mcryptd_queue *queue,
+   struct crypto_async_request *request,
+   struct mcryptd_skcipher_request_ctx *rctx)
+{
+   int cpu, err;
+   struct mcryptd_cpu_queue *cpu_queue;
+
+   cpu = get_cpu();
+   cpu_queue = this_cpu_ptr(queue->cpu_queue);
+   rctx->tag.cpu = cpu;
+
+   err = crypto_enqueue_request(_queue->queue, request);
+   pr_debug("enqueue request: cpu %d cpu_queue %p request %p\n",
+   cpu, cpu_queue, request);
+   queue_work_on(cpu, kcrypto_wq, _queue->work);
+   put_cpu();
+
+   return err;
+}
+
+static int mcryptd_skcipher_setkey(struct crypto_skcipher *parent,
+   const u8 *key, unsigned int keylen)
+{
+   struct mcryptd_skcipher_ctx *ctx = crypto_skcipher_ctx(parent);
+   struct crypto_skcipher *child = ctx->child;
+   int err;
+
+   crypto_skcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
+   crypto_skcipher_set_flags(child, crypto_skcipher_get_flags(parent) &
+   CRYPTO_TFM_REQ_MASK);
+   err = crypto_skcipher_setkey(child, key, keylen);
+   crypto_skcipher_set_flags(parent, crypto_skcipher_get_flags(child) &
+   CRYPTO_TFM_RES_MASK);
+   return err;
+}
+
+static void mcryptd_skcipher_complete(struct skcipher_request *req, int err)
+{
+   struct mcryptd_skcipher_request_ctx *rctx = skcipher_request_ctx(req);
+
+   local_bh_disable();
+   rctx->complete(>base, err);
+   local_bh_enable();
+}
+
+static void mcryptd_skcipher_encrypt(struct crypto_async_request *base,
+   int err)
+{
+   struct skcipher_request *req = skcipher_request_cast(base);
+   struct mcryptd_skcipher_request_ctx *rctx = skcipher_request_ctx(req);
+   struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+   struct mcryptd_skcipher_ctx *ctx = crypto_skcipher_ctx(tfm);
+   struct crypto_skcipher *child = ctx->child;
+   struct skcipher_request subreq;
+
+   if (unlikely(err == -EINPROGRESS))
+   goto out;
+
+   /* set up the skcipher request to work on */
+   skcipher_request_set_tfm(, child);
+   skcipher_request_set_callback(,
+   CRYPTO_TFM_REQ_MAY_SLEEP, 0, 0);
+   skcipher_request_set_crypt(, req->src, req->dst,
+   req->cryptlen, req->iv);
+
+   /*
+* pass addr of 

[Patch V5 2/7] crypto: AES CBC multi-buffer data structures

[Megha Dey]

This patch introduces the data structures and prototypes of functions
needed for doing AES CBC encryption using multi-buffer. Included are
the structures of the multi-buffer AES CBC job, job scheduler in C and
data structure defines in x86 assembly code.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h|  97 +
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 132 
 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 271 +
 arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 126 
 4 files changed, 626 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S

diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h 
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
new file mode 100644
index 000..024586b
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
@@ -0,0 +1,97 @@
+/*
+ * Header file for multi buffer AES CBC algorithm manager
+ * that deals with 8 buffers at a time
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:
+ * James Guilford 
+ * Sean Gulley 
+ * Tim Chen 
+ * Megha Dey 
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * 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.
+ * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * 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
+ * OWNER 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.
+ *
+ */
+#ifndef __AES_CBC_MB_CTX_H
+#define __AES_CBC_MB_CTX_H
+
+
+#include 
+
+#include "aes_cbc_mb_mgr.h"
+
+#define CBC_ENCRYPT0x01
+#define CBC_DECRYPT0x02
+#define CBC_START  0x04
+#define CBC_DONE   0x08
+
+#define CBC_CTX_STS_IDLE   0x00
+#define CBC_CTX_STS_PROCESSING 0x01
+#define CBC_CTX_STS_LAST   0x02
+#define CBC_CTX_STS_COMPLETE   0x04
+
+enum cbc_ctx_error {
+   CBC_CTX_ERROR_NONE   =  0,
+   CBC_CTX_ERROR_INVALID_FLAGS  = -1,
+   CBC_CTX_ERROR_ALREADY_PROCESSING = -2,
+   CBC_CTX_ERROR_ALREADY_COMPLETED  = -3,
+};
+
+#define cbc_ctx_init(ctx, n_bytes, op) \
+   do { \
+   (ctx)->flag = (op) | CBC_START; \
+   (ctx)->nbytes = (n_bytes); \
+   } while (0)
+
+/* AESNI routines to perform cbc decrypt and key expansion */
+
+asmlinkage void aesni_cbc_dec(struct crypto_aes_ctx *ctx, u8 *out,
+ const u8 *in, unsigned int len, u8 *iv);
+asmlinkage int aesni_set_key(struct crypto_aes_ctx *ctx, const u8 *in_key,
+unsigned int key_len);
+
+#endif /* __AES_CBC_MB_CTX_H */
diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h 

[Patch V5 3/7] crypto: AES CBC multi-buffer scheduler

[Megha Dey]

This patch implements in-order scheduler for encrypting multiple buffers
in parallel supporting AES CBC encryption with key sizes of
128, 192 and 256 bits. It uses 8 data lanes by taking advantage of the
SIMD instructions with XMM registers.

The multibuffer manager and scheduler is mostly written in assembly and
the initialization support is written C. The AES CBC multibuffer crypto
driver support interfaces with the multibuffer manager and scheduler
to support AES CBC encryption in parallel. The scheduler supports
job submissions, job flushing and and job retrievals after completion.

The basic flow of usage of the CBC multibuffer scheduler is as follows:

- The caller allocates an aes_cbc_mb_mgr_inorder_x8 object
and initializes it once by calling aes_cbc_init_mb_mgr_inorder_x8().

- The aes_cbc_mb_mgr_inorder_x8 structure has an array of JOB_AES
objects. Allocation and scheduling of JOB_AES objects are managed
by the multibuffer scheduler support routines. The caller allocates
a JOB_AES using aes_cbc_get_next_job_inorder_x8().

- The returned JOB_AES must be filled in with parameters for CBC
encryption (eg: plaintext buffer, ciphertext buffer, key, iv, etc) and
submitted to the manager object using aes_cbc_submit_job_inorder_xx().

- If the oldest JOB_AES is completed during a call to
aes_cbc_submit_job_inorder_x8(), it is returned. Otherwise,
NULL is returned.

- A call to aes_cbc_flush_job_inorder_x8() always returns the
oldest job, unless the multibuffer manager is empty of jobs.

- A call to aes_cbc_get_completed_job_inorder_x8() returns
a completed job. This routine is useful to process completed
jobs instead of waiting for the flusher to engage.

- When a job is returned from submit or flush, the caller extracts
the useful data and returns it to the multibuffer manager implicitly
by the next call to aes_cbc_get_next_job_xx().

Jobs are always returned from submit or flush routines in the order they
were submitted (hence "inorder").A job allocated using
aes_cbc_get_next_job_inorder_x8() must be filled in and submitted before
another call. A job returned by aes_cbc_submit_job_inorder_x8() or
aes_cbc_flush_job_inorder_x8() is 'deallocated' upon the next call to
get a job structure. Calls to get_next_job() cannot fail. If all jobs
are
allocated after a call to get_next_job(), the subsequent call to submit
always returns the oldest job in a completed state.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c   | 146 
 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 223 +++
 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 417 +
 3 files changed, 786 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S

diff --git a/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c 
b/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
new file mode 100644
index 000..2a2ce6c
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
@@ -0,0 +1,146 @@
+/*
+ * Initialization code for multi buffer AES CBC algorithm
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:
+ * James Guilford 
+ * Sean Gulley 
+ * Tim Chen 
+ * Megha Dey 
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * 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.
+ * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS 

[Patch V5 6/7] crypto: AES vectors for AES CBC multibuffer testing

[Megha Dey]

For more robust testing of AES CBC multibuffer support, additional
test vectors have been added to the AES CBC encrypt/decrypt
test case.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 crypto/testmgr.h | 1456 ++
 1 file changed, 1456 insertions(+)

diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 15c043f..85679b3 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -34413,4 +34413,1460 @@ struct comp_testvec {
},
 };
 
+#ifdef CONFIG_CRYPTO_AES_CBC_MB
+static struct cipher_testvec aes_cbc_enc_tv_template_rnddata_klen16[] = {
+{
+   .key =
+"\xd7\x0c\x4c\x6d\x11\x02\xb0\x31\x63\x9b\x82\x76\x9e\x03\x26\xdf",
+   .klen = 16,
+   .iv =
+"\xc1\x62\x66\x62\xb8\x65\x28\xfa\x5f\x36\xd3\x09\xb1\x2c\xa1\xa3",
+   .input =
+"\x4f\x6c\x63\xa5\xd0\x19\x08\x4e\xd4\x58\x33\xf6\x2b\xeb\x26\xb9",
+   .ilen = 16,
+   .result =
+"\xa0\x35\xb0\x33\xc0\x2e\xe5\xbb\xbc\xe6\x01\x9e\xf4\x67\x11\x14",
+   .rlen = 16,
+},
+{
+   .key =
+"\xd7\x0c\x4c\x6d\x11\x02\xb0\x31\x63\x9b\x82\x76\x9e\x03\x26\xdf",
+   .klen = 16,
+   .iv =
+"\x78\x6c\x27\xd6\xb2\xdc\xbe\x7b\xab\xc2\x43\xd7\x81\x0c\xe5\x20",
+   .input =
+"\x9a\x00\x4e\x5a\xb3\x51\x68\xaa\xdb\x6e\xe5\xa4\x7f\x23\x6e\x4d"
+"\x1e\x72\x5e\xad\x64\xc9\x96\x23\xf8\xae\xef\xf6\x7b\x7d\xd6\xf0",
+   .ilen = 32,
+   .result =
+"\x5a\xc0\x04\xc6\x53\xef\x3b\x69\xb1\x41\xc7\x85\xeb\x69\x82\xd0"
+"\xed\x09\xbb\xec\xb2\x8d\x5c\xc9\x61\x81\x5c\xf6\x99\x49\xa0\x4d",
+   .rlen = 32,
+},
+{
+   .key =
+"\xd7\x0c\x4c\x6d\x11\x02\xb0\x31\x63\x9b\x82\x76\x9e\x03\x26\xdf",
+   .klen = 16,
+   .iv =
+"\xc9\x05\x4c\x35\x96\x77\xd3\x3c\x3d\x97\x7c\x82\xf5\x58\x71\xf1",
+   .input =
+"\xa9\x5b\x03\xec\xec\x73\xed\xcb\x5c\x4c\xd2\x40\xb6\x9b\x49\x31"
+"\x5d\xf2\x23\xb3\x11\x98\xeb\x89\xab\x3e\x3a\xdd\xaa\xfd\xd1\xde"
+"\xab\x73\x59\x86\x1a\x59\x32\xb2\x55\x46\x4a\x80\xa4\xcc\xa8\xd9",
+   .ilen = 48,
+   .result =
+"\xdb\x05\x69\xe1\x33\x8b\x0b\x3d\x33\x12\x0d\xef\x94\x0f\xa3\xb3"
+"\xd7\x0a\x53\x7b\x98\x53\xc6\xc2\xa3\xd4\x7a\x30\x1a\xed\x45\xcc"
+"\x47\x38\xc1\x75\x0b\x3c\xd4\x8d\xa8\xf9\xd3\x71\xb8\x22\xa6\xae",
+   .rlen = 48,
+},
+{
+   .key =
+"\xd7\x0c\x4c\x6d\x11\x02\xb0\x31\x63\x9b\x82\x76\x9e\x03\x26\xdf",
+   .klen = 16,
+   .iv =
+"\x6c\xb4\x84\x61\x1e\x39\x4b\x22\x37\xaa\x7b\x78\xc0\x71\x20\x60",
+   .input =
+"\x05\x43\x76\x1e\xc6\x68\x43\x52\x5f\x43\x39\xbf\x93\x38\x38\x83"
+"\x38\x1d\x3c\xb5\xc8\xab\xe4\xd0\x7f\x1a\xac\xca\xcc\x16\xea\x75"
+"\x30\x75\x40\xe8\x61\x07\xc6\x04\x55\x2b\xf3\x29\xc3\x37\x83\x42"
+"\xe0\x21\xfb\xb4\x5d\x93\xbb\x87\x01\x3e\xa6\x9d\x3b\x0a\x5a\x37",
+   .ilen = 64,
+   .result =
+"\x83\x9f\xa0\xac\x14\x14\x88\x68\x7f\x9a\x5f\x98\x91\x71\xa8\xce"
+"\x28\xfb\x5e\xb1\x49\xe7\x63\x39\x12\x62\x00\x3e\x5c\x63\x2b\x12"
+"\x3d\xff\xd5\x0a\x43\x28\x52\x68\x78\x62\xc7\xa4\xbb\xca\x5d\x5e"
+"\xe3\xd5\x23\xb3\xe7\x22\xae\xf3\xd0\xd9\x00\x14\x0c\x46\x67\x17",
+   .rlen = 64,
+},
+{
+   .key =
+"\xd7\x0c\x4c\x6d\x11\x02\xb0\x31\x63\x9b\x82\x76\x9e\x03\x26\xdf",
+   .klen = 16,
+   .iv =
+"\xf9\xe8\xab\xe2\xf9\x28\xeb\x05\x10\xc4\x97\x37\x76\xe4\xe0\xd9",
+   .input =
+"\xab\x99\xe8\x2a\x18\x50\xdc\x80\x1f\x38\xb9\x01\x34\xd4\x59\x60"
+"\x4e\x1c\x21\x71\x22\x06\xbe\x5f\x71\x07\x3b\x13\xe7\x05\xca\xa5"
+"\x7b\x23\xb5\xaa\xc6\xdb\xe3\x17\xa9\x9f\xe1\xbc\xd5\x1b\xe6\xf5"
+"\xfa\x43\xdd\x80\x50\xc8\x8a\x32\x2f\x65\x25\xa4\xeb\xd1\x74\x02"
+"\x07\xc1\x04\x94\x6b\x34\xa1\x74\x62\xb2\x8d\x60\xf5\x7e\xda\x1a"
+"\x0f\xf5\x21\xe1\xd7\x88\xc8\x26\xd7\x49\xb2\x4a\x84\x2c\x00\x3b"
+"\x96\xde\x4e\xa7\x57\x27\xa0\xa4\x3a\xff\x69\x19\xf7\xec\xeb\x62"
+"\xff\x5a\x82\x0d\x25\x5e\x3c\x63\xb3\x6d\xc4\xb9\xe3\xc9\x3a\xc2",
+   .ilen = 128,
+   .result =
+"\xec\xd5\x2f\x6a\xfd\x61\xf2\x37\x19\x6f\x55\x31\xd7\x2c\x14\x4d"
+"\xc1\xb4\xbb\x7d\xa9\x1a\xe6\x85\x8c\x2f\xbf\x7e\x66\x21\xf8\x17"
+"\x9e\x09\x1b\x2a\x11\xbf\xdf\x7d\xdf\xf5\xfb\x0a\x16\x79\xe2\x43"
+"\x5c\x3b\x3e\x84\x35\xfd\x92\x9e\xe0\x31\x50\x1d\x62\xd6\x22\x99"
+"\x5f\x25\xb3\xe8\xdf\xb0\xc0\xab\xd9\xdb\xac\x4b\x9c\xe2\x89\xc6"
+"\x49\x7f\x5f\xee\xcb\xf6\x25\x10\x9f\x32\x58\x85\x45\x50\x74\x8a"
+"\x55\xce\x86\x44\xda\xe4\x93\x58\x4d\xd3\x73\x76\x40\xf6\x92\x8b"
+"\x99\xc1\x2b\xf9\x18\xd0\xfa\xd0\xa6\x84\x03\xf5\xd4\xcb\xfa\xe7",
+   .rlen = 128,
+},
+{
+   .key =
+"\xd7\x0c\x4c\x6d\x11\x02\xb0\x31\x63\x9b\x82\x76\x9e\x03\x26\xdf",
+   .klen = 16,
+   .iv =
+"\x58\x1e\x1a\x65\x16\x25\xaa\x55\x97\xcd\xeb\x4c\xd6\xb3\x9c\x2b",
+   .input =
+"\xef\x85\x0b\xe5\x02\xd5\xce\xcc\xad\x2d\x5e\xec\x1e\x01\x8c\x28"
+"\xf0\x2c\x23\x10\xaa\x84\xf0\x61\xe2\x56\x29\x21\x9f\x09\xaf\x9d"
+"\x7d\xfc\x60\x16\x4c\x67\xdd\xdf\x74\x35\x49\x81\xca\x68\xb6\xc7"

[Patch V5 5/7] crypto: AES CBC multi-buffer glue code

[Megha Dey]

This patch introduces the multi-buffer job manager which is responsible
for submitting scatter-gather buffers from several AES CBC jobs
to the multi-buffer algorithm. The glue code interfaces with the
underlying algorithm that handles 8 data streams of AES CBC encryption
in parallel. AES key expansion and CBC decryption requests are performed
in a manner similar to the existing AESNI Intel glue driver.

The outline of the algorithm for AES CBC encryption requests is
sketched below:

Any driver requesting the crypto service will place an async crypto
request on the workqueue.  The multi-buffer crypto daemon will pull an
AES CBC encryption request from work queue and put each request in an
empty data lane for multi-buffer crypto computation.  When all the empty
lanes are filled, computation will commence on the jobs in parallel and
the job with the shortest remaining buffer will get completed and be
returned. To prevent prolonged stall, when no new jobs arrive, we will
flush workqueue of jobs after a maximum allowable delay has elapsed.

To accommodate the fragmented nature of scatter-gather, we will keep
submitting the next scatter-buffer fragment for a job for multi-buffer
computation until a job is completed and no more buffer fragments
remain.
At that time we will pull a new job to fill the now empty data slot.
We check with the multibuffer scheduler to see if there are other
completed jobs to prevent extraneous delay in returning any completed
jobs.

This multi-buffer algorithm should be used for cases where we get at
least 8 streams of crypto jobs submitted at a reasonably high rate.
For low crypto job submission rate and low number of data streams, this
algorithm will not be beneficial. The reason is at low rate, we do not
fill out the data lanes before flushing the jobs instead of processing
them with all the data lanes full.  We will miss the benefit of parallel
computation, and adding delay to the processing of the crypto job at the
same time.  Some tuning of the maximum latency parameter may be needed
to get the best performance.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/Makefile|   1 +
 arch/x86/crypto/aes-cbc-mb/Makefile |  22 +
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 737 
 3 files changed, 760 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 34b3fa2..cc556a7 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_CRYPTO_CRC32_PCLMUL) += crc32-pclmul.o
 obj-$(CONFIG_CRYPTO_SHA256_SSSE3) += sha256-ssse3.o
 obj-$(CONFIG_CRYPTO_SHA512_SSSE3) += sha512-ssse3.o
 obj-$(CONFIG_CRYPTO_CRCT10DIF_PCLMUL) += crct10dif-pclmul.o
+obj-$(CONFIG_CRYPTO_AES_CBC_MB) += aes-cbc-mb/
 obj-$(CONFIG_CRYPTO_POLY1305_X86_64) += poly1305-x86_64.o
 
 # These modules require assembler to support AVX.
diff --git a/arch/x86/crypto/aes-cbc-mb/Makefile 
b/arch/x86/crypto/aes-cbc-mb/Makefile
new file mode 100644
index 000..b642bd8
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/Makefile
@@ -0,0 +1,22 @@
+#
+# Arch-specific CryptoAPI modules.
+#
+
+avx_supported := $(call as-instr,vpxor %xmm0$(comma)%xmm0$(comma)%xmm0,yes,no)
+
+# we need decryption and key expansion routine symbols
+# if either AESNI_NI_INTEL or AES_CBC_MB is a module
+
+ifeq ($(CONFIG_CRYPTO_AES_NI_INTEL),m)
+   dec_support := ../aesni-intel_asm.o
+endif
+ifeq ($(CONFIG_CRYPTO_AES_CBC_MB),m)
+   dec_support := ../aesni-intel_asm.o
+endif
+
+ifeq ($(avx_supported),yes)
+   obj-$(CONFIG_CRYPTO_AES_CBC_MB) += aes-cbc-mb.o
+   aes-cbc-mb-y := $(dec_support) aes_cbc_mb.o aes_mb_mgr_init.o \
+   mb_mgr_inorder_x8_asm.o mb_mgr_ooo_x8_asm.o \
+   aes_cbc_enc_x8.o
+endif
diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c 
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
new file mode 100644
index 000..0d30383
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
@@ -0,0 +1,737 @@
+/*
+ * Multi buffer AES CBC algorithm glue code
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:

Re: [PATCH 3/6] ima: Simplify policy_func_show.

[Thiago Jung Bauermann]

Am Donnerstag, 20. April 2017, 08:13:23 BRT schrieb Mimi Zohar:
> On Tue, 2017-04-18 at 17:17 -0300, Thiago Jung Bauermann wrote:
> > If the func_tokens array uses the same indices as enum ima_hooks,
> > policy_func_show can be a lot simpler, and the func_* enum becomes
> > unnecessary.
> 
> My main concern with separating the enumeration from the string
> definition is that they might become out of sync.  Perhaps using
> macros, similar to those used for kernel_read_file_id_str(), would be
> better?

I agree that it would be better. Is the patch below what you had in mind?

I also noticed that policy_func_show can be even simpler if we stop using the 
printf format string from the policy_tokens table. What do you think?

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


>From 594628c94f5dd7c6d2624944a76b6a01f9668128 Mon Sep 17 00:00:00 2001
From: Thiago Jung Bauermann 
Date: Mon, 10 Apr 2017 14:59:44 -0300
Subject: [PATCH 3/6] ima: Simplify policy_func_show.

If the func_tokens array uses the same indices as enum ima_hooks,
policy_func_show can be a lot simpler, and the func_* enum becomes
unnecessary.

Also, if we use the same macro trick used by kernel_read_file_id_str we can
use one hooks list for both the enum and the string array, making sure they
are always in sync (suggested by Mimi Zohar).

Finally, by using the printf pattern for the function token directly
instead of using the pt macro we can simplify policy_func_show even further
and avoid the need of having a temporary buffer. Since the only use of
Opt_func's printf pattern in policy_tokens was in policy_func_show, we
don't need it at all anymore so remove it.

Signed-off-by: Thiago Jung Bauermann 
---
 security/integrity/ima/ima.h| 25 +---
 security/integrity/ima/ima_policy.c | 60 +
 2 files changed, 22 insertions(+), 63 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index b563fbd4d122..51ef805cf7f3 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -172,17 +172,22 @@ static inline unsigned long ima_hash_key(u8 *digest)
return hash_long(*digest, IMA_HASH_BITS);
 }
 
+#define __ima_hooks(hook)  \
+   hook(NONE)  \
+   hook(FILE_CHECK)\
+   hook(MMAP_CHECK)\
+   hook(BPRM_CHECK)\
+   hook(POST_SETATTR)  \
+   hook(MODULE_CHECK)  \
+   hook(FIRMWARE_CHECK)\
+   hook(KEXEC_KERNEL_CHECK)\
+   hook(KEXEC_INITRAMFS_CHECK) \
+   hook(POLICY_CHECK)  \
+   hook(MAX_CHECK)
+#define __ima_hook_enumify(ENUM)   ENUM,
+
 enum ima_hooks {
-   FILE_CHECK = 1,
-   MMAP_CHECK,
-   BPRM_CHECK,
-   POST_SETATTR,
-   MODULE_CHECK,
-   FIRMWARE_CHECK,
-   KEXEC_KERNEL_CHECK,
-   KEXEC_INITRAMFS_CHECK,
-   POLICY_CHECK,
-   MAX_CHECK
+   __ima_hooks(__ima_hook_enumify)
 };
 
 /* LIM API function definitions */
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index cfda5d7b17ec..39d43a5beb5a 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -503,7 +503,7 @@ static match_table_t policy_tokens = {
{Opt_subj_user, "subj_user=%s"},
{Opt_subj_role, "subj_role=%s"},
{Opt_subj_type, "subj_type=%s"},
-   {Opt_func, "func=%s"},
+   {Opt_func, NULL},
{Opt_mask, "mask=%s"},
{Opt_fsmagic, "fsmagic=%s"},
{Opt_fsuuid, "fsuuid=%s"},
@@ -896,23 +896,10 @@ static const char *const mask_tokens[] = {
"MAY_APPEND"
 };
 
-enum {
-   func_file = 0, func_mmap, func_bprm,
-   func_module, func_firmware, func_post,
-   func_kexec_kernel, func_kexec_initramfs,
-   func_policy
-};
+#define __ima_hook_stringify(str)  #str,
 
 static const char *const func_tokens[] = {
-   "FILE_CHECK",
-   "MMAP_CHECK",
-   "BPRM_CHECK",
-   "MODULE_CHECK",
-   "FIRMWARE_CHECK",
-   "POST_SETATTR",
-   "KEXEC_KERNEL_CHECK",
-   "KEXEC_INITRAMFS_CHECK",
-   "POLICY_CHECK"
+   __ima_hooks(__ima_hook_stringify)
 };
 
 void *ima_policy_start(struct seq_file *m, loff_t *pos)
@@ -949,49 +936,16 @@ void ima_policy_stop(struct seq_file *m, void *v)
 
 #define pt(token)  policy_tokens[token + Opt_err].pattern
 #define mt(token)  mask_tokens[token]
-#define ft(token)  func_tokens[token]
 
 /*
  * policy_func_show - display the ima_hooks policy rule
  */
 static void policy_func_show(struct seq_file *m, enum ima_hooks func)
 {
-   char tbuf[64] = {0,};
-
-   switch (func) {
-   case FILE_CHECK:
-   seq_printf(m, pt(Opt_func), ft(func_file));
-   break;
-   case MMAP_CHECK:
-   seq_printf(m, pt(Opt_func), ft(func_mmap));
-  

[Patch V5 7/7] crypto: AES CBC multi-buffer tcrypt

[Megha Dey]

The tcrypt test framework for CBC multi-buffer testing is
laid out in this patch. Tcrypt has been extended to validate
the functionality and performance of AES CBC multi-buffer support.

A new test(mode=600) has been added to test the speed of the multibuffer
case, as multi-buffer encrypt will wait for additional encrypt requests
that never arrive to kick off computation. So we always incur the extra
delay before flush timer expires to trigger the computation in the
(mode=500)
test. We create the new tests that will send out these additional
requests
that can be aggregated and computed in parallel for true throughput
speed test
of the multi-buffer encrypt test case.case.

The enhanced CBC tests create multiple transforms and exercise
the multi-buffer implementation. Crafted requests are sent at once
to the multiple transforms created and the returned responses
are compared with expected results. The test vectors are so chosen
as to exercise the scatter-gather list to the maximum allowable limit
within the framework.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 crypto/tcrypt.c  | 257 +++-
 crypto/testmgr.c | 707 +++
 crypto/testmgr.h |  64 -
 3 files changed, 1015 insertions(+), 13 deletions(-)

diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 9a11f3c..1d4416a 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "tcrypt.h"
 
 /*
@@ -84,7 +85,7 @@ struct tcrypt_result {
int err;
 };
 
-static void tcrypt_complete(struct crypto_async_request *req, int err)
+void tcrypt_complete(struct crypto_async_request *req, int err)
 {
struct tcrypt_result *res = req->data;
 
@@ -183,6 +184,11 @@ static int test_aead_cycles(struct aead_request *req, int 
enc, int blen)
 
 #define XBUFSIZE 8
 #define MAX_IVLEN 32
+#define MB_WIDTH 8
+struct scatterlist mb_sg[MB_WIDTH][XBUFSIZE];
+struct skcipher_request *mb_req[MB_WIDTH];
+struct tcrypt_result mb_tresult[MB_WIDTH];
+char *mb_xbuf[MB_WIDTH][XBUFSIZE];
 
 static int testmgr_alloc_buf(char *buf[XBUFSIZE])
 {
@@ -780,6 +786,46 @@ static inline int do_one_acipher_op(struct 
skcipher_request *req, int ret)
return ret;
 }
 
+
+/*
+ * Perform a maximum of MB_WIDTH operations.
+ * Await the results and measure performance.
+ */
+cycles_t mb_start, mb_end;
+static int mb_err[MB_WIDTH];
+
+static inline int do_multi_acipher_op(
+   struct skcipher_request *req[MB_WIDTH], int enc)
+{
+   int i, ret, comp_ret = 0;
+   bool is_async;
+
+   for (i = 0; i < MB_WIDTH; ++i) {
+   ret = enc == ENCRYPT ? crypto_skcipher_encrypt(req[i])
+   : crypto_skcipher_decrypt(req[i]);
+   mb_err[i] = ret;
+   if (ret == -EINPROGRESS || ret == -EBUSY)
+   continue; /* on with next req */
+   /* any other error, bail out */
+   if (ret)
+   return ret;
+   }
+   for (i = 0; i < MB_WIDTH; ++i) {
+   struct tcrypt_result *tr = req[i]->base.data;
+
+   is_async = mb_err[i] == -EINPROGRESS || mb_err[i] == -EBUSY;
+   if (is_async) {
+   wait_for_completion(>completion);
+   reinit_completion(>completion);
+   }
+   comp_ret = tr->err;
+   if (comp_ret)
+   pr_info("multi_acipher_op error\n");
+   }
+
+   return comp_ret;
+}
+
 static int test_acipher_jiffies(struct skcipher_request *req, int enc,
int blen, int secs)
 {
@@ -927,6 +973,7 @@ static void test_skcipher_speed(const char *algo, int enc, 
unsigned int secs,
if (ret) {
pr_err("setkey() failed flags=%x\n",
crypto_skcipher_get_flags(tfm));
+
goto out_free_req;
}
 
@@ -980,6 +1027,203 @@ static void test_skcipher_speed(const char *algo, int 
enc, unsigned int secs,
crypto_free_skcipher(tfm);
 }
 
+static int test_mb_acipher_jiffies(
+   struct skcipher_request *req[MB_WIDTH], int enc, int blen, int secs)
+{
+   unsigned long start, end;
+   int bcount;
+   int ret;
+
+   /* initiate a maximum of MB_WIDTH operations and measure performance */
+   for (start = jiffies, end = start + secs * HZ, bcount = 0;
+   time_before(jiffies, end); bcount += MB_WIDTH) {
+   ret = do_multi_acipher_op(req, enc);
+   if (ret)
+   return ret;
+   }
+
+   pr_cont("%d operations in %d seconds (%ld bytes)\n",
+   bcount, secs, (long)bcount * blen);
+   return 0;
+}
+
+#define ITR 8
+static int 

[Patch V5 4/7] crypto: AES CBC by8 encryption

[Megha Dey]

This patch introduces the assembly routine to do a by8 AES CBC encryption
in support of the AES CBC multi-buffer implementation.

It encrypts 8 data streams of the same key size simultaneously.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S | 775 
 1 file changed, 775 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S

diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S 
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
new file mode 100644
index 000..2130574
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
@@ -0,0 +1,775 @@
+/*
+ * AES CBC by8 multibuffer optimization (x86_64)
+ * This file implements 128/192/256 bit AES CBC encryption
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:
+ * James Guilford 
+ * Sean Gulley 
+ * Tim Chen 
+ * Megha Dey 
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * 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.
+ * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * 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
+ * OWNER 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 
+
+/* stack size needs to be an odd multiple of 8 for alignment */
+
+#define AES_KEYSIZE_12816
+#define AES_KEYSIZE_19224
+#define AES_KEYSIZE_25632
+
+#define XMM_SAVE_SIZE  16*10
+#define GPR_SAVE_SIZE  8*9
+#define STACK_SIZE (XMM_SAVE_SIZE + GPR_SAVE_SIZE)
+
+#define GPR_SAVE_REG   %rsp
+#define GPR_SAVE_AREA  %rsp + XMM_SAVE_SIZE
+#define LEN_AREA_OFFSETXMM_SAVE_SIZE + 8*8
+#define LEN_AREA_REG   %rsp
+#define LEN_AREA   %rsp + XMM_SAVE_SIZE + 8*8
+
+#define IN_OFFSET  0
+#define OUT_OFFSET 8*8
+#define KEYS_OFFSET16*8
+#define IV_OFFSET  24*8
+
+
+#define IDX%rax
+#define TMP%rbx
+#define ARG%rdi
+#define LEN%rsi
+
+#define KEYS0  %r14
+#define KEYS1  %r15
+#define KEYS2  %rbp
+#define KEYS3  %rdx
+#define KEYS4  %rcx
+#define KEYS5  %r8
+#define KEYS6  %r9
+#define KEYS7  %r10
+
+#define IN0%r11
+#define IN2%r12
+#define IN4%r13
+#define IN6LEN
+
+#define XDATA0 %xmm0
+#define XDATA1 %xmm1
+#define XDATA2 %xmm2
+#define XDATA3 %xmm3
+#define XDATA4 %xmm4
+#define XDATA5 %xmm5
+#define XDATA6 %xmm6
+#define XDATA7 %xmm7
+
+#define XKEY0_3%xmm8
+#define XKEY1_4%xmm9
+#define XKEY2_5%xmm10
+#define XKEY3_6%xmm11
+#define XKEY4_7%xmm12
+#define XKEY5_8%xmm13
+#define XKEY6_9%xmm14
+#define XTMP   %xmm15
+
+#defineMOVDQ movdqu /* assume buffers not aligned */
+#define CONCAT(a, b)   a##b
+#define INPUT_REG_SUFX 1   /* IN */
+#define XDATA_REG_SUFX 2   /* XDAT */
+#define KEY_REG_SUFX   3   /* KEY */
+#define XMM_REG_SUFX   4   /* XMM */
+

[Patch V5 0/7] crypto: AES CBC multibuffer implementation

[Megha Dey]

In this patch series, we introduce AES CBC encryption that is parallelized on
x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data
streams in parallel with SIMD instructions. Decryption is handled as in the
existing AESNI Intel CBC implementation which can already parallelize decryption
even for a single data stream.

Please see the multi-buffer whitepaper for details of the technique:
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html

It is important that any driver uses this algorithm properly for scenarios
where we have many data streams that can fill up the data lanes most of the
time. It shouldn't be used when only a single data stream is expected mostly.
Otherwise we may incur extra delays when we have frequent gaps in data lanes,
causing us to wait till data come in to fill the data lanes before initiating
encryption.  We may have to wait for flush operations to commence when no new
data come in after some wait time. However we keep this extra delay to a
minimum by opportunistically flushing the unfinished jobs if crypto daemon is
the only active task running on a cpu.

By using this technique, we saw a throughput increase of up to 5.7x under
optimal conditions when we have fully loaded encryption jobs filling up all
the data lanes.

Change Log:

v5
1. Use an async implementation of the inner algorithm instead of sync and use
the latest skcipher interface instead of the older blkcipher interface.
(we have picked up this work after a while)

v4
1. Make the decrypt path also use ablkcpher walk.
http://lkml.iu.edu/hypermail/linux/kernel/1512.0/01807.html

v3
1. Use ablkcipher_walk helpers to walk the scatter gather list
and eliminated needs to modify blkcipher_walk for multibuffer cipher

v2
1. Update cpu feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory

Megha Dey (7):
  crypto: Multi-buffer encryption infrastructure support
  crypto: AES CBC multi-buffer data structures
  crypto: AES CBC multi-buffer scheduler
  crypto: AES CBC by8 encryption
  crypto: AES CBC multi-buffer glue code
  crypto: AES vectors for AES CBC multibuffer testing
  crypto: AES CBC multi-buffer tcrypt

 arch/x86/crypto/Makefile   |1 +
 arch/x86/crypto/aes-cbc-mb/Makefile|   22 +
 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S|  775 ++
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c|  737 ++
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h|   97 ++
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h|  132 ++
 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c   |  146 ++
 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S |  271 
 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S |  223 +++
 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S |  417 ++
 arch/x86/crypto/aes-cbc-mb/reg_sizes.S |  126 ++
 crypto/Kconfig |   15 +
 crypto/mcryptd.c   |  298 
 crypto/simd.c  |  164 +++
 crypto/tcrypt.c|  257 +++-
 crypto/testmgr.c   |  707 +
 crypto/testmgr.h   | 1496 
 include/crypto/internal/simd.h |3 +
 include/crypto/mcryptd.h   |   35 +
 19 files changed, 5921 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S

-- 
1.9.1

[PATCH V3 2/2] crypto: ccp - Disable interrupts early on unload

[Gary R Hook]

From: Gary R Hook 

Ensure that we disable interrupts first when shutting down
the driver.

Cc:  # 4.9.x+

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev-v5.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index c7972e733e43..13b81a1c1184 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -942,10 +942,10 @@ static void ccp5_destroy(struct ccp_device *ccp)
iowrite32(cmd_q->qcontrol & ~CMD5_Q_RUN, cmd_q->reg_control);
 
/* Disable the interrupts */
-   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_interrupt_status);
+   iowrite32(0x00, cmd_q->reg_int_enable);
 
/* Clear the interrupt status */
-   iowrite32(0x00, cmd_q->reg_int_enable);
+   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_interrupt_status);
ioread32(cmd_q->reg_int_status);
ioread32(cmd_q->reg_status);
}

[PATCH V3 1/2] crypto: ccp - Use only the relevant interrupt bits

[Gary R Hook]

Each CCP queue can product interrupts for 4 conditions:
operation complete, queue empty, error, and queue stopped.
This driver only works with completion and error events.

Cc:  # 4.9.x+

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev-v5.c |9 +
 drivers/crypto/ccp/ccp-dev.h|5 ++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index e03d06a54d4e..c7972e733e43 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -801,7 +801,7 @@ static int ccp5_init(struct ccp_device *ccp)
ioread32(cmd_q->reg_status);
 
/* Clear the interrupts */
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_interrupt_status);
+   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_interrupt_status);
}
 
dev_dbg(dev, "Requesting an IRQ...\n");
@@ -882,7 +882,7 @@ static int ccp5_init(struct ccp_device *ccp)
/* Enable interrupts */
for (i = 0; i < ccp->cmd_q_count; i++) {
cmd_q = >cmd_q[i];
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_int_enable);
+   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_int_enable);
}
 
dev_dbg(dev, "Registering device...\n");
@@ -942,7 +942,7 @@ static void ccp5_destroy(struct ccp_device *ccp)
iowrite32(cmd_q->qcontrol & ~CMD5_Q_RUN, cmd_q->reg_control);
 
/* Disable the interrupts */
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_interrupt_status);
+   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_interrupt_status);
 
/* Clear the interrupt status */
iowrite32(0x00, cmd_q->reg_int_enable);
@@ -1002,7 +1002,8 @@ static irqreturn_t ccp5_irq_handler(int irq, void *data)
cmd_q->int_rcvd = 1;
 
/* Acknowledge the interrupt and wake the kthread */
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_interrupt_status);
+   iowrite32(SUPPORTED_INTERRUPTS,
+ cmd_q->reg_interrupt_status);
wake_up_interruptible(_q->int_queue);
}
}
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 191274d41036..2dfec019a832 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -109,9 +109,8 @@
 #define INT_COMPLETION 0x1
 #define INT_ERROR  0x2
 #define INT_QUEUE_STOPPED  0x4
-#define ALL_INTERRUPTS (INT_COMPLETION| \
-INT_ERROR| \
-INT_QUEUE_STOPPED)
+#defineINT_EMPTY_QUEUE 0x8
+#define SUPPORTED_INTERRUPTS   (INT_COMPLETION | INT_ERROR)
 
 #define LSB_REGION_WIDTH   5
 #define MAX_LSB_CNT8

[PATCH V3 0/2] Interrupt management fixes

[Gary R Hook]

Correct the driver to attend to only relevant interrupt
bits, and ensure that interrupts are managed properly
at module unload.

Changes from V2:
- Apply patches to relevant stable branches

Changes from V1:
- Changed the #define to "SUPPORTED_INTERRUPTS"

---

Gary R Hook (2):
  crypto: ccp - Use only the relevant interrupt bits
  crypto: ccp - Disable interrupts early on unload


 drivers/crypto/ccp/ccp-dev-v5.c |   11 ++-
 drivers/crypto/ccp/ccp-dev.h|5 ++---
 2 files changed, 8 insertions(+), 8 deletions(-)

--

[PATCH V3 1/2] crypto: ccp - Use only the relevant interrupt bits

[Gary R Hook]

Each CCP queue can product interrupts for 4 conditions:
operation complete, queue empty, error, and queue stopped.
This driver only works with completion and error events.

Cc:  # 4.9.x-

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev-v5.c |9 +
 drivers/crypto/ccp/ccp-dev.h|5 ++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index e03d06a54d4e..c7972e733e43 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -801,7 +801,7 @@ static int ccp5_init(struct ccp_device *ccp)
ioread32(cmd_q->reg_status);
 
/* Clear the interrupts */
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_interrupt_status);
+   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_interrupt_status);
}
 
dev_dbg(dev, "Requesting an IRQ...\n");
@@ -882,7 +882,7 @@ static int ccp5_init(struct ccp_device *ccp)
/* Enable interrupts */
for (i = 0; i < ccp->cmd_q_count; i++) {
cmd_q = >cmd_q[i];
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_int_enable);
+   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_int_enable);
}
 
dev_dbg(dev, "Registering device...\n");
@@ -942,7 +942,7 @@ static void ccp5_destroy(struct ccp_device *ccp)
iowrite32(cmd_q->qcontrol & ~CMD5_Q_RUN, cmd_q->reg_control);
 
/* Disable the interrupts */
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_interrupt_status);
+   iowrite32(SUPPORTED_INTERRUPTS, cmd_q->reg_interrupt_status);
 
/* Clear the interrupt status */
iowrite32(0x00, cmd_q->reg_int_enable);
@@ -1002,7 +1002,8 @@ static irqreturn_t ccp5_irq_handler(int irq, void *data)
cmd_q->int_rcvd = 1;
 
/* Acknowledge the interrupt and wake the kthread */
-   iowrite32(ALL_INTERRUPTS, cmd_q->reg_interrupt_status);
+   iowrite32(SUPPORTED_INTERRUPTS,
+ cmd_q->reg_interrupt_status);
wake_up_interruptible(_q->int_queue);
}
}
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 191274d41036..2dfec019a832 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -109,9 +109,8 @@
 #define INT_COMPLETION 0x1
 #define INT_ERROR  0x2
 #define INT_QUEUE_STOPPED  0x4
-#define ALL_INTERRUPTS (INT_COMPLETION| \
-INT_ERROR| \
-INT_QUEUE_STOPPED)
+#defineINT_EMPTY_QUEUE 0x8
+#define SUPPORTED_INTERRUPTS   (INT_COMPLETION | INT_ERROR)
 
 #define LSB_REGION_WIDTH   5
 #define MAX_LSB_CNT8

Re: [PATCH v2 5/9] staging: ccree: add AEAD support

[kbuild test robot]

Hi Gilad,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc7]
[cannot apply to staging/staging-testing next-20170420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Ben-Yossef/staging-ccree-add-Arm-TrustZone-CryptoCell-REE-driver/20170420-222023


coccinelle warnings: (new ones prefixed by >>)

>> drivers/staging/ccree/ssi_buffer_mgr.c:758:2-4: ERROR: test of a 
>> variable/field address

vim +758 drivers/staging/ccree/ssi_buffer_mgr.c

   742  
   743  if (areq_ctx->gcm_iv_inc2_dma_addr != 0) {
   744  
SSI_RESTORE_DMA_ADDR_TO_48BIT(areq_ctx->gcm_iv_inc2_dma_addr);
   745  dma_unmap_single(dev, 
areq_ctx->gcm_iv_inc2_dma_addr, 
   746  AES_BLOCK_SIZE, DMA_TO_DEVICE);
   747  }
   748  }
   749  #endif
   750  
   751  if (areq_ctx->ccm_hdr_size != ccm_header_size_null) {
   752  if (areq_ctx->ccm_iv0_dma_addr != 0) {
   753  
SSI_RESTORE_DMA_ADDR_TO_48BIT(areq_ctx->ccm_iv0_dma_addr);
   754  dma_unmap_single(dev, 
areq_ctx->ccm_iv0_dma_addr, 
   755  AES_BLOCK_SIZE, DMA_TO_DEVICE);
   756  }
   757  
 > 758  if (_ctx->ccm_adata_sg != NULL)
   759  dma_unmap_sg(dev, _ctx->ccm_adata_sg,
   760  1, DMA_TO_DEVICE);
   761  }
   762  if (areq_ctx->gen_ctx.iv_dma_addr != 0) {
   763  
SSI_RESTORE_DMA_ADDR_TO_48BIT(areq_ctx->gen_ctx.iv_dma_addr);
   764  dma_unmap_single(dev, areq_ctx->gen_ctx.iv_dma_addr,
   765   hw_iv_size, DMA_BIDIRECTIONAL);
   766  }

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

Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

[Stephan Müller]

Am Donnerstag, 20. April 2017, 19:46:02 CEST schrieb Eric Biggers:

Hi Eric,

> Hi Stephan,
> 
> On Thu, Apr 20, 2017 at 03:27:17PM +0200, Stephan Müller wrote:
> > Am Donnerstag, 20. April 2017, 07:46:31 CEST schrieb Eric Biggers:
> > 
> > Hi Eric,
> > 
> > > From: Eric Biggers 
> > > 
> > > The result of the Diffie-Hellman computation may be shorter than the
> > > input prime number.  Only calculate the KDF over the actual result;
> > > don't include additional uninitialized memory.
> > 
> > Thank you for catching that (and all the rest). But I think this patch is
> > not correct. If the DH operation results in a shorter value, the trailing
> > part must be set to null and the KDF calculated over the entire prime
> > length.
> > 
> > Thus, if the DH result is shorter than the prime, the memory should look
> > like DH result || 0x00  ||
> > otherinfo.
> > 
> > Thus, instead of this patch, I would think that the kmalloc call should be
> > changed to a kzalloc.
> 
> Is this in the standard? 

That is the gotcha that is not explicitly written in the standard. However, 
based on my experience with other implementations and tests like ECDSA and RSA 
CAVS testing, the standards seem to always interpreted to use the full allowed 
length. If the mathematical result is shorter than the defined length, it 
should be zero-padded.

> And is it the user-specified length of the prime
> number, or the length after stripping leading zeroes?

It should be the length of the prime used for the DH operation. As the prime 
is given with the DH parameters, the DH parameter set defines the length of 
the prime.

I cannot say about the stripping of leading zeros of user-provided primes 
because I have no idea where that is defined.

I would need to do some further research on this matter and check with the 
authors of the standard.

> Also, note that the
> numbers are being represented in big endian format; is that required, or
> just coincidental?  With big endian numbers leading zeroes go at the
> beginning, not the end, otherwise their value will be changed...

The numbers are MPI and are therefore big endian formats. Also the counter in 
the KDF is a big endian format which is mandated in the spec.

You are right that the zeros go to the beginning of the number and I made a 
wrong statement in my initial remark regarding the zero value.
> 
> - Ericinning and my initial remark regarding where the zeros are is wrong. 
Yet, IMHO we should not stip the zeros before applying the KDF as this would 
imply that the KDF result is different.
> 
> By the way: do we really need this in the kernel at all, given that it's
> just doing some math on data which userspace has access to?

It is the question about how we want the keys subsystem to operate. The DH 
shared secret shall not be used as a key. But the DH operation is part of the 
key subsystem. If there is never a case where the result of the DH operation 
is used in the kernel, then the KDF can be removed and my patches could be 
reverted. However, in this case, the entire DH business could be questioned as 
this can easily be done in user space as well.

Ciao
Stephan

[PATCH] staging: ccree: fix ifnullfree.cocci warnings

[kbuild test robot]

drivers/staging/ccree/ssi_hash.c:317:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:320:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:323:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:373:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:375:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:377:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:379:3-8: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:381:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
drivers/staging/ccree/ssi_hash.c:383:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_hash.c |   27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -313,14 +313,11 @@ fail4:
state->digest_buff_dma_addr = 0;
}
 fail3:
-   if (state->opad_digest_buff != NULL)
-   kfree(state->opad_digest_buff);
+   kfree(state->opad_digest_buff);
 fail2:
-   if (state->digest_bytes_len != NULL)
-   kfree(state->digest_bytes_len);
+   kfree(state->digest_bytes_len);
 fail1:
-   if (state->digest_buff != NULL)
-   kfree(state->digest_buff);
+kfree(state->digest_buff);
 fail_digest_result_buff:
 if (state->digest_result_buff != NULL) {
 kfree(state->digest_result_buff);
@@ -369,18 +366,12 @@ static void ssi_hash_unmap_request(struc
state->opad_digest_dma_addr = 0;
}
 
-   if (state->opad_digest_buff != NULL)
-   kfree(state->opad_digest_buff);
-   if (state->digest_bytes_len != NULL)
-   kfree(state->digest_bytes_len);
-   if (state->digest_buff != NULL)
-   kfree(state->digest_buff);
-   if (state->digest_result_buff != NULL) 
-   kfree(state->digest_result_buff);
-   if (state->buff1 != NULL) 
-   kfree(state->buff1);
-   if (state->buff0 != NULL)
-   kfree(state->buff0);
+   kfree(state->opad_digest_buff);
+   kfree(state->digest_bytes_len);
+   kfree(state->digest_buff);
+   kfree(state->digest_result_buff);
+   kfree(state->buff1);
+   kfree(state->buff0);
 }
 
 static void ssi_hash_unmap_result(struct device *dev, 

Re: [PATCH v2 2/9] staging: ccree: add ahash support

[kbuild test robot]

Hi Gilad,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.11-rc7]
[cannot apply to staging/staging-testing next-20170420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Ben-Yossef/staging-ccree-add-Arm-TrustZone-CryptoCell-REE-driver/20170420-222023


coccinelle warnings: (new ones prefixed by >>)

>> drivers/staging/ccree/ssi_hash.c:317:2-7: WARNING: NULL check before freeing 
>> functions like kfree, debugfs_remove, debugfs_remove_recursive or 
>> usb_free_urb is not needed. Maybe consider reorganizing relevant code to 
>> avoid passing NULL values.
   drivers/staging/ccree/ssi_hash.c:320:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:323:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:373:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:375:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:377:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:379:3-8: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:381:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.
   drivers/staging/ccree/ssi_hash.c:383:2-7: WARNING: NULL check before freeing 
functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb 
is not needed. Maybe consider reorganizing relevant code to avoid passing NULL 
values.

Please review and possibly fold the followup patch.

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

Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

[Eric Biggers]

Hi Stephan,

On Thu, Apr 20, 2017 at 03:27:17PM +0200, Stephan Müller wrote:
> Am Donnerstag, 20. April 2017, 07:46:31 CEST schrieb Eric Biggers:
> 
> Hi Eric,
> 
> > From: Eric Biggers 
> > 
> > The result of the Diffie-Hellman computation may be shorter than the
> > input prime number.  Only calculate the KDF over the actual result;
> > don't include additional uninitialized memory.
> 
> Thank you for catching that (and all the rest). But I think this patch is not 
> correct. If the DH operation results in a shorter value, the trailing part 
> must be set to null and the KDF calculated over the entire prime length.
> 
> Thus, if the DH result is shorter than the prime, the memory should look like 
> DH result || 0x00  || otherinfo.
> 
> Thus, instead of this patch, I would think that the kmalloc call should be 
> changed to a kzalloc.
> > 

Is this in the standard?  And is it the user-specified length of the prime
number, or the length after stripping leading zeroes?  Also, note that the
numbers are being represented in big endian format; is that required, or just
coincidental?  With big endian numbers leading zeroes go at the beginning, not
the end, otherwise their value will be changed...

By the way: do we really need this in the kernel at all, given that it's just
doing some math on data which userspace has access to?

- Eric

[PATCH] staging: ccree: fix ifnullfree.cocci warnings

[kbuild test robot]

drivers/staging/ccree/ssi_buffer_mgr.c:530:3-19: WARNING: NULL check before 
freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or 
usb_free_urb is not needed. Maybe consider reorganizing relevant code to avoid 
passing NULL values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_buffer_mgr.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -526,8 +526,7 @@ int ssi_buffer_mgr_fini(struct ssi_drvda
struct buff_mgr_handle *buff_mgr_handle = drvdata->buff_mgr_handle;
 
if (buff_mgr_handle  != NULL) {
-   if (buff_mgr_handle->mlli_buffs_pool != NULL)
-   dma_pool_destroy(buff_mgr_handle->mlli_buffs_pool);
+   dma_pool_destroy(buff_mgr_handle->mlli_buffs_pool);
kfree(drvdata->buff_mgr_handle);
drvdata->buff_mgr_handle = NULL;
 

[PATCH] staging: ccree: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

drivers/staging/ccree/ssi_driver.c:484:6-11: No need to set .owner here. The 
core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_driver.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -481,7 +481,6 @@ MODULE_DEVICE_TABLE(of, arm_cc7x_dev_of_
 static struct platform_driver cc7x_driver = {
.driver = {
   .name = "cc7xree",
-  .owner = THIS_MODULE,
 #ifdef CONFIG_OF
   .of_match_table = arm_cc7x_dev_of_match,
 #endif

[PATCH] staging: ccree: fix semicolon.cocci warnings

[kbuild test robot]

drivers/staging/ccree/ssi_request_mgr.c:623:3-4: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_request_mgr.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -620,7 +620,7 @@ static void comp_handler(unsigned long d
/* Avoid race with above clear: Test completion counter 
once more */
request_mgr_handle->axi_completed += 
CC_REG_FLD_GET(CRY_KERNEL, AXIM_MON_COMP, VALUE, 
CC_HAL_READ_REGISTER(AXIM_MON_BASE_OFFSET));
-   };
+   }

}
/* after verifing that there is nothing to do, Unmask AXI completion 
interrupt */

[PATCH] staging: ccree: fix array_size.cocci warnings

[kbuild test robot]

drivers/staging/ccree/ssi_sysfs.c:319:34-35: WARNING: Use ARRAY_SIZE
drivers/staging/ccree/ssi_sysfs.c:429:34-35: WARNING: Use ARRAY_SIZE

 Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element

Semantic patch information:
 This makes an effort to find cases where ARRAY_SIZE can be used such as
 where there is a division of sizeof the array by the sizeof its first
 element or by any indexed element or the element type. It replaces the
 division of the two sizeofs by ARRAY_SIZE.

Generated by: scripts/coccinelle/misc/array_size.cocci

CC: Gilad Ben-Yossef 
Signed-off-by: Fengguang Wu 
---

 ssi_sysfs.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/staging/ccree/ssi_sysfs.c
+++ b/drivers/staging/ccree/ssi_sysfs.c
@@ -316,7 +316,7 @@ static ssize_t ssi_sys_help_show(struct
int i=0, offset = 0;
 
offset += scnprintf(buf + offset, PAGE_SIZE - offset, "Usage:\n");
-   for ( i = 0; i < (sizeof(help_str)/sizeof(help_str[0])); i+=2) {
+   for ( i = 0; i < ARRAY_SIZE(help_str); i+=2) {
   offset += scnprintf(buf + offset, PAGE_SIZE - offset, "%s\t\t%s\n", 
help_str[i], help_str[i+1]);
}
return offset;
@@ -426,8 +426,7 @@ int ssi_sysfs_init(struct kobject *sys_d
/* Initialize top directory */
retval = sys_init_dir(_top_dir, drvdata, sys_dev_obj,
"cc_info", ssi_sys_top_level_attrs,
-   sizeof(ssi_sys_top_level_attrs) /
-   sizeof(struct kobj_attribute));
+   ARRAY_SIZE(ssi_sys_top_level_attrs));
return retval;
 }
 

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

[kbuild test robot]

Hi Gilad,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.11-rc7]
[cannot apply to staging/staging-testing next-20170420]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gilad-Ben-Yossef/staging-ccree-add-Arm-TrustZone-CryptoCell-REE-driver/20170420-222023
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_driver.c:60:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_driver.c: In function 'cc_isr':
>> drivers/staging/ccree/cc_hal.h:33:38: error: implicit declaration of 
>> function 'READ_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_READ_REGISTER(offset) READ_REGISTER(cc_base + offset)
 ^
>> drivers/staging/ccree/ssi_driver.c:120:8: note: in expansion of macro 
>> 'CC_HAL_READ_REGISTER'
 irr = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_IRR));
   ^~~~
>> drivers/staging/ccree/cc_hal.h:32:44: error: implicit declaration of 
>> function 'WRITE_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_WRITE_REGISTER(offset, val) WRITE_REGISTER(cc_base + offset, 
val)
   ^
>> drivers/staging/ccree/ssi_driver.c:129:2: note: in expansion of macro 
>> 'CC_HAL_WRITE_REGISTER'
 CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_ICR), irr);
 ^
   cc1: some warnings being treated as errors
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_sysfs.c:19:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_sysfs.c: In function 'ssi_sys_regdump_show':
>> drivers/staging/ccree/cc_hal.h:33:38: error: implicit declaration of 
>> function 'READ_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_READ_REGISTER(offset) READ_REGISTER(cc_base + offset)
 ^
>> drivers/staging/ccree/ssi_sysfs.c:291:19: note: in expansion of macro 
>> 'CC_HAL_READ_REGISTER'
 register_value = CC_HAL_READ_REGISTER(CC_REG_OFFSET(HOST_RGF, 
HOST_SIGNATURE));
  ^~~~
   cc1: some warnings being treated as errors
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_buffer_mgr.h:27,
from drivers/staging/ccree/ssi_buffer_mgr.c:28:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_request_mgr.c:27:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_request_mgr.c: In function 'request_mgr_init':
>> drivers/staging/ccree/ssi_request_mgr.c:198:29: error: implicit declaration 
>> of function 'READ_REGISTER' [-Werror=implicit-function-declaration]
 req_mgr_h->hw_queue_size = READ_REGISTER(drvdata->cc_base +
^
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_request_mgr.c:27:
   drivers/staging/ccree/ssi_request_mgr.c: In function 'comp_handler':
>> drivers/staging/ccree/cc_hal.h:32:44: error: implicit declaration of 
>> function 'WRITE_REGISTER' [-Werror=implicit-function-declaration]
#define CC_HAL_WRITE_REGISTER(offset, val) WRITE_REGISTER(cc_base + offset, 
val)
   ^
>> drivers/staging/ccree/ssi_request_mgr.c:595:3: note: in expansion of macro 
>> 'CC_HAL_WRITE_REGISTER'
  CC_HAL_WRITE_REGISTER(CC_REG_OFFSET(HOST_RGF, HOST_ICR), 
SSI_COMP_IRQ_MASK);
  ^
   cc1: some warnings being treated as errors
--
   In file included from drivers/staging/ccree/ssi_driver.h:48:0,
from drivers/staging/ccree/ssi_pm.c:24:
>> drivers/staging/ccree/cc_hal.h:29:2: error: #error Unsupported platform
#error Unsupported platform
 ^
   drivers/staging/ccree/ssi_pm.c: In function 'ssi_power_mgr_runtime_suspend':
>> drivers/staging/ccree/ssi_pm.c:46:2: error: implicit declaration of function 
>&g

[PATCH v2 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

[sean.wang]

From: Sean Wang 

This patch adds support for hardware random generator on MT7623 SoC
and should also work on other similar Mediatek SoCs. Currently,
the driver is already tested successfully with rng-tools.

Signed-off-by: Sean Wang 
Reviewed-by: PrasannaKumar Muralidharan 
---
 drivers/char/hw_random/Kconfig   |  14 
 drivers/char/hw_random/Makefile  |   1 +
 drivers/char/hw_random/mtk-rng.c | 168 +++
 3 files changed, 183 insertions(+)
 create mode 100644 drivers/char/hw_random/mtk-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 0cafe08..df5e7c2 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -423,6 +423,20 @@ config HW_RANDOM_CAVIUM
 
  If unsure, say Y.
 
+config HW_RANDOM_MTK
+   tristate "Mediatek Random Number Generator support"
+   depends on HW_RANDOM
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   default y
+   ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here. the
+ module will be called mtk-rng.
+
+ If unsure, say Y.
+
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 5f52b1e..59eacb7 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
 obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
 obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
 obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
+obj-$(CONFIG_HW_RANDOM_MTK)+= mtk-rng.o
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
new file mode 100644
index 000..df8eb54
--- /dev/null
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -0,0 +1,168 @@
+/*
+ * Driver for Mediatek Hardware Random Number Generator
+ *
+ * Copyright (C) 2017 Sean Wang 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#define MTK_RNG_DEV KBUILD_MODNAME
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USEC_POLL  2
+#define TIMEOUT_POLL   20
+
+#define RNG_CTRL   0x00
+#define RNG_EN BIT(0)
+#define RNG_READY  BIT(31)
+
+#define RNG_DATA   0x08
+
+#define to_mtk_rng(p)  container_of(p, struct mtk_rng, rng)
+
+struct mtk_rng {
+   void __iomem *base;
+   struct clk *clk;
+   struct hwrng rng;
+};
+
+static int mtk_rng_init(struct hwrng *rng)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   u32 val;
+   int err;
+
+   err = clk_prepare_enable(priv->clk);
+   if (err)
+   return err;
+
+   val = readl(priv->base + RNG_CTRL);
+   val |= RNG_EN;
+   writel(val, priv->base + RNG_CTRL);
+
+   return 0;
+}
+
+static void mtk_rng_cleanup(struct hwrng *rng)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   u32 val;
+
+   val = readl(priv->base + RNG_CTRL);
+   val &= ~RNG_EN;
+   writel(val, priv->base + RNG_CTRL);
+
+   clk_disable_unprepare(priv->clk);
+}
+
+static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   int ready;
+
+   ready = readl(priv->base + RNG_CTRL) & RNG_READY;
+   if (!ready && wait)
+   readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
+ ready & RNG_READY, USEC_POLL,
+ TIMEOUT_POLL);
+   return !!ready;
+}
+
+static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+   struct mtk_rng *priv = to_mtk_rng(rng);
+   int retval = 0;
+
+   while (max >= sizeof(u32)) {
+   if (!mtk_rng_wait_ready(rng, wait))
+   break;
+
+   *(u32 *)buf = readl(priv->base + RNG_DATA);
+   retval += sizeof(u32);
+   buf += sizeof(u32);
+   max -= sizeof(u32);
+   }
+
+   return retval || !wait ? retval : -EIO;
+}
+
+static int mtk_rng_probe(struct platform_device *pdev)
+{
+   struct resource *res;
+   int ret;
+   struct mtk_rng *priv;
+
+   

[PATCH v2 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings

[sean.wang]

From: Sean Wang 

Document the devicetree bindings for Mediatek random number
generator which could be found on MT7623 SoC or other similar
Mediatek SoCs.

Signed-off-by: Sean Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt 
b/Documentation/devicetree/bindings/rng/mtk-rng.txt
new file mode 100644
index 000..a6d62a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for Mediatek random number generator
+found in Mediatek SoC family
+
+Required properties:
+- compatible   : Should be "mediatek,mt7623-rng"
+- clocks   : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names  : Should contain "rng" entries;
+- reg  : Specifies base physical address and size of the registers
+
+Example:
+
+rng: rng@1020f000 {
+   compatible = "mediatek,mt7623-rng";
+   reg = <0 0x1020f000 0 0x1000>;
+   clocks = < CLK_INFRA_TRNG>;
+   clock-names = "rng";
+};
-- 
1.9.1

[PATCH v2 0/2] hwrng: mtk: add support for hardware random generator on MT7623 SoC

[sean.wang]

From: Sean Wang 

This patchset introduces support for Mediatek hardware random generator (RNG)
Currently, the driver is already tested successfully with rng-tools on MT7623
SoC. And it should also be workable on other similar Mediatek SoCs.

Changes since v1:
- remove unnecessary warning message
- remove mistakenly changed line
- refine macro definition with keeping one space between name and define
- remove redundant platform_get_resource() call

Sean Wang (2):
  dt-bindings: hwrng: Add Mediatek hardware random generator bindings
  hwrng: mtk: Add driver for hardware random generator on MT7623 SoC

 Documentation/devicetree/bindings/rng/mtk-rng.txt |  18 +++
 drivers/char/hw_random/Kconfig|  14 ++
 drivers/char/hw_random/Makefile   |   1 +
 drivers/char/hw_random/mtk-rng.c  | 168 ++
 4 files changed, 201 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
 create mode 100644 drivers/char/hw_random/mtk-rng.c

-- 
1.9.1

Re: [RFC PATCH v1 0/1] *** crypto: AF_ALG: add compression support ***

[abed mohammad kamaluddin]

Hi Herbert,

>> > I think we should convert ipcomp over to the new interface first
>> > in order to make sure that we don't need to change the interface
>> > which would be hard to do once we export it to user-space.
>>
>> Would it be acceptable if we export an algif interface using 
>> alg_type_compress,
>
> No we're not going to export an obsolete interface.
>

Are there any deficiencies expected in the acomp interface for use
with ipcomp? One issue mentioned earlier on the lists was that the
interface might
require tweaks for piecemeal decompression. Has this been taken up?

We identified few issues when using acomp with user-space zlib for file
compression. If the the interface is tweaked keeping those use-cases
in mind apart from the existing kernel apps (zswap/ipcomp/zram), the hardware
algorithms can be utilized using the algif framework.

Thanks
Abed



On Thu, Apr 20, 2017 at 1:30 PM, Herbert Xu  wrote:
> On Thu, Apr 20, 2017 at 12:39:58PM +0530, abed mohammad kamaluddin wrote:
>> Hi Herbert,
>>
>> > I think we should convert ipcomp over to the new interface first
>> > in order to make sure that we don't need to change the interface
>> > which would be hard to do once we export it to user-space.
>>
>> Would it be acceptable if we export an algif interface using 
>> alg_type_compress,
>> which is being used by ipcomp currently? We would like to use our zip
>> device from
>> userspace through this interface.
>
> No we're not going to export an obsolete interface.
>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 5/6] MODSIGN: Export module signature definitions.

[David Howells]

Mimi Zohar  wrote:

> On Tue, 2017-04-18 at 17:17 -0300, Thiago Jung Bauermann wrote:
> > IMA will use the module_signature format for append signatures, so export
> > the relevant definitions and factor out the code which verifies that the
> > appended signature trailer is valid.
> > 
> > Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
> > and be able to use validate_module_signature without having to depend on
> > CONFIG_MODULE_SIG.
> 
> Basically we want to generalize the concept of an appended signature.
>  Referring to it as a "module signature format" seems a bit confusing.
> 
> David, would you have a problem with changing the appended string from
> "~Module signature appended~\n" to something more generic?

Conceptually, no.  Is it possible that doing so could break someone's module
that they load on multiple versions of the kernel?  Say a module that only
exports things and doesn't use anything from the core or any other module.

Also, it needs to reasonably long and distinct enough to prevent a false
positive match.

David

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

[Greg Kroah-Hartman]

On Thu, Apr 20, 2017 at 04:40:56PM +0300, Gilad Ben-Yossef wrote:
> On Thu, Apr 20, 2017 at 4:33 PM, Greg Kroah-Hartman
>  wrote:
> > On Thu, Apr 20, 2017 at 04:12:55PM +0300, Gilad Ben-Yossef wrote:
> >> +++ b/drivers/staging/ccree/bsp.h
> >> @@ -0,0 +1,21 @@
> >> +/*
> >> + * Copyright (C) 2012-2016 ARM Limited or its affiliates.
> >> + *
> >> + * 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.
> >
> > Oh, I have to ask, do you really mean "any later version" here and
> > elsewhere?
> >
> > If so, then your MODULE_LICENSE() marking is wrong, please fix that up,
> > or fix up the license text, I can't take incompatible ones without
> > getting angry emails from legal people sent to me...
> >
> 
> Thanks for noticing this.
> 
> The copyright + license notice is a boilerplate I got from the powers
> that be here.
> 
> I'll consult internally what is the proper action. I don't want to
> make legal mad either... :-)

Ok, I'll drop this patch series then, and wait for an updated one with
this fixed up.

thanks,

greg k-h

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

[Gilad Ben-Yossef]

On Thu, Apr 20, 2017 at 4:33 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Apr 20, 2017 at 04:12:55PM +0300, Gilad Ben-Yossef wrote:
>> +++ b/drivers/staging/ccree/bsp.h
>> @@ -0,0 +1,21 @@
>> +/*
>> + * Copyright (C) 2012-2016 ARM Limited or its affiliates.
>> + *
>> + * 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.
>
> Oh, I have to ask, do you really mean "any later version" here and
> elsewhere?
>
> If so, then your MODULE_LICENSE() marking is wrong, please fix that up,
> or fix up the license text, I can't take incompatible ones without
> getting angry emails from legal people sent to me...
>

Thanks for noticing this.

The copyright + license notice is a boilerplate I got from the powers
that be here.

I'll consult internally what is the proper action. I don't want to
make legal mad either... :-)


Thanks again,

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH v2 6/9] staging: ccree: add FIPS support

[Stephan Müller]

Am Donnerstag, 20. April 2017, 15:13:00 CEST schrieb Gilad Ben-Yossef:

Hi Gilad,

> +/* The function verifies that tdes keys are not weak.*/
> +static int ssi_fips_verify_3des_keys(const u8 *key, unsigned int keylen)
> +{
> +#ifdef CCREE_FIPS_SUPPORT
> +tdes_keys_t *tdes_key = (tdes_keys_t*)key;
> +
> + /* verify key1 != key2 and key3 != key2*/

I do not think that this check is necessary. There is no FIPS requirement or 
IG that mandates this (unlike the XTS key check).

If there would be such requirement, we would need a common service function 
for all TDES implementations

> +if (unlikely( (memcmp((u8*)tdes_key->key1, (u8*)tdes_key->key2,
> sizeof(tdes_key->key1)) == 0) || +  
> (memcmp((u8*)tdes_key->key3,
> (u8*)tdes_key->key2, sizeof(tdes_key->key3)) == 0) )) { +   
> return -ENOEXEC;
> +}
> +#endif /* CCREE_FIPS_SUPPORT */
> +
> +return 0;
> +}
> +
> +/* The function verifies that xts keys are not weak.*/
> +static int ssi_fips_verify_xts_keys(const u8 *key, unsigned int keylen)
> +{
> +#ifdef CCREE_FIPS_SUPPORT
> +/* Weak key is define as key that its first half (128/256 lsb)
> equals its second half (128/256 msb) */ +int singleKeySize = keylen
> >> 1;
> +
> + if (unlikely(memcmp(key, [singleKeySize], singleKeySize) == 0)) {
> + return -ENOEXEC;

Use xts_check_key.

> +The test vectors were taken from:
> +
> +* AES
> +NIST Special Publication 800-38A 2001 Edition
> +Recommendation for Block Cipher Modes of Operation
> +http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
> +Appendix F: Example Vectors for Modes of Operation of the AES
> +
> +* AES CTS
> +Advanced Encryption Standard (AES) Encryption for Kerberos 5
> +February 2005
> +https://tools.ietf.org/html/rfc3962#appendix-B
> +B.  Sample Test Vectors
> +
> +* AES XTS
> +http://csrc.nist.gov/groups/STM/cavp/#08
> +http://csrc.nist.gov/groups/STM/cavp/documents/aes/XTSTestVectors.zip
> +
> +* AES CMAC
> +http://csrc.nist.gov/groups/STM/cavp/index.html#07
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/cmactestvectors.zip
> +
> +* AES-CCM
> +http://csrc.nist.gov/groups/STM/cavp/#07
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip
> +
> +* AES-GCM
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/gcmtestvectors.zip
> +
> +* Triple-DES
> +NIST Special Publication 800-67 January 2012
> +Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher
> +http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf
> +APPENDIX B: EXAMPLE OF TDEA FORWARD AND INVERSE CIPHER OPERATIONS +and
> +http://csrc.nist.gov/groups/STM/cavp/#01
> +http://csrc.nist.gov/groups/STM/cavp/documents/des/tdesmct_intermediate.zip
> +
> +* HASH
> +http://csrc.nist.gov/groups/STM/cavp/#03
> +http://csrc.nist.gov/groups/STM/cavp/documents/shs/shabytetestvectors.zip
> +
> +* HMAC
> +http://csrc.nist.gov/groups/STM/cavp/#07
> +http://csrc.nist.gov/groups/STM/cavp/documents/mac/hmactestvectors.zip
> +
> +*/

Is this test vector business really needed? Why do you think that testmgr.c is 
not sufficient? Other successful FIPS validations of the kernel crypto API 
managed without such special code.

Also, your entire API seems to implement the approach that if there is a self 
test error, you disable the cipher functions, but leave the rest in-tact. The 
standard kernel crypto API handling logic is to simply panic the kernel. Is it 
really necessary to implement a special case for your driver?


Ciao
Stephan

Re: [PATCH v2 0/9] staging: ccree: add Arm TrustZone CryptoCell REE driver

[Gilad Ben-Yossef]

On Thu, Apr 20, 2017 at 4:30 PM, Greg Kroah-Hartman
 wrote:
> On Thu, Apr 20, 2017 at 04:12:54PM +0300, Gilad Ben-Yossef wrote:
>> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
>> accelerators. It is supported by a long lived series of out of tree
>> drivers, which I am now in the process of unifying and upstreaming.
>> This is the first drop, supporting the new CryptoCell 712 REE.
>>
>> The code still needs some cleanup before maturing to a proper
>> upstream driver, which I am in the process of doing. However,
>> as discussion of some of the capabilities of the hardware and
>> its application to some dm-crypt and dm-verity features recently
>> took place I though it is better to do this in the open via the
>> staging tree.
>>
>> A Git repository based off of Linux 4.11-rc7 is also available at
>> https://github.com/gby/linux.git branch ccree_v2 for those inclined.
>
> If you want this in staging, I'll be glad to take it, but note then you
> can't work off of an external repo, as syncing the two is almost
> impossible and more work than you want to go through.

Once it's in the staging tree I don't need a separate repo. It was only useful
so long as I did not have an upstream tree to point people to.
>
> So, as long as this builds properly, want me to queue these up in my
> tree?

Yes, please.

Thanks,
Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH v2 1/9] staging: ccree: introduce CryptoCell HW driver

[Greg Kroah-Hartman]

On Thu, Apr 20, 2017 at 04:12:55PM +0300, Gilad Ben-Yossef wrote:
> +++ b/drivers/staging/ccree/bsp.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (C) 2012-2016 ARM Limited or its affiliates.
> + * 
> + * 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.

Oh, I have to ask, do you really mean "any later version" here and
elsewhere?

If so, then your MODULE_LICENSE() marking is wrong, please fix that up,
or fix up the license text, I can't take incompatible ones without
getting angry emails from legal people sent to me...

thanks,

greg k-h

Re: [PATCH v2 0/9] staging: ccree: add Arm TrustZone CryptoCell REE driver

[Greg Kroah-Hartman]

On Thu, Apr 20, 2017 at 04:12:54PM +0300, Gilad Ben-Yossef wrote:
> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware
> accelerators. It is supported by a long lived series of out of tree
> drivers, which I am now in the process of unifying and upstreaming.
> This is the first drop, supporting the new CryptoCell 712 REE.
> 
> The code still needs some cleanup before maturing to a proper
> upstream driver, which I am in the process of doing. However,
> as discussion of some of the capabilities of the hardware and
> its application to some dm-crypt and dm-verity features recently
> took place I though it is better to do this in the open via the
> staging tree.
> 
> A Git repository based off of Linux 4.11-rc7 is also available at
> https://github.com/gby/linux.git branch ccree_v2 for those inclined.

If you want this in staging, I'll be glad to take it, but note then you
can't work off of an external repo, as syncing the two is almost
impossible and more work than you want to go through.

So, as long as this builds properly, want me to queue these up in my
tree?

thanks,

greg k-h

Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

[Stephan Müller]

Am Donnerstag, 20. April 2017, 07:46:31 CEST schrieb Eric Biggers:

Hi Eric,

> From: Eric Biggers 
> 
> The result of the Diffie-Hellman computation may be shorter than the
> input prime number.  Only calculate the KDF over the actual result;
> don't include additional uninitialized memory.

Thank you for catching that (and all the rest). But I think this patch is not 
correct. If the DH operation results in a shorter value, the trailing part 
must be set to null and the KDF calculated over the entire prime length.

Thus, if the DH result is shorter than the prime, the memory should look like 
DH result || 0x00  || otherinfo.

Thus, instead of this patch, I would think that the kmalloc call should be 
changed to a kzalloc.
> 
> Signed-off-by: Eric Biggers 
> ---
>  security/keys/dh.c | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/security/keys/dh.c b/security/keys/dh.c
> index 1c1cac677041..a3a8607107f5 100644
> --- a/security/keys/dh.c
> +++ b/security/keys/dh.c
> @@ -313,17 +313,6 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user
> *params, goto error4;
>   }
> 
> - /*
> -  * Concatenate SP800-56A otherinfo past DH shared secret -- the
> -  * input to the KDF is (DH shared secret || otherinfo)
> -  */
> - if (kdfcopy &&
> - copy_from_user(kbuf + resultlen, kdfcopy->otherinfo,
> -kdfcopy->otherinfolen) != 0) {
> - ret = -EFAULT;
> - goto error5;
> - }
> -
>   ret = do_dh(result, base, private, prime);
>   if (ret)
>   goto error5;
> @@ -333,8 +322,17 @@ long __keyctl_dh_compute(struct keyctl_dh_params __user
> *params, goto error5;
> 
>   if (kdfcopy) {
> + /*
> +  * Concatenate SP800-56A otherinfo past DH shared secret -- the
> +  * input to the KDF is (DH shared secret || otherinfo)
> +  */
> + if (copy_from_user(kbuf + nbytes, kdfcopy->otherinfo,
> +kdfcopy->otherinfolen) != 0) {
> + ret = -EFAULT;
> + goto error5;
> + }
>   ret = keyctl_dh_compute_kdf(sdesc, buffer, buflen, kbuf,
> - resultlen + kdfcopy->otherinfolen);
> + nbytes + kdfcopy->otherinfolen);
>   } else {
>   ret = nbytes;
>   if (copy_to_user(buffer, kbuf, nbytes) != 0)



Ciao
Stephan

[PATCH v2 2/9] staging: ccree: add ahash support

[Gilad Ben-Yossef]

Add CryptoCell async. hash and HMAC support.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig  |6 +
 drivers/staging/ccree/Makefile |2 +-
 drivers/staging/ccree/cc_crypto_ctx.h  |   22 +
 drivers/staging/ccree/hash_defs.h  |   78 +
 drivers/staging/ccree/ssi_buffer_mgr.c |  311 +++-
 drivers/staging/ccree/ssi_buffer_mgr.h |6 +
 drivers/staging/ccree/ssi_driver.c |   11 +-
 drivers/staging/ccree/ssi_driver.h |4 +-
 drivers/staging/ccree/ssi_hash.c   | 2732 
 drivers/staging/ccree/ssi_hash.h   |  101 ++
 drivers/staging/ccree/ssi_pm.c |4 +
 11 files changed, 3263 insertions(+), 14 deletions(-)
 create mode 100644 drivers/staging/ccree/hash_defs.h
 create mode 100644 drivers/staging/ccree/ssi_hash.c
 create mode 100644 drivers/staging/ccree/ssi_hash.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 0f723d7..a528a99 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -2,6 +2,12 @@ config CRYPTO_DEV_CCREE
tristate "Support for ARM TrustZone CryptoCell C7XX family of Crypto 
accelerators"
depends on CRYPTO_HW && OF && HAS_DMA
default n
+   select CRYPTO_HASH
+   select CRYPTO_SHA1
+   select CRYPTO_MD5
+   select CRYPTO_SHA256
+   select CRYPTO_SHA512
+   select CRYPTO_HMAC
help
  Say 'Y' to enable a driver for the Arm TrustZone CryptoCell 
  C7xx. Currently only the CryptoCell 712 REE is supported.
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 972af69..f94e225 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 8b8aea2..fedf259 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -220,6 +220,28 @@ struct drv_ctx_generic {
 } __attribute__((__may_alias__));
 
 
+struct drv_ctx_hash {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_HASH */
+   enum drv_hash_mode mode;
+   uint8_t digest[CC_DIGEST_SIZE_MAX];
+   /* reserve to end of allocated context size */
+   uint8_t reserved[CC_CTX_SIZE - 2 * sizeof(uint32_t) -
+   CC_DIGEST_SIZE_MAX];
+};
+
+/*  drv_ctx_hmac should have the same structure as drv_ctx_hash except
+   k0, k0_size fields */
+struct drv_ctx_hmac {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_HMAC */
+   enum drv_hash_mode mode;
+   uint8_t digest[CC_DIGEST_SIZE_MAX];
+   uint32_t k0[CC_HMAC_BLOCK_SIZE_MAX/sizeof(uint32_t)];
+   uint32_t k0_size;
+   /* reserve to end of allocated context size */
+   uint8_t reserved[CC_CTX_SIZE - 3 * sizeof(uint32_t) -
+   CC_DIGEST_SIZE_MAX - CC_HMAC_BLOCK_SIZE_MAX];
+};
+
 /***/
 /* MESSAGE BASED CONTEXTS **/
 /***/
diff --git a/drivers/staging/ccree/hash_defs.h 
b/drivers/staging/ccree/hash_defs.h
new file mode 100644
index 000..0cd6909
--- /dev/null
+++ b/drivers/staging/ccree/hash_defs.h
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2012-2016 ARM Limited or its affiliates.
+ * 
+ * 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.
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#ifndef  _HASH_DEFS_H__
+#define  _HASH_DEFS_H__
+
+#include "cc_crypto_ctx.h"
+
+/* this files provides definitions required for hash engine drivers */
+#ifndef CC_CONFIG_HASH_SHA_512_SUPPORTED
+#define SEP_HASH_LENGTH_WORDS  2
+#else
+#define SEP_HASH_LENGTH_WORDS  4
+#endif
+
+#ifdef BIG__ENDIAN
+#define OPAD_CURRENT_LENGTH 0x4000, 0x , 0x, 0x
+#define HASH_LARVAL_MD5  0x76543210, 0xFEDCBA98, 0x89ABCDEF, 0x01234567
+#define HASH_LARVAL_SHA1 0xF0E1D2C3, 0x76543210, 0xFEDCBA98, 0x89ABCDEF, 
0x01234567
+#define 

[PATCH v2 9/9] MAINTAINERS: add Gilad BY as ccree maintainer

[Gilad Ben-Yossef]

I work for Arm on maintaining the TrustZone CryptoCell driver.

Signed-off-by: Gilad Ben-Yossef 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 676c139..f21caa1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3066,6 +3066,13 @@ F:   drivers/net/ieee802154/cc2520.c
 F: include/linux/spi/cc2520.h
 F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
 
+CCREE ARM TRUSTZONE CRYPTOCELL 700 REE DRIVER
+M: Gilad Ben-Yossef 
+L: linux-crypto@vger.kernel.org
+S: Supported
+F: drivers/staging/ccree/
+W: 
https://developer.arm.com/products/system-ip/trustzone-cryptocell/cryptocell-700-family
+
 CEC DRIVER
 M: Hans Verkuil 
 L: linux-me...@vger.kernel.org
-- 
2.1.4

[PATCH v2 3/9] staging: ccree: add skcipher support

[Gilad Ben-Yossef]

Add CryptoCell skcipher support

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig  |8 +
 drivers/staging/ccree/Makefile |2 +-
 drivers/staging/ccree/cc_crypto_ctx.h  |   21 +
 drivers/staging/ccree/ssi_buffer_mgr.c |  147 
 drivers/staging/ccree/ssi_buffer_mgr.h |   16 +
 drivers/staging/ccree/ssi_cipher.c | 1440 
 drivers/staging/ccree/ssi_cipher.h |   88 ++
 drivers/staging/ccree/ssi_driver.c |   14 +
 drivers/staging/ccree/ssi_driver.h |   30 +
 9 files changed, 1765 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/ccree/ssi_cipher.c
 create mode 100644 drivers/staging/ccree/ssi_cipher.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index a528a99..3fff040 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -3,11 +3,19 @@ config CRYPTO_DEV_CCREE
depends on CRYPTO_HW && OF && HAS_DMA
default n
select CRYPTO_HASH
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_DES
+   select CRYPTO_AUTHENC
select CRYPTO_SHA1
select CRYPTO_MD5
select CRYPTO_SHA256
select CRYPTO_SHA512
select CRYPTO_HMAC
+   select CRYPTO_AES
+   select CRYPTO_CBC
+   select CRYPTO_ECB
+   select CRYPTO_CTR
+   select CRYPTO_XTS
help
  Say 'Y' to enable a driver for the Arm TrustZone CryptoCell 
  C7xx. Currently only the CryptoCell 712 REE is supported.
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index f94e225..21a80d5 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index fedf259..f198779 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -242,6 +242,27 @@ struct drv_ctx_hmac {
CC_DIGEST_SIZE_MAX - CC_HMAC_BLOCK_SIZE_MAX];
 };
 
+struct drv_ctx_cipher {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_AES */
+   enum drv_cipher_mode mode;
+   enum drv_crypto_direction direction;
+   enum drv_crypto_key_type crypto_key_type;
+   enum drv_crypto_padding_type padding_type;
+   uint32_t key_size; /* numeric value in bytes   */
+   uint32_t data_unit_size; /* required for XTS */
+   /* block_state is the AES engine block state.
+   *  It is used by the host to pass IV or counter at initialization.
+   *  It is used by SeP for intermediate block chaining state and for
+   *  returning MAC algorithms results.   */
+   uint8_t block_state[CC_AES_BLOCK_SIZE];
+   uint8_t key[CC_AES_KEY_SIZE_MAX];
+   uint8_t xex_key[CC_AES_KEY_SIZE_MAX];
+   /* reserve to end of allocated context size */
+   uint32_t reserved[CC_DRV_CTX_SIZE_WORDS - 7 -
+   CC_AES_BLOCK_SIZE/sizeof(uint32_t) - 2 *
+   (CC_AES_KEY_SIZE_MAX/sizeof(uint32_t))];
+};
+
 /***/
 /* MESSAGE BASED CONTEXTS **/
 /***/
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 5144eaa..a0fafa9 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -28,6 +28,7 @@
 
 #include "ssi_buffer_mgr.h"
 #include "cc_lli_defs.h"
+#include "ssi_cipher.h"
 #include "ssi_hash.h"
 
 #define LLI_MAX_NUM_OF_DATA_ENTRIES 128
@@ -517,6 +518,152 @@ static inline int ssi_ahash_handle_curr_buf(struct device 
*dev,
return 0;
 }
 
+void ssi_buffer_mgr_unmap_blkcipher_request(
+   struct device *dev,
+   void *ctx,
+   unsigned int ivsize,
+   struct scatterlist *src,
+   struct scatterlist *dst)
+{
+   struct blkcipher_req_ctx *req_ctx = (struct blkcipher_req_ctx *)ctx;
+
+   if (likely(req_ctx->gen_ctx.iv_dma_addr != 0)) {
+   SSI_LOG_DEBUG("Unmapped iv: iv_dma_addr=0x%llX iv_size=%u\n", 
+   (unsigned long long)req_ctx->gen_ctx.iv_dma_addr,
+   ivsize);
+   SSI_RESTORE_DMA_ADDR_TO_48BIT(req_ctx->gen_ctx.iv_dma_addr);
+   dma_unmap_single(dev, req_ctx->gen_ctx.iv_dma_addr, 
+ivsize, 
+DMA_TO_DEVICE);
+   }
+   /* Release pool */
+   if (req_ctx->dma_buf_type == SSI_DMA_BUF_MLLI) {
+   

[PATCH v2 5/9] staging: ccree: add AEAD support

[Gilad Ben-Yossef]

Add CryptoCell AEAD support

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig  |1 +
 drivers/staging/ccree/Makefile |2 +-
 drivers/staging/ccree/cc_crypto_ctx.h  |   21 +
 drivers/staging/ccree/ssi_aead.c   | 2826 
 drivers/staging/ccree/ssi_aead.h   |  120 ++
 drivers/staging/ccree/ssi_buffer_mgr.c |  899 ++
 drivers/staging/ccree/ssi_buffer_mgr.h |4 +
 drivers/staging/ccree/ssi_driver.c |   11 +
 drivers/staging/ccree/ssi_driver.h |4 +
 9 files changed, 3887 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/ccree/ssi_aead.c
 create mode 100644 drivers/staging/ccree/ssi_aead.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 3fff040..2d11223 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -5,6 +5,7 @@ config CRYPTO_DEV_CCREE
select CRYPTO_HASH
select CRYPTO_BLKCIPHER
select CRYPTO_DES
+   select CRYPTO_AEAD
select CRYPTO_AUTHENC
select CRYPTO_SHA1
select CRYPTO_MD5
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 89afe9a..b9285c0 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index f198779..743461f 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -263,6 +263,27 @@ struct drv_ctx_cipher {
(CC_AES_KEY_SIZE_MAX/sizeof(uint32_t))];
 };
 
+/* authentication and encryption with associated data class */
+struct drv_ctx_aead {
+   enum drv_crypto_alg alg; /* DRV_CRYPTO_ALG_AES */
+   enum drv_cipher_mode mode;
+   enum drv_crypto_direction direction;
+   uint32_t key_size; /* numeric value in bytes   */
+   uint32_t nonce_size; /* nonce size (octets) */
+   uint32_t header_size; /* finit additional data size (octets) */
+   uint32_t text_size; /* finit text data size (octets) */
+   uint32_t tag_size; /* mac size, element of {4, 6, 8, 10, 12, 14, 16} */
+   /* block_state1/2 is the AES engine block state */
+   uint8_t block_state[CC_AES_BLOCK_SIZE];
+   uint8_t mac_state[CC_AES_BLOCK_SIZE]; /* MAC result */
+   uint8_t nonce[CC_AES_BLOCK_SIZE]; /* nonce buffer */
+   uint8_t key[CC_AES_KEY_SIZE_MAX];
+   /* reserve to end of allocated context size */
+   uint32_t reserved[CC_DRV_CTX_SIZE_WORDS - 8 -
+   3 * (CC_AES_BLOCK_SIZE/sizeof(uint32_t)) -
+   CC_AES_KEY_SIZE_MAX/sizeof(uint32_t)];
+};
+
 /***/
 /* MESSAGE BASED CONTEXTS **/
 /***/
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
new file mode 100644
index 000..1d2890e
--- /dev/null
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -0,0 +1,2826 @@
+/*
+ * Copyright (C) 2012-2016 ARM Limited or its affiliates.
+ * 
+ * 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.
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ssi_config.h"
+#include "ssi_driver.h"
+#include "ssi_buffer_mgr.h"
+#include "ssi_aead.h"
+#include "ssi_request_mgr.h"
+#include "ssi_hash.h"
+#include "ssi_sysfs.h"
+#include "ssi_sram_mgr.h"
+
+#define template_aead  template_u.aead
+
+#define MAX_AEAD_SETKEY_SEQ 12
+#define MAX_AEAD_PROCESS_SEQ 23
+
+#define MAX_HMAC_DIGEST_SIZE (SHA256_DIGEST_SIZE)
+#define MAX_HMAC_BLOCK_SIZE (SHA256_BLOCK_SIZE)
+
+#define AES_CCM_RFC4309_NONCE_SIZE 3
+#define MAX_NONCE_SIZE CTR_RFC3686_NONCE_SIZE
+
+
+/* Value of each ICV_CMP byte (of 8) in case of success */
+#define 

[PATCH v2 6/9] staging: ccree: add FIPS support

[Gilad Ben-Yossef]

Add FIPS mode support to CryptoCell driver

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig   |9 +
 drivers/staging/ccree/Makefile  |1 +
 drivers/staging/ccree/ssi_aead.c|6 +
 drivers/staging/ccree/ssi_cipher.c  |   52 +
 drivers/staging/ccree/ssi_driver.c  |   19 +-
 drivers/staging/ccree/ssi_driver.h  |2 +
 drivers/staging/ccree/ssi_fips.c|   65 ++
 drivers/staging/ccree/ssi_fips.h|   70 ++
 drivers/staging/ccree/ssi_fips_data.h   |  315 ++
 drivers/staging/ccree/ssi_fips_ext.c|   96 ++
 drivers/staging/ccree/ssi_fips_ll.c | 1681 +++
 drivers/staging/ccree/ssi_fips_local.c  |  369 +++
 drivers/staging/ccree/ssi_fips_local.h  |   77 ++
 drivers/staging/ccree/ssi_hash.c|   21 +-
 drivers/staging/ccree/ssi_request_mgr.c |2 +
 15 files changed, 2783 insertions(+), 2 deletions(-)
 create mode 100644 drivers/staging/ccree/ssi_fips.c
 create mode 100644 drivers/staging/ccree/ssi_fips.h
 create mode 100644 drivers/staging/ccree/ssi_fips_data.h
 create mode 100644 drivers/staging/ccree/ssi_fips_ext.c
 create mode 100644 drivers/staging/ccree/ssi_fips_ll.c
 create mode 100644 drivers/staging/ccree/ssi_fips_local.c
 create mode 100644 drivers/staging/ccree/ssi_fips_local.h

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 2d11223..ae62704 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -24,6 +24,15 @@ config CRYPTO_DEV_CCREE
  cryptographic operations on the system REE.
  If unsure say Y.
 
+config CCREE_FIPS_SUPPORT
+   bool "Turn on CryptoCell 7XX REE FIPS mode support"
+   depends on CRYPTO_DEV_CCREE
+   default n
+   help
+ Say 'Y' to enable support for FIPS compliant mode by the
+ CCREE driver.
+ If unsure say N.
+
 config CCREE_DISABLE_COHERENT_DMA_OPS
bool "Disable Coherent DMA operations for the CCREE driver"
depends on CRYPTO_DEV_CCREE
diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index b9285c0..44f3e3e 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
 ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
+ccree-$(CCREE_FIPS_SUPPORT) += ssi_fips.o ssi_fips_ll.o ssi_fips_ext.o 
ssi_fips_local.o
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 1d2890e..3ab958b 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -36,6 +36,7 @@
 #include "ssi_hash.h"
 #include "ssi_sysfs.h"
 #include "ssi_sram_mgr.h"
+#include "ssi_fips_local.h"
 
 #define template_aead  template_u.aead
 
@@ -153,6 +154,8 @@ static int ssi_aead_init(struct crypto_aead *tfm)
container_of(alg, struct ssi_crypto_alg, aead_alg);
SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx, 
crypto_tfm_alg_name(&(tfm->base)));
 
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
+
/* Initialize modes in instance */
ctx->cipher_mode = ssi_alg->cipher_mode;
ctx->flow_mode = ssi_alg->flow_mode;
@@ -572,6 +575,7 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key, 
unsigned int keylen)
SSI_LOG_DEBUG("Setting key in context @%p for %s. key=%p keylen=%u\n",
ctx, crypto_tfm_alg_name(crypto_aead_tfm(tfm)), key, keylen);
 
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
/* STAT_PHASE_0: Init and sanity checks */
START_CYCLE_COUNT();
 
@@ -699,6 +703,7 @@ static int ssi_aead_setauthsize(
 {
struct ssi_aead_ctx *ctx = crypto_aead_ctx(authenc);

+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
/* Unsupported auth. sizes */
if ((authsize == 0) ||
(authsize >crypto_aead_maxauthsize(authenc))) {
@@ -2006,6 +2011,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
SSI_LOG_DEBUG("%s context=%p req=%p iv=%p src=%p src_ofs=%d dst=%p 
dst_ofs=%d cryptolen=%d\n",
((direct==DRV_CRYPTO_DIRECTION_ENCRYPT)?"Encrypt":"Decrypt"), 
ctx, req, req->iv,
sg_virt(req->src), req->src->offset, sg_virt(req->dst), 
req->dst->offset, req->cryptlen);
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
/* STAT_PHASE_0: Init and sanity checks */
START_CYCLE_COUNT();
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 2e4ce90..e8a4071 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -31,6 +31,7 @@
 #include "ssi_cipher.h"
 #include "ssi_request_mgr.h"
 #include "ssi_sysfs.h"
+#include "ssi_fips_local.h"
 
 #define MAX_ABLKCIPHER_SEQ_LEN 6
 
@@ -191,6 +192,7 @@ static int ssi_blkcipher_init(struct crypto_tfm *tfm)

[PATCH v2 7/9] staging: ccree: add TODO list

[Gilad Ben-Yossef]

Add TODO list for moving out of staging tree for ccree crypto driver

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/TODO | 28 
 1 file changed, 28 insertions(+)
 create mode 100644 drivers/staging/ccree/TODO

diff --git a/drivers/staging/ccree/TODO b/drivers/staging/ccree/TODO
new file mode 100644
index 000..3f1d61d
--- /dev/null
+++ b/drivers/staging/ccree/TODO
@@ -0,0 +1,28 @@
+
+
+*
+*  *
+* Arm Trust Zone CryptoCell REE Linux driver upstreaming TODO items*
+*  *
+*
+
+ccree specific items
+a.k.a stuff fixing for this driver to move out of staging
+~
+
+1.  Move to using Crypto Engine to handle backlog queueing.
+2.  Remove synchronous algorithm support leftovers.
+3.  Separate platform specific code for FIPS and power management into 
separate platform modules.
+4.  Drop legacy kernel support code.
+5.  Move most (all?) #ifdef CONFIG into inline functions.
+6.  Remove all unused definitions.
+7.  Re-factor to accomediate newer/older HW revisions besides the 712.
+8.  Handle the many checkpatch errors.
+9.  Implement ahash import/export correctly.
+10. Go through a proper review of DT bindings and sysfs ABI
+
+Kernel infrastructure items
+a.k.a stuff we either neither need to fix in the kernel or understand what 
we're doing wrong
+
+1. ahash import/export context has a PAGE_SIZE/8 size limit.  We need more.
+2. Crypto Engine seems to be built for HW with hardware queue depth of 1, we 
have 600++.
-- 
2.1.4

[PATCH v2 4/9] staging: ccree: add IV generation support

[Gilad Ben-Yossef]

Add CryptoCell IV hardware generation support.

This patch adds the needed support to drive the HW but does not expose
the ability via the kernel crypto API yet.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Makefile  |   2 +-
 drivers/staging/ccree/ssi_buffer_mgr.c  |   2 +
 drivers/staging/ccree/ssi_cipher.c  |  11 ++
 drivers/staging/ccree/ssi_cipher.h  |   1 +
 drivers/staging/ccree/ssi_driver.c  |   9 +
 drivers/staging/ccree/ssi_driver.h  |   7 +
 drivers/staging/ccree/ssi_ivgen.c   | 301 
 drivers/staging/ccree/ssi_ivgen.h   |  72 
 drivers/staging/ccree/ssi_pm.c  |   2 +
 drivers/staging/ccree/ssi_request_mgr.c |  33 +++-
 10 files changed, 438 insertions(+), 2 deletions(-)
 create mode 100644 drivers/staging/ccree/ssi_ivgen.c
 create mode 100644 drivers/staging/ccree/ssi_ivgen.h

diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 21a80d5..89afe9a 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,2 +1,2 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o ssi_pm_ext.o
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index a0fafa9..6a9c964 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -534,6 +534,7 @@ void ssi_buffer_mgr_unmap_blkcipher_request(
SSI_RESTORE_DMA_ADDR_TO_48BIT(req_ctx->gen_ctx.iv_dma_addr);
dma_unmap_single(dev, req_ctx->gen_ctx.iv_dma_addr, 
 ivsize, 
+req_ctx->is_giv ? DMA_BIDIRECTIONAL :
 DMA_TO_DEVICE);
}
/* Release pool */
@@ -587,6 +588,7 @@ int ssi_buffer_mgr_map_blkcipher_request(
req_ctx->gen_ctx.iv_dma_addr = 
dma_map_single(dev, (void *)info, 
   ivsize, 
+  req_ctx->is_giv ? DMA_BIDIRECTIONAL:
   DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, 
req_ctx->gen_ctx.iv_dma_addr))) {
diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 01467e8..2e4ce90 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -819,6 +819,13 @@ static int ssi_blkcipher_process(
  areq,
  desc, _len);
 
+   /* do we need to generate IV? */
+   if (req_ctx->is_giv == true) {
+   ssi_req.ivgen_dma_addr[0] = req_ctx->gen_ctx.iv_dma_addr;
+   ssi_req.ivgen_dma_addr_len = 1;
+   /* set the IV size (8/16 B long)*/
+   ssi_req.ivgen_size = ivsize;
+   }
END_CYCLE_COUNT(ssi_req.op_type, STAT_PHASE_2);
 
/* STAT_PHASE_3: Lock HW and push sequence */
@@ -901,6 +908,7 @@ static int ssi_sblkcipher_encrypt(struct blkcipher_desc 
*desc,
unsigned int ivsize = crypto_blkcipher_ivsize(blk_tfm);
 
req_ctx->backup_info = desc->info;
+   req_ctx->is_giv = false;
 
return ssi_blkcipher_process(tfm, req_ctx, dst, src, nbytes, 
desc->info, ivsize, NULL, DRV_CRYPTO_DIRECTION_ENCRYPT);
 }
@@ -916,6 +924,7 @@ static int ssi_sblkcipher_decrypt(struct blkcipher_desc 
*desc,
unsigned int ivsize = crypto_blkcipher_ivsize(blk_tfm);
 
req_ctx->backup_info = desc->info;
+   req_ctx->is_giv = false;
 
return ssi_blkcipher_process(tfm, req_ctx, dst, src, nbytes, 
desc->info, ivsize, NULL, DRV_CRYPTO_DIRECTION_DECRYPT);
 }
@@ -948,6 +957,7 @@ static int ssi_ablkcipher_encrypt(struct ablkcipher_request 
*req)
unsigned int ivsize = crypto_ablkcipher_ivsize(ablk_tfm);
 
req_ctx->backup_info = req->info;
+   req_ctx->is_giv = false;
 
return ssi_blkcipher_process(tfm, req_ctx, req->dst, req->src, 
req->nbytes, req->info, ivsize, (void *)req, DRV_CRYPTO_DIRECTION_ENCRYPT);
 }
@@ -960,6 +970,7 @@ static int ssi_ablkcipher_decrypt(struct ablkcipher_request 
*req)
unsigned int ivsize = crypto_ablkcipher_ivsize(ablk_tfm);
 
req_ctx->backup_info = req->info;
+   req_ctx->is_giv = false;
return ssi_blkcipher_process(tfm, req_ctx, req->dst, req->src, 
req->nbytes, req->info, ivsize, (void *)req, DRV_CRYPTO_DIRECTION_DECRYPT);
 }
 
diff --git a/drivers/staging/ccree/ssi_cipher.h 
b/drivers/staging/ccree/ssi_cipher.h
index 511800f1..d1a98f9 100644
--- a/drivers/staging/ccree/ssi_cipher.h
+++ b/drivers/staging/ccree/ssi_cipher.h
@@ -45,6 +45,7 @@ struct 

[PATCH v2 8/9] staging: ccree: add DT bindings for Arm CryptoCell

[Gilad Ben-Yossef]

This adds DT bindings for the Arm TrustZone CryptoCell cryptographic
accelerator IP.

Signed-off-by: Gilad Ben-Yossef 
---
 .../devicetree/bindings/crypto/arm-cryptocell.txt  | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 
drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt

diff --git 
a/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
 
b/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
new file mode 100644
index 000..2ea6517
--- /dev/null
+++ 
b/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
@@ -0,0 +1,27 @@
+Arm TrustZone CryptoCell cryptographic accelerators
+
+Required properties:
+- compatible: must be "arm,cryptocell-712-ree".
+- reg: shall contain base register location and length.
+   Typically length is 0x1.
+- interrupts: shall contain the interrupt for the device.
+
+Optional properties:
+- interrupt-parent: can designate the interrupt controller the
+   device interrupt is connected to, if needed.
+- clocks: may contain the clock handling the device, if needed.
+- power-domains: may contain a reference to the PM domain, if applicable.
+
+
+Examples:
+
+Zynq FPGA device
+
+
+   arm_cc7x: arm_cc7x@8000 {
+   compatible = "arm,cryptocell-712-ree";
+   interrupt-parent = <>;
+   interrupts = < 0 30 4 >;
+   reg = < 0x8000 0x1 >;
+   };
+
-- 
2.1.4

Re: [PATCH 5/6] MODSIGN: Export module signature definitions.

[Mimi Zohar]

On Tue, 2017-04-18 at 17:17 -0300, Thiago Jung Bauermann wrote:
> IMA will use the module_signature format for append signatures, so export
> the relevant definitions and factor out the code which verifies that the
> appended signature trailer is valid.
> 
> Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it
> and be able to use validate_module_signature without having to depend on
> CONFIG_MODULE_SIG.

Basically we want to generalize the concept of an appended signature.
 Referring to it as a "module signature format" seems a bit confusing.

David, would you have a problem with changing the appended string from
"~Module signature appended~\n" to something more generic?  The
appended signature format could be used by anything calling
kernel_read_file() (eg. kexec kernel image/initramfs).

Mimi

> Signed-off-by: Thiago Jung Bauermann 
> ---
>  include/linux/module_signature.h | 45 
>  init/Kconfig |  6 +++-
>  kernel/Makefile  |  2 +-
>  kernel/module_signing.c  | 74 
> +---
>  4 files changed, 82 insertions(+), 45 deletions(-)
> 
> diff --git a/include/linux/module_signature.h 
> b/include/linux/module_signature.h
> new file mode 100644
> index ..b04f16559b47
> --- /dev/null
> +++ b/include/linux/module_signature.h
> @@ -0,0 +1,45 @@
> +/* Module signature handling.
> + *
> + * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
> + * Written by David Howells (dhowe...@redhat.com)
> + *
> + * 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.
> + */
> +
> +#ifndef _LINUX_MODULE_SIGNATURE_H
> +#define _LINUX_MODULE_SIGNATURE_H
> +
> +enum pkey_id_type {
> + PKEY_ID_PGP,/* OpenPGP generated key ID */
> + PKEY_ID_X509,   /* X.509 arbitrary subjectKeyIdentifier */
> + PKEY_ID_PKCS7,  /* Signature in PKCS#7 message */
> +};
> +
> +/*
> + * Module signature information block.
> + *
> + * The constituents of the signature section are, in order:
> + *
> + *   - Signer's name
> + *   - Key identifier
> + *   - Signature data
> + *   - Information block
> + */
> +struct module_signature {
> + u8  algo;   /* Public-key crypto algorithm [0] */
> + u8  hash;   /* Digest algorithm [0] */
> + u8  id_type;/* Key identifier type [PKEY_ID_PKCS7] */
> + u8  signer_len; /* Length of signer's name [0] */
> + u8  key_id_len; /* Length of key identifier [0] */
> + u8  __pad[3];
> + __be32  sig_len;/* Length of signature data */
> +};
> +
> +int validate_module_signature(const struct module_signature *ms,
> +   size_t file_len);
> +int mod_verify_sig(const void *mod, unsigned long *_modlen);
> +
> +#endif /* _LINUX_MODULE_SIGNATURE_H */
> diff --git a/init/Kconfig b/init/Kconfig
> index a92f27da4a27..891325e5aeff 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -2024,7 +2024,7 @@ config MODULE_SRCVERSION_ALL
>  config MODULE_SIG
>   bool "Module signature verification"
>   depends on MODULES
> - select SYSTEM_DATA_VERIFICATION
> + select MODULE_SIG_FORMAT
>   help
> Check modules for valid signatures upon load: the signature
> is simply appended to the module. For more information see
> @@ -2039,6 +2039,10 @@ config MODULE_SIG
> debuginfo strip done by some packagers (such as rpmbuild) and
> inclusion into an initramfs that wants the module size reduced.
> 
> +config MODULE_SIG_FORMAT
> + def_bool n
> + select SYSTEM_DATA_VERIFICATION
> +
>  config MODULE_SIG_FORCE
>   bool "Require modules to be validly signed"
>   depends on MODULE_SIG
> diff --git a/kernel/Makefile b/kernel/Makefile
> index b302b4731d16..4451bbc70a08 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -56,7 +56,7 @@ obj-y += up.o
>  endif
>  obj-$(CONFIG_UID16) += uid16.o
>  obj-$(CONFIG_MODULES) += module.o
> -obj-$(CONFIG_MODULE_SIG) += module_signing.o
> +obj-$(CONFIG_MODULE_SIG_FORMAT) += module_signing.o
>  obj-$(CONFIG_KALLSYMS) += kallsyms.o
>  obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
>  obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
> diff --git a/kernel/module_signing.c b/kernel/module_signing.c
> index 937c844bee4a..421e3e668714 100644
> --- a/kernel/module_signing.c
> +++ b/kernel/module_signing.c
> @@ -11,36 +11,38 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include "module-internal.h"
> 
> -enum pkey_id_type {
> - PKEY_ID_PGP,/* OpenPGP generated key ID */
> - PKEY_ID_X509,   /* X.509 arbitrary subjectKeyIdentifier */
> - PKEY_ID_PKCS7,  /* Signature in PKCS#7 message 

Re: [PATCH 3/6] ima: Simplify policy_func_show.

[Mimi Zohar]

On Tue, 2017-04-18 at 17:17 -0300, Thiago Jung Bauermann wrote:
> If the func_tokens array uses the same indices as enum ima_hooks,
> policy_func_show can be a lot simpler, and the func_* enum becomes
> unnecessary.

My main concern with separating the enumeration from the string
definition is that they might become out of sync.  Perhaps using
macros, similar to those used for kernel_read_file_id_str(), would be
better?

> Signed-off-by: Thiago Jung Bauermann 
> ---
>  security/integrity/ima/ima_policy.c | 47 
> ++---
>  1 file changed, 7 insertions(+), 40 deletions(-)
> 
> diff --git a/security/integrity/ima/ima_policy.c 
> b/security/integrity/ima/ima_policy.c
> index cfda5d7b17ec..158eafef64e8 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -896,20 +896,14 @@ static const char *const mask_tokens[] = {
>   "MAY_APPEND"
>  };
> 
> -enum {
> - func_file = 0, func_mmap, func_bprm,
> - func_module, func_firmware, func_post,
> - func_kexec_kernel, func_kexec_initramfs,
> - func_policy
> -};
> -

At least, add a comment here and near the ima_hooks enumeration to
prevent them from becoming out of sync.

Mimi

>  static const char *const func_tokens[] = {
> + NULL,
>   "FILE_CHECK",
>   "MMAP_CHECK",
>   "BPRM_CHECK",
> + "POST_SETATTR",
>   "MODULE_CHECK",
>   "FIRMWARE_CHECK",
> - "POST_SETATTR",
>   "KEXEC_KERNEL_CHECK",
>   "KEXEC_INITRAMFS_CHECK",
>   "POLICY_CHECK"
> @@ -949,48 +943,21 @@ void ima_policy_stop(struct seq_file *m, void *v)
> 
>  #define pt(token)policy_tokens[token + Opt_err].pattern
>  #define mt(token)mask_tokens[token]
> -#define ft(token)func_tokens[token]
> 
>  /*
>   * policy_func_show - display the ima_hooks policy rule
>   */
>  static void policy_func_show(struct seq_file *m, enum ima_hooks func)
>  {
> - char tbuf[64] = {0,};
> + if (func > 0 && func < MAX_CHECK)
> + seq_printf(m, pt(Opt_func), func_tokens[func]);
> + else {
> + char tbuf[64] = {0,};
> 
> - switch (func) {
> - case FILE_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_file));
> - break;
> - case MMAP_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_mmap));
> - break;
> - case BPRM_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_bprm));
> - break;
> - case MODULE_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_module));
> - break;
> - case FIRMWARE_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_firmware));
> - break;
> - case POST_SETATTR:
> - seq_printf(m, pt(Opt_func), ft(func_post));
> - break;
> - case KEXEC_KERNEL_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_kexec_kernel));
> - break;
> - case KEXEC_INITRAMFS_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_kexec_initramfs));
> - break;
> - case POLICY_CHECK:
> - seq_printf(m, pt(Opt_func), ft(func_policy));
> - break;
> - default:
>   snprintf(tbuf, sizeof(tbuf), "%d", func);
>   seq_printf(m, pt(Opt_func), tbuf);
> - break;
>   }
> +
>   seq_puts(m, " ");
>  }
> 

Re: [RFC PATCH v1 0/1] *** crypto: AF_ALG: add compression support ***

[Herbert Xu]

On Thu, Apr 20, 2017 at 12:39:58PM +0530, abed mohammad kamaluddin wrote:
> Hi Herbert,
> 
> > I think we should convert ipcomp over to the new interface first
> > in order to make sure that we don't need to change the interface
> > which would be hard to do once we export it to user-space.
> 
> Would it be acceptable if we export an algif interface using 
> alg_type_compress,
> which is being used by ipcomp currently? We would like to use our zip
> device from
> userspace through this interface.

No we're not going to export an obsolete interface.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 4/8] crypto: KPP - add API crypto_kpp_set_params

[Stephan Müller]

Am Mittwoch, 19. April 2017, 16:51:54 CEST schrieb Benedetto, Salvatore:

Hi Salvatore,

> Hi Stephan,
> 
> > -Original Message-
> > From: keyrings-ow...@vger.kernel.org [mailto:keyrings-
> > ow...@vger.kernel.org] On Behalf Of Stephan Müller
> > Sent: Wednesday, April 19, 2017 12:06 AM
> > To: linux-crypto@vger.kernel.org
> > Cc: keyri...@vger.kernel.org
> > Subject: [PATCH 4/8] crypto: KPP - add API crypto_kpp_set_params
> > 
> > KPP mechanisms like DH require a parameter set to be provided by the
> > caller. That parameter set may be provided by the crypto_kpp_set_secret
> > function. Yet, the parameters hare handled independently from the secret
> > key which implies that they should be able to be set independently from
> > the key.
> > 
> > The new API allows KPP mechanisms to register a callback allowing to set
> > such parameters.
> > 
> > Signed-off-by: Stephan Mueller 
> > ---
> > 
> >  Documentation/crypto/api-kpp.rst |  2 +-
> >  include/crypto/kpp.h | 28 
> >  2 files changed, 29 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/crypto/api-kpp.rst b/Documentation/crypto/api-
> > kpp.rst
> > index 7d86ab9..7b2c0d4 100644
> > --- a/Documentation/crypto/api-kpp.rst
> > +++ b/Documentation/crypto/api-kpp.rst
> > @@ -11,7 +11,7 @@ Key-agreement Protocol Primitives (KPP) Cipher API
> > 
> > :doc: Generic Key-agreement Protocol Primitives API
> >  
> >  .. kernel-doc:: include/crypto/kpp.h
> > 
> > -   :functions: crypto_alloc_kpp crypto_free_kpp crypto_kpp_set_secret
> > crypto_kpp_generate_public_key crypto_kpp_compute_shared_secret
> > crypto_kpp_maxsize
> > +   :functions: crypto_alloc_kpp crypto_free_kpp crypto_kpp_set_params
> > + crypto_kpp_set_secret crypto_kpp_generate_public_key
> > + crypto_kpp_compute_shared_secret crypto_kpp_maxsize
> > 
> >  Key-agreement Protocol Primitives (KPP) Cipher Request Handle
> >  -
> > 
> > diff --git a/include/crypto/kpp.h b/include/crypto/kpp.h index
> > ce8e1f7..5931364 100644
> > --- a/include/crypto/kpp.h
> > +++ b/include/crypto/kpp.h
> > @@ -51,6 +51,9 @@ struct crypto_kpp {
> > 
> >  /**
> >  
> >   * struct kpp_alg - generic key-agreement protocol primitives
> >   *
> > 
> > + * @set_params:Function allows the caller to set the parameters
> > + * separately from the key. The format of the
> > parameters
> > + * is protocol specific.
> > 
> >   * @set_secret:Function invokes the protocol specific
> > 
> > function to
> > 
> >   * store the secret private key along with parameters.
> >   * The implementation knows how to decode thie
> > 
> > buffer
> > @@ -74,6 +77,8 @@ struct crypto_kpp {
> > 
> >   * @base:  Common crypto API algorithm data structure
> >   */
> >  
> >  struct kpp_alg {
> > 
> > +   int (*set_params)(struct crypto_kpp *tfm, const void *buffer,
> > + unsigned int len);
> > 
> > int (*set_secret)(struct crypto_kpp *tfm, const void *buffer,
> > 
> >   unsigned int len);
> > 
> > int (*generate_public_key)(struct kpp_request *req); @@ -259,6
> > 
> > +264,29 @@ struct kpp_secret {  };
> > 
> >  /**
> > 
> > + * crypto_kpp_set_params() - Set parameters needed for kpp operation
> > + *
> > + * Function invokes the specific kpp operation for a given alg.
> > + *
> > + * @tfm:   tfm handle
> > + * @buffer:Buffer holding the protocol specific representation of 
> > the
> > + * parameters (e.g. PKCS#3 DER for DH)
> > + * @len:   Length of the parameter buffer.
> > + *
> > + * Return: zero on success; error code in case of error  */ static
> > +inline int crypto_kpp_set_params(struct crypto_kpp *tfm,
> > +   const void *buffer, unsigned int len) {
> > +   struct kpp_alg *alg = crypto_kpp_alg(tfm);
> > +
> > +   if (alg->set_params)
> > +   return alg->set_params(tfm, buffer, len);
> > +   else
> > +   return -EOPNOTSUPP;
> > +}
> > +
> > +/**
> > 
> >   * crypto_kpp_set_secret() - Invoke kpp operation
> >   *
> >   * Function invokes the specific kpp operation for a given alg.
> > 
> > --
> > 2.9.3
> 
> I'm not really in favor of having two ways for setting the params.

I am in full agreement. But setting the key together with the parameters is 
not good, IMHO. Every other crypto lib implements a separate setting.

> As you are probably aware, PKCS3 and set_params was my intial
> approach, but then Herbert suggested a lighter approach like rtnetlink
> which I actually prefer.

I was not aware of that. Considering that PKCS#3 or X9.42 are the common 
formats for setting parameters, I am not in favor of "inventing" a special 
format just for the kernel user space interface. If we would have such special 
format, user space would need to add a conversion step from a common to the 
kernel-special 

Re: [RFC PATCH v1 0/1] *** crypto: AF_ALG: add compression support ***

[abed mohammad kamaluddin]

Hi Herbert,

> I think we should convert ipcomp over to the new interface first
> in order to make sure that we don't need to change the interface
> which would be hard to do once we export it to user-space.

Would it be acceptable if we export an algif interface using alg_type_compress,
which is being used by ipcomp currently? We would like to use our zip
device from
userspace through this interface.

Thanks
Abed (Cavium)


On Fri, Apr 14, 2017 at 2:02 PM, Herbert Xu  wrote:
> On Fri, Apr 14, 2017 at 12:04:53AM +0530, Abed Kamaluddin wrote:
>> Hi Herbert,
>>
>> This patch adds compression support to the AF_ALG interface exported by the
>> kernel crypto API. By extending AF_ALG, all compression algorithms of types
>> scomp and acomp, which the kernel crypto API allows access to, are now also
>> accessible from userspace.
>>
>> The new compression interface has been tested with both kernel software
>> deflate(scomp) and HW accelerated ThunderX deflate(scomp) using the zpipe
>> example application provided by zlib.
>
> I think we should convert ipcomp over to the new interface first
> in order to make sure that we don't need to change the interface
> which would be hard to do once we export it to user-space.
>
> Thanks,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt