Re: [PATCH v2] X.509: Fix error code in x509_cert_parse()
Herbert Xu wrote: > Patch applied. Thanks. Note that I've passed this on to James to pass on to Linus along with a bunch of other patches. David
Re: [PATCH] crypto: rng - move __crypto_rng_cast to the rng header
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
Re: [PATCH] crypto: rng: Remove unused function __crypto_rng_cast()
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.
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 v3 0/2] crypto: ecdh - add privkey generation support
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 v2 0/3] Add support for Cavium CNN55XX crypto adapters.
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 v1 0/2] remove mediatek ethif clock in crypto driver
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
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 v4 00/14] fixes for kpp and akcipher
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
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 v6 5/5] MAINTAINERS: add a maintainer for the Inside Secure crypto driver
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()
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 v2 01/11] crypto: introduce crypto wait for async op
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(&wait->completion); > + reinit_completion(&wait->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 v8 1/2] crypto: skcipher AF_ALG - overhaul memory management
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(&ctx->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(&ctx->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 v2 0/6] Appended signatures support for IMA appraisal
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
Alg errors with Intel QAT Card
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-
RE: Can someone check linux kernel 4.4, and 4.9 rfc4309 test vectors?
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 = &ctx; > 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, &outl, 0, sizeof(P)); >// Add the AAD > EVP_EncryptUpdate(cryptCtx, 0, &outl, A, sizeof(A)); >// Now we encrypt the data in P, placing the output in CT > EVP_EncryptUpdate(cryptCtx, CT, &outl, P, Psize); > EVP_EncryptFinal(cryptCtx, &CT[outl], &outl); > // Append the tag to the end of the encrypted output > EVP_CIPHER_CTX_ctrl(cryptCtx, EVP_CTRL_CCM_GET_TAG, Tsize, &CT[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 0/6] Appended signatures support for IMA appraisal
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