Crypto Fixes for 4.11

Hi Linus: This push fixes the following issues: - vmalloc stack regression in CCM. - Build problem in CRC32 on ARM. - Memory leak in cavium. - Missing Kconfig dependencies in atmel and mediatek. - XTS Regression on some platforms (s390 and ppc). - Memory overrun in CCM test vector. Please pull

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

Hi Bjorn, On 03/03/2017 02:33 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: This RFC series provides support for AMD's new Secure Encrypted Virtualization (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1]. What kernel

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On 3/3/2017 2:42 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: From: Tom Lendacky The use of ioremap will force the setup data to be mapped decrypted even though setup data is encrypted. Switch to using memremap which will be

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

Hi Boris, On 03/03/2017 10:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote: From: Tom Lendacky Update the CPU features to include identifying and reporting on the Secure Encrypted Virtualization (SEV) feature. SME is

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote: > On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > > This RFC series provides support for AMD's new Secure Encrypted > > Virtualization > > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 >

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > The use of ioremap will force the setup data to be mapped decrypted even > though setup data is encrypted. Switch to using memremap which will be > able to perform the proper

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > This RFC series provides support for AMD's new Secure Encrypted Virtualization > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 > [1]. What kernel version is this series based on?

[RFC 1/7] soc/qman: export volatile dequeue related structs

Since qman_volatile_dequeue() is already exported, move the related structures into the public header too. Signed-off-by: Horia Geantă --- drivers/soc/fsl/qbman/qman_priv.h | 36 include/soc/fsl/qman.h| 36

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote: > From: Tom Lendacky > > Update the CPU features to include identifying and reporting on the > Secure Encrypted Virtualization (SEV) feature. SME is identified by > CPUID 0x801f, but requires BIOS

[RFC 4/7] soc/qman: add helper functions needed by caam/qi driver

Add helper functions, macros, #defines for accessing / enabling qman functionality from caam/qi driver, such that this driver is not aware of the need for data conversion to big endian. qman is updated to use these helpers internally. Signed-off-by: Horia Geantă ---

[RFC 3/7] soc/qman: export non-programmable FQD fields query

Export qman_query_fq_np() function and related structures. This will be needed in the caam/qi driver, where "queue empty" condition will be decided based on the frm_cnt. Signed-off-by: Horia Geantă --- drivers/soc/fsl/qbman/qman.c | 4 +--

[RFC 2/7] soc/qman: add dedicated channel ID for CAAM

Add and export the ID of the channel serviced by the CAAM (Cryptographic Acceleration and Assurance Module) DCP. Signed-off-by: Horia Geantă --- drivers/soc/fsl/qbman/qman_ccsr.c | 6 +- include/soc/fsl/qman.h| 3 +++ 2 files changed, 8 insertions(+), 1

[RFC 0/7] crypto: caam - add Queue Interface (QI) support

The patchset adds support for CAAM Queue Interface (QI), the additional interface (besides job ring) available for submitting jobs to the engine on platforms having DPAA (Datapath Acceleration Architecture). Patches 1-4 are QMan dependencies. I would prefer to take them through the crypto tree,

[RFC 5/7] crypto: caam - avoid double inclusion in desc_constr.h

Signed-off-by: Horia Geantă --- drivers/crypto/caam/desc_constr.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/caam/desc_constr.h b/drivers/crypto/caam/desc_constr.h index b9c8d98ef826..d8e83ca104e0 100644 --- a/drivers/crypto/caam/desc_constr.h

[RFC 7/7] crypto: caam/qi - add ablkcipher and authenc algorithms

Add support to submit ablkcipher and authenc algorithms via the QI backend: -ablkcipher: cbc({aes,des,des3_ede}) ctr(aes), rfc3686(ctr(aes)) xts(aes) -authenc: authenc(hmac(md5),cbc({aes,des,des3_ede})) authenc(hmac(sha*),cbc({aes,des,des3_ede})) caam/qi being a new driver, let's wait some time

[RFC 6/7] crypto: caam - add Queue Interface (QI) backend support

CAAM engine supports two interfaces for crypto job submission: -job ring interface - already existing caam/jr driver -Queue Interface (QI) - caam/qi driver added in current patch QI is present in CAAM engines found on DPAA platforms. QI gets its I/O (frame descriptors) from QMan (Queue Manager)

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list. Heh, I was about to ask if it was something I should push towards another maintainer for s5p stuff, but found you listed in that as well. If I am incorrect in that assumption, do let me know whom else I should make aware

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

On Thu, 2017-03-02 at 13:11 -0600, Brijesh Singh wrote: > Hi Mark, > > On 03/02/2017 11:39 AM, Mark Rutland wrote: > > On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote: > > > > > > +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \ > > >   ccp-ops.o \ > > >   ccp-dev-v3.o \ > > >

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote: > I do have ECB selected as well: > DM_CRYPT=y > CRYPTO_ECB=y > CRYPTO_XTS=y > > name : ecb(aes) > driver : ecb-aes-s5p > module : kernel > priority : 100 > refcnt : 1 > selftest : passed > internal

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

I do have ECB selected as well: DM_CRYPT=y CRYPTO_ECB=y CRYPTO_XTS=y name : ecb(aes) driver : ecb-aes-s5p module : kernel priority : 100 refcnt : 1 selftest : passed internal : no type : ablkcipher async: yes blocksize: 16 min keysize :

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote: > OK, I went ahead and enabled self tests > "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, > albeit with failures: > * > Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- > Mar 02 23:14:38 server

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

OK, I went ahead and enabled self tests "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, albeit with failures: * Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on test 1 for xts(ecb-aes-s5p):