Re: [PATCH] crypto: Drop owner assignment from platform_driver
On Fri, 10 Jul 2015 14:46:16 +0900
Krzysztof Kozlowski k.kozlow...@samsung.com wrote:
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Boris Brezillon boris.brezil...@free-electrons.com
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/crypto/marvell/cesa.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 1c6f98dd88f4..0643e3366e33 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -533,7 +533,6 @@ static struct platform_driver marvell_cesa = {
.probe = mv_cesa_probe,
.remove = mv_cesa_remove,
.driver = {
- .owner = THIS_MODULE,
.name = marvell-cesa,
.of_match_table = mv_cesa_of_match_table,
},
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/14] crypto: aead - Phase oute seqniv
On Thu, Jul 09, 2015 at 12:19:53PM +0200, Stephan Mueller wrote: All GCM implementations available on recent Intel systems successfully tested (i.e NX and CAAM not tested). Just to clarify: from a caller's perspective, using seqniv(rfc4106(gcm(aes))) is still the right invocation? Or shall I now use seqiv? You should use seqiv from now on. But I should update the patches so that seqniv is not visible to user-space. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/7] crypto: omap-aes: Add support for GCM mode
Hi Herbert,
On Wednesday 08 July 2015 09:48 AM, Herbert Xu wrote:
On Tue, Jul 07, 2015 at 09:01:48PM +0530, Lokesh Vutla wrote:
+static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
+ struct aead_request *req)
[..snip..]
+static int do_encrypt_iv(struct aead_request *req, u32 *tag)
+{
+struct scatterlist iv_sg;
+struct ablkcipher_request *ablk_req;
+struct crypto_ablkcipher *tfm;
+struct tcrypt_result result;
+struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
+int ret = 0;
+
+tfm = crypto_alloc_ablkcipher(ctr(aes), 0, 0);
Ugh, you cannot allocate crypto transforms in the data path. You
should allocate it in init instead. Also using ctr(aes) is overkill.
Just use aes and do the xor by hand.
+static int omap_aes_gcm_crypt(struct aead_request *req, unsigned long mode)
+{
+struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
+struct omap_aes_reqctx *rctx = aead_request_ctx(req);
+struct crypto_aead *aead = crypto_aead_reqtfm(req);
+unsigned int authlen = crypto_aead_authsize(aead);
+struct omap_aes_dev *dd;
+__be32 counter = cpu_to_be32(1);
+int err;
+
+memset(ctx-auth_tag, 0, sizeof(ctx-auth_tag));
The ctx is shared memory and you must not write to it as multiple
requests can be called on the same tfm. Use rctx instead.
May be a dumb question.
If you don't mind can you elaborate more on the usage of rctx and ctx
in the driver?
Thanks and regards,
Lokesh
+memcpy(req-iv + 12, counter, 4);
The IV is only 12 bytes long so you're corrupting memory here.
You should use rctx here too.
+if (req-assoclen + req-cryptlen == 0) {
+scatterwalk_map_and_copy(ctx-auth_tag, req-dst, 0, authlen,
+ 1);
+return 0;
+}
How can this be right? Did you enable the selftest?
Cheers,
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: akcipher: continuous memory for input/output
On Wed, Jul 08, 2015 at 05:54:35PM +0200, Stephan Mueller wrote: But IIRC, there are systems out there which perform a full hybrid asym operation. Without having checked in detail, I believe this is true for IBM cryptoexpress or Cavium cards. Such systems won't be using the akcipher interface even if we decided to support them. As akcipher is only meant to support the underlying cipher, not the whole system. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/14] crypto: aead - Phase oute seqniv
On Thu, Jul 09, 2015 at 01:38:07PM +0200, Stephan Mueller wrote: Actually, I found a problem that I have overlooked initally: rfc4106-gcm-aesni causes a problem. For encryption/decryption with the same tests for other rfc4106 implementations, I get an EINVAL. Did you update your test vectors? The AD must now include the IV. This is the reason I disabled the AEAD interface in 4.2 by requiring any exported AEAD algorithm to carry the CRYPTO_ALG_AEAD_NEW flag. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/14] crypto: aead - Phase oute seqniv
Am Freitag, 10. Juli 2015, 21:39:22 schrieb Herbert Xu: Hi Herbert, On Thu, Jul 09, 2015 at 01:38:07PM +0200, Stephan Mueller wrote: Actually, I found a problem that I have overlooked initally: rfc4106-gcm-aesni causes a problem. For encryption/decryption with the same tests for other rfc4106 implementations, I get an EINVAL. Did you update your test vectors? The AD must now include the IV. This is the reason I disabled the AEAD interface in 4.2 by requiring any exported AEAD algorithm to carry the CRYPTO_ALG_AEAD_NEW flag. I actually did not. But it works with the gcm equivalents as well as the C version of RFC4106. Only rfc4106-gcm-aesni is affected. But I will update the invocation. Thanks Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/14] crypto: aead - Phase oute seqniv
Am Freitag, 10. Juli 2015, 21:38:02 schrieb Herbert Xu: Hi Herbert, On Thu, Jul 09, 2015 at 12:19:53PM +0200, Stephan Mueller wrote: All GCM implementations available on recent Intel systems successfully tested (i.e NX and CAAM not tested). Just to clarify: from a caller's perspective, using seqniv(rfc4106(gcm(aes))) is still the right invocation? Or shall I now use seqiv? You should use seqiv from now on. But I should update the patches so that seqniv is not visible to user-space. In this case, wouldn't xfrm_algo.c need to be changed too? Cheers, Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] crypto: qat - add MMP FW support to accel engine
Add code that loads the MMP firmware
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
drivers/crypto/qat/qat_common/adf_accel_devices.h |2 +
drivers/crypto/qat/qat_common/adf_accel_engine.c | 42 ++--
.../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c |1
.../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h |2 +
4 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_accel_devices.h
b/drivers/crypto/qat/qat_common/adf_accel_devices.h
index 91c969e..45db8d5 100644
--- a/drivers/crypto/qat/qat_common/adf_accel_devices.h
+++ b/drivers/crypto/qat/qat_common/adf_accel_devices.h
@@ -152,6 +152,7 @@ struct adf_hw_device_data {
void (*exit_arb)(struct adf_accel_dev *accel_dev);
void (*enable_ints)(struct adf_accel_dev *accel_dev);
const char *fw_name;
+ const char *fw_mmp_name;
uint32_t pci_dev_id;
uint32_t fuses;
uint32_t accel_capabilities_mask;
@@ -185,6 +186,7 @@ struct icp_qat_fw_loader_handle;
struct adf_fw_loader_data {
struct icp_qat_fw_loader_handle *fw_loader;
const struct firmware *uof_fw;
+ const struct firmware *mmp_fw;
};
struct adf_accel_dev {
diff --git a/drivers/crypto/qat/qat_common/adf_accel_engine.c
b/drivers/crypto/qat/qat_common/adf_accel_engine.c
index fdda8e7..20b08bd 100644
--- a/drivers/crypto/qat/qat_common/adf_accel_engine.c
+++ b/drivers/crypto/qat/qat_common/adf_accel_engine.c
@@ -55,24 +55,36 @@ int adf_ae_fw_load(struct adf_accel_dev *accel_dev)
{
struct adf_fw_loader_data *loader_data = accel_dev-fw_loader;
struct adf_hw_device_data *hw_device = accel_dev-hw_device;
- void *uof_addr;
- uint32_t uof_size;
+ void *uof_addr, *mmp_addr;
+ u32 uof_size, mmp_size;
+ if (!hw_device-fw_name)
+ return 0;
+
+ if (request_firmware(loader_data-mmp_fw, hw_device-fw_mmp_name,
+accel_dev-accel_pci_dev.pci_dev-dev)) {
+ dev_err(GET_DEV(accel_dev), Failed to load MMP firmware %s\n,
+ hw_device-fw_mmp_name);
+ return -EFAULT;
+ }
if (request_firmware(loader_data-uof_fw, hw_device-fw_name,
accel_dev-accel_pci_dev.pci_dev-dev)) {
- dev_err(GET_DEV(accel_dev), Failed to load firmware %s\n,
+ dev_err(GET_DEV(accel_dev), Failed to load UOF firmware %s\n,
hw_device-fw_name);
- return -EFAULT;
+ goto out_err;
}
uof_size = loader_data-uof_fw-size;
uof_addr = (void *)loader_data-uof_fw-data;
+ mmp_size = loader_data-mmp_fw-size;
+ mmp_addr = (void *)loader_data-mmp_fw-data;
+ qat_uclo_wr_mimage(loader_data-fw_loader, mmp_addr, mmp_size);
if (qat_uclo_map_uof_obj(loader_data-fw_loader, uof_addr, uof_size)) {
dev_err(GET_DEV(accel_dev), Failed to map UOF\n);
goto out_err;
}
if (qat_uclo_wr_all_uimage(loader_data-fw_loader)) {
- dev_err(GET_DEV(accel_dev), Failed to map UOF\n);
+ dev_err(GET_DEV(accel_dev), Failed to load UOF\n);
goto out_err;
}
return 0;
@@ -85,11 +97,17 @@ out_err:
void adf_ae_fw_release(struct adf_accel_dev *accel_dev)
{
struct adf_fw_loader_data *loader_data = accel_dev-fw_loader;
+ struct adf_hw_device_data *hw_device = accel_dev-hw_device;
+
+ if (!hw_device-fw_name)
+ return;
qat_uclo_del_uof_obj(loader_data-fw_loader);
qat_hal_deinit(loader_data-fw_loader);
release_firmware(loader_data-uof_fw);
+ release_firmware(loader_data-mmp_fw);
loader_data-uof_fw = NULL;
+ loader_data-mmp_fw = NULL;
loader_data-fw_loader = NULL;
}
@@ -99,6 +117,9 @@ int adf_ae_start(struct adf_accel_dev *accel_dev)
struct adf_hw_device_data *hw_data = accel_dev-hw_device;
uint32_t ae_ctr, ae, max_aes = GET_MAX_ACCELENGINES(accel_dev);
+ if (!hw_data-fw_name)
+ return 0;
+
for (ae = 0, ae_ctr = 0; ae max_aes; ae++) {
if (hw_data-ae_mask (1 ae)) {
qat_hal_start(loader_data-fw_loader, ae, 0xFF);
@@ -117,6 +138,9 @@ int adf_ae_stop(struct adf_accel_dev *accel_dev)
struct adf_hw_device_data *hw_data = accel_dev-hw_device;
uint32_t ae_ctr, ae, max_aes = GET_MAX_ACCELENGINES(accel_dev);
+ if (!hw_data-fw_name)
+ return 0;
+
for (ae = 0, ae_ctr = 0; ae max_aes; ae++) {
if (hw_data-ae_mask (1 ae)) {
qat_hal_stop(loader_data-fw_loader, ae, 0xFF);
@@ -143,6 +167,10 @@ static int adf_ae_reset(struct adf_accel_dev *accel_dev,
int ae)
int adf_ae_init(struct adf_accel_dev *accel_dev)
{
struct adf_fw_loader_data *loader_data;
+ struct adf_hw_device_data
[PATCH 0/3] crypto: qat - add RSA support to qat driver
This series adds RSA support to the qat driver. First patch adds the logic in FW loader to load the Modular Math Processor(MMP) firmware to the device's internal memory. Second patch adds logic to load MMP firmware from disk. Third patch adds the actual RSA implementation. It also contains minor cleanup - namely removes unused TRNG rings. Once this is accepted a version of qat_895xcc.bin firmware and the new mmp firmware will follow. --- Pingchao Yang (1): crypto: qat - add support for MMP FW Tadeusz Struk (2): crypto: qat - add MMP FW support to accel engine crypto: qat - Add support for RSA algorithm drivers/crypto/qat/Kconfig |2 drivers/crypto/qat/qat_common/Makefile |1 drivers/crypto/qat/qat_common/adf_accel_devices.h |3 drivers/crypto/qat/qat_common/adf_accel_engine.c | 42 + drivers/crypto/qat/qat_common/adf_common_drv.h | 10 drivers/crypto/qat/qat_common/adf_init.c |4 drivers/crypto/qat/qat_common/icp_qat_fw.h |2 drivers/crypto/qat/qat_common/icp_qat_fw_pke.h | 112 drivers/crypto/qat/qat_common/qat_algs.c |5 drivers/crypto/qat/qat_common/qat_asym_algs.c | 583 drivers/crypto/qat/qat_common/qat_crypto.c | 19 - drivers/crypto/qat/qat_common/qat_crypto.h |2 drivers/crypto/qat/qat_common/qat_hal.c| 13 drivers/crypto/qat/qat_common/qat_uclo.c | 27 - .../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c |7 .../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.h |2 drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 12 17 files changed, 777 insertions(+), 69 deletions(-) create mode 100644 drivers/crypto/qat/qat_common/icp_qat_fw_pke.h create mode 100644 drivers/crypto/qat/qat_common/qat_asym_algs.c -- -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
