Re: [PATCH v2 0/6] Appended signatures support for IMA appraisal

[Thiago Jung Bauermann]

Michael Ellerman  writes:

> Thiago Jung Bauermann  writes:
>
>> On the OpenPOWER platform, secure boot and trusted boot are being
>> implemented using IMA for taking measurements and verifying signatures.
>
> I still want you to implement arch_kexec_kernel_verify_sig() as well :)

Yes, I will implement it! We are still working on loading the public
keys for kernel signing from the firmware into a kernel keyring, so
there's not much point in implementing arch_kexec_kernel_verify_sig
without having that first.

The same problem also affects IMA: even with these patches, new code
still neededs to be added to make IMA use the platform keys for kernel
signature verification.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

[PATCH] Drivers: ccree - style fix

[Derek Robson]

Align block comments
Found using checkpatch

Signed-off-by: Derek Robson 
---
 drivers/staging/ccree/cc_hw_queue_defs.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index aaa56c85bda2..0e6416ed9a58 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -23,8 +23,8 @@
 #include 
 
 /**
-*  DEFINITIONS
-**/
+ * DEFINITIONS
+ 
**/
 
 #define HW_DESC_SIZE_WORDS 6
 #define HW_QUEUE_SLOTS_MAX  15 /* Max. available slots in HW queue 
*/
@@ -70,8 +70,8 @@
 #define WORD5_DOUT_ADDR_HIGH   CC_GENMASK(5, DOUT_ADDR_HIGH)
 
 /**
-*  TYPE DEFINITIONS
-**/
+ * TYPE DEFINITIONS
+ 
**/
 
 struct cc_hw_desc {
union {
-- 
2.13.0

Re: [PATCH v2 0/6] Appended signatures support for IMA appraisal

[Michael Ellerman]

Thiago Jung Bauermann  writes:

> On the OpenPOWER platform, secure boot and trusted boot are being
> implemented using IMA for taking measurements and verifying signatures.

I still want you to implement arch_kexec_kernel_verify_sig() as well :)

cheers

Re: Can someone check linux kernel 4.4, and 4.9 rfc4309 test vectors?

[Harsh Jain]

On Wed, Jun 7, 2017 at 7:27 PM, Che-Min Hsieh  wrote:
> Rfc4309 test vectors in testmgr.h have gone through major changes from linux3 
>  to linux4.
> In linux 4.4, linux4.9, there are vectors as such
>
> 23194 static struct aead_testvec aes_ccm_rfc4309_enc_tv_template[] = {
> 23195{ /* Generated using Crypto++ */
> 23196.key   = zeroed_string,
> 23197.klen  = 19,
> 23198.iv   = zeroed_string,
> 23199.input= zeroed_string,
> 23200.ilen   = 16,
> 23201.assoc= zeroed_string,
> 23202.alen  = 16,
> 23203.result   = "\x2E\x9A\xCA\x6B\xDA\x54\xFC\x6F"
> 23204  "\x12\x50\xE8\xDE\x81\x3C\x63\x08"
> 23205  "\x1A\x22\xBA\x75\xEE\xD4\xD5\xB5"
> 23206  "\x27\x50\x01\xAC\x03\x33\x39\xFB",
> 23207.rlen   = 32,
>
>
> I have a test program using open ssl API (-l crypto), and run on Ubuntu Linux 
> PC,   I  get the following  test result:
>
> 2e 9a ca 6b da 54 fc 6f 12 50 e8 de 81 3c 63 08
> fb 64 91 b4 dd dc bf 5d fd 67 e3 a2 f8 7c 0e 6c
>   The first part of encrypted text is correct. But MAC is not the 
> same.
>
> My program is as the following:
>
> void ccmTest()
> {
> /* Initialization */
> EVP_CIPHER_CTX ctx;
> EVP_CIPHER_CTX *cryptCtx = 
> EVP_CIPHER_CTX_init(cryptCtx);
> int i;
>
>unsigned char P[16] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> int Psize = sizeof(P);
> unsigned char K[16] = {0};
> unsigned char N[11] = {0};
> unsigned char A[16] = {0};
> unsigned char CT[128];
>
> int Nsize = 11;
> int Tsize = 16;
>
> // Initialize the context with the alg only
> EVP_EncryptInit(cryptCtx, EVP_aes_128_ccm(), 0, 0);
>
> // Set nonce and tag sizes
> EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_SET_IVLEN, Nsize, 0);
> EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_SET_TAG, Tsize, 0);
>
> // Finally set the key and the nonce
> EVP_EncryptInit(cryptCtx, 0, K, N);
>
> // Tell the alg we will encrypt Psize bytes
> int outl = 0;
> EVP_EncryptUpdate(cryptCtx, 0, , 0, sizeof(P));
>// Add the AAD
> EVP_EncryptUpdate(cryptCtx, 0, , A, sizeof(A));
>// Now we encrypt the data in P, placing the output in CT
> EVP_EncryptUpdate(cryptCtx, CT, , P, Psize);
> EVP_EncryptFinal(cryptCtx, [outl], );
> // Append the tag to the end of the encrypted output
> EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_GET_TAG, Tsize, [Psize]);
> hexdump(CT, Tsize+Psize);
> }
>
>
> I run "insmod tcrypt.ko mode=45"  rfc4309 test with Qualcomm crypto hardware 
> on Linux4.4. The test fails. The generated output is the same as my openSSL 
> test application in 1.
Older kernel driver also includes IV in Authentication data.  Thats
why MAC is wrong . 4.4 kernel crypto drivers don't need to include IV
in authentication data. Updating driver not to include IV string in
authentication data for latest kernels should work.
>
> My test application runs on Ubuntu with linux 3.10 rfc4309 test vector, and 
> generated MAC as expected from test vectors.  Qualcomm crypto hardware runs 
> "insmod tcrypt.ko mode=45" successfully with linux 3.10.
>
> I am suspicious about the test vectors of 4.4. Can someone verify the Linux 
> 4.4 rfc4309 test vectors with his/her openSSL application on PC?
>
> Chemin

RE: Can someone check linux kernel 4.4, and 4.9 rfc4309 test vectors?

[Che-Min Hsieh]

Thanks.
Yes, in the new kernel, the association data passing in to the driver, the last 
8 bytes of data should be excluded in the driver.
The conversion from rfc4309 test vectors defined in the testmgr.h should drop 
the last 8 bytes of data before passing to the openSSL API as association data. 
After I did that, things match.


-Original Message-
From: Harsh Jain [mailto:harshjain.p...@gmail.com] 
Sent: Friday, June 9, 2017 2:31 AM
To: Che-Min Hsieh 
Cc: linux-crypto@vger.kernel.org; Zhen Kong ; Dan Bronstein 

Subject: Re: Can someone check linux kernel 4.4, and 4.9 rfc4309 test vectors?

On Wed, Jun 7, 2017 at 7:27 PM, Che-Min Hsieh  wrote:
> Rfc4309 test vectors in testmgr.h have gone through major changes from linux3 
>  to linux4.
> In linux 4.4, linux4.9, there are vectors as such
>
> 23194 static struct aead_testvec aes_ccm_rfc4309_enc_tv_template[] = {
> 23195{ /* Generated using Crypto++ */
> 23196.key   = zeroed_string,
> 23197.klen  = 19,
> 23198.iv   = zeroed_string,
> 23199.input= zeroed_string,
> 23200.ilen   = 16,
> 23201.assoc= zeroed_string,
> 23202.alen  = 16,
> 23203.result   = "\x2E\x9A\xCA\x6B\xDA\x54\xFC\x6F"
> 23204  "\x12\x50\xE8\xDE\x81\x3C\x63\x08"
> 23205  "\x1A\x22\xBA\x75\xEE\xD4\xD5\xB5"
> 23206  "\x27\x50\x01\xAC\x03\x33\x39\xFB",
> 23207.rlen   = 32,
>
>
> I have a test program using open ssl API (-l crypto), and run on Ubuntu Linux 
> PC,   I  get the following  test result:
>
> 2e 9a ca 6b da 54 fc 6f 12 50 e8 de 81 3c 63 08 fb 64 91 b4 dd dc bf 
> 5d fd 67 e3 a2 f8 7c 0e 6c
>   The first part of encrypted text is correct. But MAC is not the 
> same.
>
> My program is as the following:
>
> void ccmTest()
> {
> /* Initialization */
> EVP_CIPHER_CTX ctx;
> EVP_CIPHER_CTX *cryptCtx = 
> EVP_CIPHER_CTX_init(cryptCtx);
> int i;
>
>unsigned char P[16] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
> int Psize = sizeof(P);
> unsigned char K[16] = {0};
> unsigned char N[11] = {0};
> unsigned char A[16] = {0};
> unsigned char CT[128];
>
> int Nsize = 11;
> int Tsize = 16;
>
> // Initialize the context with the alg only
> EVP_EncryptInit(cryptCtx, EVP_aes_128_ccm(), 0, 0);
>
> // Set nonce and tag sizes
> EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_SET_IVLEN, Nsize, 0);
> EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_SET_TAG, Tsize, 0);
>
> // Finally set the key and the nonce
> EVP_EncryptInit(cryptCtx, 0, K, N);
>
> // Tell the alg we will encrypt Psize bytes
> int outl = 0;
> EVP_EncryptUpdate(cryptCtx, 0, , 0, sizeof(P));
>// Add the AAD
> EVP_EncryptUpdate(cryptCtx, 0, , A, sizeof(A));
>// Now we encrypt the data in P, placing the output in CT
> EVP_EncryptUpdate(cryptCtx, CT, , P, Psize);
> EVP_EncryptFinal(cryptCtx, [outl], );
> // Append the tag to the end of the encrypted output
> EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_GET_TAG, Tsize, [Psize]);
> hexdump(CT, Tsize+Psize);
> }
>
>
> I run "insmod tcrypt.ko mode=45"  rfc4309 test with Qualcomm crypto hardware 
> on Linux4.4. The test fails. The generated output is the same as my openSSL 
> test application in 1.
Older kernel driver also includes IV in Authentication data.  Thats why MAC is 
wrong . 4.4 kernel crypto drivers don't need to include IV in authentication 
data. Updating driver not to include IV string in authentication data for 
latest kernels should work.
>
> My test application runs on Ubuntu with linux 3.10 rfc4309 test vector, and 
> generated MAC as expected from test vectors.  Qualcomm crypto hardware runs 
> "insmod tcrypt.ko mode=45" successfully with linux 3.10.
>
> I am suspicious about the test vectors of 4.4. Can someone verify the Linux 
> 4.4 rfc4309 test vectors with his/her openSSL application on PC?
>
> Chemin

Re: [PATCH v2 01/11] crypto: introduce crypto wait for async op

[Herbert Xu]

On Mon, May 29, 2017 at 11:22:48AM +0300, Gilad Ben-Yossef wrote:
>
> +static inline int crypto_wait_req(int err, struct crypto_wait *wait)
> +{
> + switch (err) {
> + case -EINPROGRESS:
> + case -EBUSY:
> + wait_for_completion(>completion);
> + reinit_completion(>completion);
> + err = wait->err;
> + break;
> + };
> +
> + return err;
> +}

This assumes that the request is used with backlog.  For non-backlog
requests this would result in a memory leak as EBUSY in that case is
a fatal error.

So this API can't be used without backlog.

We could introduce a flag to indicate whether we want backlog or not,
or maybe we should change our API so that in the non-backlog case we
return something other than EBUSY.

Opinions?

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

Re: [PATCH v3 0/2] crypto: ecdh - add privkey generation support

[Herbert Xu]

On Tue, May 30, 2017 at 05:52:47PM +0300, Tudor Ambarus wrote:
> Hi,
> 
> This patch set adds support for generating ecc private keys.
> ecc private keys are generated using the method of extra random bits,
> equivalent to that described in FIPS 186-4, Appendix B.4.1.
> 
> Generation of ecc private keys is helpful in a user-space to kernel
> ecdh offload because the keys are not revealed to user-space.
> 
> Private key generation is also helpful to implement forward secrecy.
> A public/private key system demonstrates the property of forward secrecy
> if it creates new key pairs for each communication session. These key pairs
> are generated on an as-needed basis and are destroyed after the session
> is over. If an attacker were to record previous encrypted session data,
> they wouldn't be able to decrypt it with possession of a long-term key.
> 
> There are crypto accelerators that are capable of generating and retaining
> ecdh private keys without revealing them to software. This patch set is a
> prerequisite for hardware ecdh with private key generation support.
> 
> Changes in v3:

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

Re: [PATCH v4 00/14] fixes for kpp and akcipher

[Herbert Xu]

On Thu, May 25, 2017 at 10:18:02AM +0300, Tudor Ambarus wrote:
> Hi,
> 
> These are various fixes that I made while reading kpp and akcipher
> implementations.
> 
> Changes in v4:
>  - assume key is already set when calling crypto_akcipher/kpp_maxsize()

All applied, with patch 4/14 taken from v5.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 00/13] crypto: omap fixes / changes for 4.13

[Herbert Xu]

On Wed, May 24, 2017 at 10:35:21AM +0300, Tero Kristo wrote:
> Hi,
> 
> This series has a number of fixes towards 4.13 merge window (I don't
> think we need to rush these as nobody has complained of any of the
> issues so far), and the addition of AES GCM mode. Lokesh posted
> the support patch for GCM quite a while back, I have addressed
> the comments received back then as well as I could and done some
> additional changes on top. The series also introduces a base
> OMAP crypto support library for handling the various cases
> of buffer alignment. This is now used for both AES/DES. Addition
> of SHA to this is still pending as it requires certain things
> to be done slightly differently (need a couple of new flags for
> the API I believe.)

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

Re: [PATCH v1 0/2] remove mediatek ethif clock in crypto driver

[Herbert Xu]

On Thu, Jun 01, 2017 at 10:30:20AM +0800, Ryder Lee wrote:
> This patch series only remove redundant clock setting in mediatek crypto 
> driver.
> 
> Changes since v1:
> -rework the commit message.

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

Re: [PATCH v6 4/5] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver

[Herbert Xu]

On Wed, May 24, 2017 at 04:10:34PM +0200, Antoine Tenart wrote:
> Add support for Inside Secure SafeXcel EIP197 cryptographic engine,
> which can be found on Marvell Armada 7k and 8k boards. This driver
> currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and
> hmac(sah1) algorithms.
> 
> Two firmwares are needed for this engine to work. Their are mostly used
> for more advanced operations than the ones supported (as of now), but we
> still need them to pass the data to the internal cryptographic engine.
> 
> Signed-off-by: Antoine Tenart 

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

Re: [PATCH v2 0/3] Add support for Cavium CNN55XX crypto adapters.

[Herbert Xu]

On Tue, May 30, 2017 at 05:28:00PM +0530, Srikanth Jampala wrote:
> This series adds support for Cavium CNN55XX crypto adapters.
>   
>  CNN55XX crypto adapters belongs to Cavium NITROX family series,
>  able to accelerates both Symmetric and Asymmetric crypto workloads.
>  These adapters have crypto cores for Symmetric and Asymmetric
>  crypto operations, and needs to load firmware to become operational.
>  
>  Patches are generated on top of kernel/git/herbert/crypto-2.6
> 
>  The series was tested with dm-crypt for in kernel
>  cryptographic offload operations.
> 
> Changes from v1 to v2:

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

Re: [PATCH] crypto: rng: Remove unused function __crypto_rng_cast()

[Herbert Xu]

On Mon, May 22, 2017 at 03:49:43PM -0700, Matthias Kaehlcke wrote:
> This fixes the following warning when building with clang:
> 
> crypto/rng.c:35:34: error: unused function '__crypto_rng_cast'
> [-Werror,-Wunused-function]
> 
> Signed-off-by: Matthias Kaehlcke 

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

Re: [PATCH 1/1] crypto:drbg- Fixes panic in wait_for_completion call.

[Herbert Xu]

On Fri, May 26, 2017 at 12:12:51PM +0200, Stephan Müller wrote:
> Am Donnerstag, 25. Mai 2017, 17:23:47 CEST schrieb Harsh Jain:
> 
> Hi Harsh,
> 
> > Initialise ctr_completion variable before use.
> 
> Thank you very much for catching this.
> 
> But I think the chosen function is wrong. When we have an HMAC or Hash DRBG, 
> this completion function does not need to be initialized.
> 
> May I ask you to check this patch?

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

Re: [PATCH v6 5/5] MAINTAINERS: add a maintainer for the Inside Secure crypto driver

[Herbert Xu]

On Wed, May 24, 2017 at 04:10:35PM +0200, Antoine Tenart wrote:
> A new cryptographic engine driver was added in
> drivers/crypto/inside-secure. Add myself as a maintainer for this
> driver.
> 
> Signed-off-by: Antoine Tenart 

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

Re: [PATCH v2] X.509: Fix error code in x509_cert_parse()

[Herbert Xu]

On Mon, May 29, 2017 at 04:26:22PM +0300, Dan Carpenter wrote:
> We forgot to set the error code on this path so it could result in
> returning NULL which leads to a NULL dereference.
> 
> Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the 
> akcipher api")
> Signed-off-by: Dan Carpenter 
> ---
> v2:  Style change

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

Re: [PATCH v8 1/2] crypto: skcipher AF_ALG - overhaul memory management

[Herbert Xu]

On Tue, May 23, 2017 at 04:31:59PM +0200, Stephan Müller wrote:
>
>  static void skcipher_sock_destruct(struct sock *sk)
>  {
>   struct alg_sock *ask = alg_sk(sk);
>   struct skcipher_ctx *ctx = ask->private;
> - struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(>req);
> + struct sock *psk = ask->parent;
> + struct alg_sock *pask = alg_sk(psk);
> + struct skcipher_tfm *skc = pask->private;
> + struct crypto_skcipher *tfm = skc->skcipher;
>  
> - if (atomic_read(>inflight))
> - skcipher_wait(sk);
> + /* Suspend caller if AIO operations are in flight. */
> + wait_event_interruptible(skcipher_aio_finish_wait,
> +  (ctx->inflight == 0));

This doesn't look right.  If a signal comes in wouldn't you end
up freeing live memory?

The existing code is crap too.  We should not be waiting in the
destructor in the first place.  The proper way to do it is to hold
a reference count on the socket.

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

Re: [PATCH] crypto: rng - move __crypto_rng_cast to the rng header

[Herbert Xu]

On Tue, May 09, 2017 at 10:32:22AM +0200, Corentin Labbe wrote:
> This patch move __crypto_rng_cast() to the right header like other
> __algo_cast functions.
> 
> Signed-off-by: Corentin Labbe 

As there is another patch which will remove thie function altogether,
I think I'll just leave it in place.

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

Alg errors with Intel QAT Card

[Raj Ammanur]

Hi

I am seeing the below errors after  installing an Intel QAT card
and loading the upstreamed qat_dh895xcc and intel_qat modules.

Have others seen similar errors and know if this is a known issue
and a fix exists or know whats going on ? This is with 4.12.0-rc4+
version of the kernel.

Any help is sincerely appreciated.

thanks
--Raj


[3.639046] dh895xcc :00:0b.0: qat_dev0 started 12 acceleration engines
[4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on
encryption for qat_aes_cbc
[4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption
at page 0 for qat_aes_ctr
[4.282042] alg: skcipher: Test 4 failed (invalid result) on
encryption for qat_aes_xts
[4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22
[root@dhcp-swlab-681 ~]# dmesg | grep -i alg
[1.499336] alg: No test for pkcs1pad(rsa,sha256)
(pkcs1pad(rsa-generic,sha256))
[2.562511] SELinux:  Class alg_socket not defined in policy.
[4.168887] alg: skcipher-ddst: Test 5 failed (invalid result) on
encryption for qat_aes_cbc
[4.217866] alg: skcipher-ddst: Chunk test 1 failed on encryption
at page 0 for qat_aes_ctr
[4.282042] alg: skcipher: Test 4 failed (invalid result) on
encryption for qat_aes_xts
[4.367682] alg: akcipher: encrypt test failed. Invalid output
[4.395210] alg: akcipher: test 1 failed for qat-rsa, err=-22
[4.431827] alg: dh: generate public key test failed. Invalid output
[4.431829] alg: dh: test failed on vector 1, err=-22


83:00.0 Co-processor: Intel Corporation DH895XCC Series QAT
Subsystem: Intel Corporation Device 
Physical Slot: 2
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR-