Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Wed, 25 Sep 2013, James Bottomley wrote:
I don't get this. Why is it important that current kernel can't
recreate the signature?
The thread model is an attack on the saved information (i.e. the suspend
image) between it being saved by the old kernel and used by the new one.
The important point isn't that the new kernel doesn't have access to
K_{N-1} it's that no-one does: the key is destroyed as soon as the old
kernel terminates however the verification public part P_{N-1} survives.
James,
could you please describe the exact scenario you think that the symmetric
keys aproach doesn't protect against, while the assymetric key aproach
does?
The crucial points, which I believe make the symmetric key aproach work
(and I feel quite embarassed by the fact that I haven't realized this
initially when coming up with the assymetric keys aproach) are:
- the kernel that is performing the actual resumption is trusted in the
secure boot model, i.e. you trust it to perform proper verification
- potentially malicious userspace (which is what we are protecting against
-- malicious root creating fake hibernation image and issuing reboot)
doesn't have access to the symmetric key
--
Jiri Kosina
SUSE Labs
--
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 V4 02/15] asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa
Hi Phil,
First! Thanks for your time to review my patch!
於 一，2013-09-23 於 19:49 +0300，Phil Carmody 提到：
On Sun, Sep 15, 2013 at 08:56:48AM +0800, Lee, Chun-Yi wrote:
Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
first step of signature generation operation (RSASSA-PKCS1-v1_5-SIGN).
This patch is temporary set emLen to pks-k, and temporary set EM to
pks-S for debugging. We will replace the above values to real signature
after implement RSASP1.
The naming of EMSA_PKCS1_v1_5_ENCODE and the variables used in this function
accord PKCS#1 spec but not follow kernel naming convention, it useful when
look
at them with spec.
Reference: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1v2/pkcs1ietffinal.txt
Reference:
http://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf
V2:
You're now at V4.
The V4 is for whole patchset, I didn't do any modify in this patch in
this version.
The version define maybe confuse between separate and whole patchset, I
will avoid it.
- Clean up naming of variable: replace _EM by EM, replace EM by EM_tmp.
- Add comment to EMSA_PKCS1-v1_5-ENCODE function.
Cc: Pavel Machek pa...@ucw.cz
Reviewed-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Lee, Chun-Yi j...@suse.com
---
crypto/asymmetric_keys/rsa.c | 163
+-
include/crypto/public_key.h |2 +
2 files changed, 164 insertions(+), 1 deletions(-)
diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
index 47f3be4..352ba45 100644
--- a/crypto/asymmetric_keys/rsa.c
+++ b/crypto/asymmetric_keys/rsa.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/kernel.h
#include linux/slab.h
+#include crypto/hash.h
#include public_key.h
#include private_key.h
@@ -152,6 +153,132 @@ static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
}
/*
+ * EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2]
+ * @M: message to be signed, an octet string
+ * @emLen: intended length in octets of the encoded message
+ * @hash_algo: hash function (option)
+ * @hash: true means hash M, otherwise M is already a digest
+ * @EM: encoded message, an octet string of length emLen
+ *
+ * This function is a implementation of the EMSA-PKCS1-v1_5 encoding
operation
+ * in RSA PKCS#1 spec. It used by the signautre generation operation of
+ * RSASSA-PKCS1-v1_5 to encode message M to encoded message EM.
+ *
+ * The variables used in this function accord PKCS#1 spec but not follow
kernel
+ * naming convention, it useful when look at them with spec.
+ */
+static int EMSA_PKCS1_v1_5_ENCODE(const u8 *M, size_t emLen,
+ enum pkey_hash_algo hash_algo, const bool hash,
+ u8 **EM, struct public_key_signature *pks)
+{
+ u8 *digest;
+ struct crypto_shash *tfm;
+ struct shash_desc *desc;
+ size_t digest_size, desc_size;
+ size_t tLen;
+ u8 *T, *PS, *EM_tmp;
+ int i, ret;
+
+ pr_info(EMSA_PKCS1_v1_5_ENCODE start\n);
+
+ if (!RSA_ASN1_templates[hash_algo].data)
+ ret = -ENOTSUPP;
...
+ else
+ pks-pkey_hash_algo = hash_algo;
+
+ /* 1) Apply the hash function to the message M to produce a hash value
H */
+ tfm = crypto_alloc_shash(pkey_hash_algo[hash_algo], 0, 0);
+ if (IS_ERR(tfm))
+ return (PTR_ERR(tfm) == -ENOENT) ? -ENOPKG : PTR_ERR(tfm);
+
+ desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
+ digest_size = crypto_shash_digestsize(tfm);
+
+ ret = -ENOMEM;
The earlier ret = -ENOTSUPP; is either unused because you return at the
IS_ERR,
or unused because you overwrite it here. I'm a little disappointed that
the compiler didn't recognise that something was assigned to a value that
is never used.
Phil
Yes, Dmitry also pointed out this issue, I should not go on the hash
process if the hash algorithm didn't support.
I will change fix this problem in next version.
Thanks a lot!
Joey Lee
--
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 V4 13/15] Hibernate: introduced SNAPSHOT_SIG_HASH config for select hash algorithm
Hi! On Sun 2013-09-15 08:56:59, Lee, Chun-Yi wrote: This patch introduced SNAPSHOT_SIG_HASH config for user to select which hash algorithm will be used during signature generation of snapshot. This series is big enough already... and who is going to test it? The hash config not just for testing, it's relate to the performance and secure between different hash algorithms. I'm not saying it is for testing. I'm saying that selection makes testing harder. There have person raised in LPC say he don't like SHA algorithm. Well, I don't like the config option. There's no need to make hash configurable. Just select one that works. SHA1 has good performance, and SHA512 has better security, which one you like it? Use SHA1. It is completely adequate for what you are trying to do. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker,
i.e. when communication happens over a network.
Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero value as soon as a mismatch is found. E.g,
on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
and up to ~850 cyc for a full match (cold). This early-return behavior
can leak timing information as a side channel, allowing an attacker to
iteratively guess the correct result.
This patch adds a new method crypto_memneq (memory not equal to each
other) to the crypto API that compares memory areas of the same length
in roughly constant time (cache misses could change the timing, but
since they don't reveal information about the content of the strings
being compared, they are effectively benign). Iow, best and worst case
behaviour take the same amount of time to complete (in contrast to
memcmp).
Note that crypto_memneq (unlike memcmp) can only be used to test for
equality or inequality, NOT for lexicographical order. This, however,
is not an issue for its use-cases within the crypto API.
We tried to locate all of the places in the crypto API where memcmp was
being used for authentication or integrity checking, and convert them
over to crypto_memneq.
crypto_memneq is declared noinline, placed in its own source file,
and compiled with optimizations that might increase code size disabled
(Os) because a smart compiler (or LTO) might notice that the return
value is always compared against zero/nonzero, and might then
reintroduce the same early-return optimization that we are trying to
avoid.
Using #pragma or __attribute__ optimization annotations of the code
for disabling optimization was avoided as it seems to be considered
broken or unmaintained for long time in GCC [1]. Therefore, we work
around that by specifying the compile flag for memneq.o directly in
the Makefile. We found that this seems to be most appropriate.
As we use (Os), this patch also provides a loop-free fast-path for
frequently used 16 byte digests. Similarly to kernel library string
functions, leave an option for future even further optimized architecture
specific assembler implementations.
This was a joint work of James Yonan and Daniel Borkmann. Also thanks
for feedback from Florian Weimer on this and earlier proposals [2].
[1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
[2] https://lkml.org/lkml/2013/2/10/131
Signed-off-by: James Yonan ja...@openvpn.net
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Cc: Florian Weimer f...@deneb.enyo.de
---
crypto/Makefile | 7 ++-
crypto/asymmetric_keys/rsa.c | 5 +-
crypto/authenc.c | 6 +-
crypto/authencesn.c | 8 +--
crypto/ccm.c | 4 +-
crypto/gcm.c | 2 +-
crypto/memneq.c | 138 +++
include/crypto/algapi.h | 18 +-
8 files changed, 174 insertions(+), 14 deletions(-)
create mode 100644 crypto/memneq.c
diff --git a/crypto/Makefile b/crypto/Makefile
index 2d5ed08..b88cdf0 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -2,8 +2,13 @@
# Cryptographic API
#
+# memneq MUST be built with -Os or -O0 to prevent early-return optimizations
+# that will defeat memneq's actual purpose to prevent timing attacks.
+CFLAGS_REMOVE_memneq.o := -O1 -O2 -O3
+CFLAGS_memneq.o := -Os
+
obj-$(CONFIG_CRYPTO) += crypto.o
-crypto-y := api.o cipher.o compress.o
+crypto-y := api.o cipher.o compress.o memneq.o
obj-$(CONFIG_CRYPTO_WORKQUEUE) += crypto_wq.o
diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
index 4a6a069..1912b9b 100644
--- a/crypto/asymmetric_keys/rsa.c
+++ b/crypto/asymmetric_keys/rsa.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/kernel.h
#include linux/slab.h
+#include crypto/algapi.h
#include public_key.h
MODULE_LICENSE(GPL);
@@ -189,12 +190,12 @@ static int RSA_verify(const u8 *H, const u8 *EM, size_t
k, size_t hash_size,
}
}
- if (memcmp(asn1_template, EM + T_offset, asn1_size) != 0) {
+ if (crypto_memneq(asn1_template, EM + T_offset, asn1_size) != 0) {
kleave( = -EBADMSG [EM[T] ASN.1 mismatch]);
return -EBADMSG;
}
- if (memcmp(H, EM + T_offset + asn1_size, hash_size) != 0) {
+ if (crypto_memneq(H, EM + T_offset + asn1_size, hash_size) != 0) {
kleave( = -EKEYREJECTED [EM[T] hash mismatch]);
return -EKEYREJECTED;
}
diff --git a/crypto/authenc.c b/crypto/authenc.c
index ffce19d..2b3f4ab 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -188,7 +188,7 @@ static void authenc_verify_ahash_update_done(struct
crypto_async_request *areq,
scatterwalk_map_and_copy(ihash, areq_ctx-sg, areq_ctx-cryptlen,
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
於 四，2013-09-26 於 10:19 +0800，joeyli 提到： 於 三，2013-09-25 於 17:25 -0400，Alan Stern 提到： On Wed, 25 Sep 2013, David Howells wrote: I have pushed some keyrings patches that will likely affect this to: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-devel I intend to ask James to pull these into his next branch. If he's happy to do so, I can look at pulling at least your asymmetric keys patch on top of them. This suggests a point that I raised at the Linux Plumbers conference: Why are asymmetric keys used for verifying the hibernation image? It seems that a symmetric key would work just as well. And it would be a lot quicker to generate, because it wouldn't need any high-precision integer computations. Alan Stern Per my understood, it's like add salt to snapshot when generate signature, then remove the salt when store the snapshot to swap. (or pass snapshot to userland). Let me explain the symmetric key solution base on my understand: + EFI stub kernel generate a hash value from a random seed, then store it to EFi boot varaible. It should protected by UEFI secure boot environment. + When hibernate launched: - Kernel create the snapshot image of memory. It's included the random hash value(salt) that generated in EFI stub stage. - Then kernel hash the snapshot image, put the hash to snapshot header, just like current asymmetric keys solution. - Kernel erase the salt in snapshot image before it go to swap or pass to userspace tool. + When hibernate resume: - Kernel or userspace tool load the snapshot(without salt) from swap to temporary memory space. - Kernel fill the salt back to snapshot image in memory, hash it. - Kernel compare the hash with the hash that put in snapshot header. - Verification done! The follow-up action as current solution. Please current me if I missed anything. Thanks a lot! Joey Lee For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Thanks Joey Lee -- 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
IV generation in geode-aes
Hi all, I could'nt understand the mechanism of IV generation in geode-aes. Can someone explain it in easy to understand manner? Thanks a lot. -- 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 39/51] DMA-API: others: use dma_set_coherent_mask()
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using the correct API.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/ata/pata_ixp4xx_cf.c |5 -
drivers/gpu/drm/exynos/exynos_drm_drv.c |6 +-
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +++--
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/pata_ixp4xx_cf.c b/drivers/ata/pata_ixp4xx_cf.c
index 1ec53f8..ddf470c 100644
--- a/drivers/ata/pata_ixp4xx_cf.c
+++ b/drivers/ata/pata_ixp4xx_cf.c
@@ -144,6 +144,7 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct ixp4xx_pata_data *data = dev_get_platdata(pdev-dev);
+ int ret;
cs0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
cs1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -157,7 +158,9 @@ static int ixp4xx_pata_probe(struct platform_device *pdev)
return -ENOMEM;
/* acquire resources and fill host */
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
data-cs0 = devm_ioremap(pdev-dev, cs0-start, 0x1000);
data-cs1 = devm_ioremap(pdev-dev, cs1-start, 0x1000);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..81192d0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -286,7 +286,11 @@ static struct drm_driver exynos_drm_driver = {
static int exynos_drm_platform_probe(struct platform_device *pdev)
{
- pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ int ret;
+
+ ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
return drm_platform_init(exynos_drm_driver, pdev);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
index acf6678..701c4c1 100644
--- a/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
+++ b/drivers/gpu/drm/omapdrm/omap_dmm_tiler.c
@@ -664,8 +664,9 @@ static int omap_dmm_probe(struct platform_device *dev)
}
/* set dma mask for device */
- /* NOTE: this is a workaround for the hwmod not initializing properly */
- dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto fail;
Tested with omapdrm on omap4 panda es board.
Thanks,
Archit
--
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 1/3] crypto: Fully restore ahash request before completing
When finishing the ahash request, the ahash_op_unaligned_done() will call complete() on the request. Yet, this will not call the correct complete callback. The correct complete callback was previously stored in the requests' private data, as seen in ahash_op_unaligned(). This patch restores the correct complete callback and .data field of the request before calling complete() on it. Signed-off-by: Marek Vasut ma...@denx.de Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net --- crypto/ahash.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/crypto/ahash.c b/crypto/ahash.c index 793a27f..a92dc38 100644 --- a/crypto/ahash.c +++ b/crypto/ahash.c @@ -213,7 +213,10 @@ static void ahash_op_unaligned_done(struct crypto_async_request *req, int err) ahash_op_unaligned_finish(areq, err); - complete(data, err); + areq-base.complete = complete; + areq-base.data = data; + + complete(areq-base, err); } static int ahash_op_unaligned(struct ahash_request *req, -- 1.8.4.rc3 -- 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 3/3] ARM: mxs: dts: Enable DCP for MXS
Enable the DCP by default on both i.MX23 and i.MX28.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Shawn Guo shawn@linaro.org
To: linux-crypto@vger.kernel.org
---
arch/arm/boot/dts/imx23.dtsi | 4 +++-
arch/arm/boot/dts/imx28.dtsi | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 87faa6e..0630a9a 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -337,8 +337,10 @@
};
dcp@80028000 {
+ compatible = fsl,mxs-dcp;
reg = 0x80028000 0x2000;
- status = disabled;
+ interrupts = 53 54;
+ status = okay;
};
pxp@8002a000 {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 918d419..8b5ad60 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -782,9 +782,10 @@
};
dcp: dcp@80028000 {
+ compatible = fsl,mxs-dcp;
reg = 0x80028000 0x2000;
- interrupts = 52 53 54;
- compatible = fsl-dcp;
+ interrupts = 53 54;
+ status = okay;
};
pxp: pxp@8002a000 {
--
1.8.4.rc3
--
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] ARM: mxs: crypto: Add Freescale MXS DCP driver
Add support for the MXS DCP block. The driver currently supports
SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
CRC32 is not yet supported.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
---
drivers/crypto/Kconfig | 17 +
drivers/crypto/Makefile |1 +
drivers/crypto/mxs-dcp.c | 1082 ++
3 files changed, 1100 insertions(+)
create mode 100644 drivers/crypto/mxs-dcp.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index f4fd837..4aa6686 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -399,4 +399,21 @@ config CRYPTO_DEV_ATMEL_SHA
To compile this driver as a module, choose M here: the module
will be called atmel-sha.
+config CRYPTO_DEV_MXS_DCP
+ tristate Support for Freescale MXS DCP
+ depends on ARCH_MXS
+ select CRYPTO_SHA1
+ select CRYPTO_SHA256
+ select CRYPTO_CBC
+ select CRYPTO_ECB
+ select CRYPTO_AES
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_ALGAPI
+ help
+ The Freescale i.MX23/i.MX28 has SHA1/SHA256 and AES128 CBC/ECB
+ co-processor on the die.
+
+ To compile this driver as a module, choose M here: the module
+ will be called atmel-sha.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index b4946dd..56cce04 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_CRYPTO_DEV_NX) += nx/
obj-$(CONFIG_CRYPTO_DEV_ATMEL_AES) += atmel-aes.o
obj-$(CONFIG_CRYPTO_DEV_ATMEL_TDES) += atmel-tdes.o
obj-$(CONFIG_CRYPTO_DEV_ATMEL_SHA) += atmel-sha.o
+obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
new file mode 100644
index 000..c2b35c7
--- /dev/null
+++ b/drivers/crypto/mxs-dcp.c
@@ -0,0 +1,1082 @@
+/*
+ * Freescale i.MX23/i.MX28 Data Co-Processor driver
+ *
+ * Copyright (C) 2013 Marek Vasut ma...@denx.de
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/crypto.h
+#include linux/dma-mapping.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/kthread.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/stmp_device.h
+
+#include crypto/aes.h
+#include crypto/sha.h
+#include crypto/internal/hash.h
+
+#define DCP_MAX_CHANS 4
+#define DCP_BUF_SZ PAGE_SIZE
+
+/* DCP DMA descriptor. */
+struct dcp_dma_desc {
+ uint32_tnext_cmd_addr;
+ uint32_tcontrol0;
+ uint32_tcontrol1;
+ uint32_tsource;
+ uint32_tdestination;
+ uint32_tsize;
+ uint32_tpayload;
+ uint32_tstatus;
+};
+
+/* Coherent aligned block for bounce buffering. */
+struct dcp_coherent_block {
+ uint8_t aes_in_buf[DCP_BUF_SZ];
+ uint8_t aes_out_buf[DCP_BUF_SZ];
+ uint8_t sha_in_buf[DCP_BUF_SZ];
+
+ uint8_t aes_key[2 * AES_KEYSIZE_128];
+ uint8_t sha_digest[SHA256_DIGEST_SIZE];
+
+ struct dcp_dma_desc desc[DCP_MAX_CHANS];
+};
+
+struct dcp {
+ struct device *dev;
+ void __iomem*base;
+
+ uint32_tcaps;
+
+ struct dcp_coherent_block *coh;
+ dma_addr_t coh_phys;
+
+ struct completion completion[DCP_MAX_CHANS];
+ struct mutexmutex[DCP_MAX_CHANS];
+ struct task_struct *thread[DCP_MAX_CHANS];
+ struct crypto_queue queue[DCP_MAX_CHANS];
+};
+
+enum dcp_chan {
+ DCP_CHAN_HASH_SHA = 0,
+ DCP_CHAN_CRYPTO = 2,
+};
+
+struct dcp_async_ctx {
+ /* Common context */
+ enum dcp_chan chan;
+ uint32_tfill;
+
+ /* SHA Hash-specific context */
+ struct mutexmutex;
+ uint32_talg;
+ unsigned inthot:1;
+
+ /* Crypto-specific context */
+ unsigned intenc:1;
+ unsigned intecb:1;
+ struct crypto_ablkcipher*fallback;
+ unsigned intkey_len;
+ uint8_t key[AES_KEYSIZE_128];
+};
+
+struct dcp_sha_req_ctx {
+ unsigned intinit:1;
+ unsigned intfini:1;
+};
+
+/*
+ * There can even be only one instance of the MXS DCP due to the
+ * design of Linux Crypto API.
+ */
+static struct dcp *global_sdcp;
Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Hi Marek, On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut ma...@denx.de wrote: Add support for the MXS DCP block. The driver currently supports SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard CRC32 is not yet supported. Signed-off-by: Marek Vasut ma...@denx.de Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net --- drivers/crypto/Kconfig | 17 + drivers/crypto/Makefile |1 + drivers/crypto/mxs-dcp.c | 1082 ++ What about the existing DCP driver at drivers/crypto/dcp.c ? Why do we need to have two drivers for the same IP block? It looks confusing to have both. Regards, Fabio Estevam -- 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 3/3] ARM: mxs: dts: Enable DCP for MXS
Hi,
Marek Vasut writes:
Enable the DCP by default on both i.MX23 and i.MX28.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Shawn Guo shawn@linaro.org
To: linux-crypto@vger.kernel.org
---
arch/arm/boot/dts/imx23.dtsi | 4 +++-
arch/arm/boot/dts/imx28.dtsi | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 87faa6e..0630a9a 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -337,8 +337,10 @@
};
dcp@80028000 {
+ compatible = fsl,mxs-dcp;
reg = 0x80028000 0x2000;
- status = disabled;
+ interrupts = 53 54;
+ status = okay;
};
AFAICT the policy seems to be that nodes, that are always enabled
don't get a 'status' property at all.
pxp@8002a000 {
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 918d419..8b5ad60 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -782,9 +782,10 @@
};
dcp: dcp@80028000 {
+ compatible = fsl,mxs-dcp;
reg = 0x80028000 0x2000;
- interrupts = 52 53 54;
- compatible = fsl-dcp;
What about drivers/crypto/dcp.c that is currently using this property?
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
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: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
Hi! For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. Actually... Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. And that may even be useful for non-secure-boot people, as it ensures you boot right image after resume, boot it just once, etc... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Dear Fabio Estevam, Hi Marek, On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut ma...@denx.de wrote: Add support for the MXS DCP block. The driver currently supports SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard CRC32 is not yet supported. Signed-off-by: Marek Vasut ma...@denx.de Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net --- drivers/crypto/Kconfig | 17 + drivers/crypto/Makefile |1 + drivers/crypto/mxs-dcp.c | 1082 ++ What about the existing DCP driver at drivers/crypto/dcp.c ? I was not aware of that one. Why do we need to have two drivers for the same IP block? It looks confusing to have both. Sure, I agree. I reviewed the one in mainline just now and I see some deficiencies of the dcp.c driver: 1) It only supports AES_CBC (mine does support AES_ECB, AES_CBC, SHA1 and SH256) 2) The driver was apparently never ran behind anyone working with MXS. ie.: - Restarting the DCP block is not done via mxs_reset_block() - The DT name is not fsl,dcp or fsl,mxs-dcp as other MXS drivers 3) What are those ugly new IOCTLs in the dcp.c driver? 4) The VMI IRQ is never used, yet it even calls the IRQ handler, this is bogus - The DCP always triggers the dcp_irq upon DMA completion - VMI IRQ is not handled in the handler at all as I see it 5) The IRQ handler can't use usual completion() in the driver because that'd trigger scheduling while atomic oops, yes? Finally, because the dcp.c driver only supports AES128 CBC, it depends on kernel _always_ passing the DCP scatterlist such that each of it's elements is 16-bytes long. If each of the elements is 16 bytes, there is no problem and the DCP will operate correctly. That is because the DCP has the following limitations: - For AES128, each buffer in the DMA chain must be multiple of 16 bytes. - For SHA1/SHA256, each buffer in the DMA chain must by multiple of 64 bytes BUT only the last buffer in the DMA chain can be shorter. So, in the AES128 case, if the hardware is passed two (4 bytes + 12 bytes for example) DMA descriptors instead of single 16 bytes descriptor, the DCP will simply stall or produce incorrect result. This can happen if the user of the async crypto API passes such a scatterlist. It is true this is not caught by the in-kernel crypto tests, because they mostly trigger the software fallback in this driver, since this driver only supports 16 byte key (klen == 16 , see crypto/testmgr.h). It can be triggered by modifying the crypto tests so that they pass two buffers, multiple of 16 bytes in total, but each of them not multiple of 16 bytes. I ran into many such problems when I was developing this driver I submitted here, I managed to trigger those by running the Cryptodev [1] tests [2] against this driver as well as testing the performance of this driver via Cryptodev/OpenSSL combination: $ openssl speed sha1 $ openssl speed sha256 $ openssl speed aes-128-cbc I also measured the performance via OpenSSL encryption/decryption. On larger files, the performance of encryption/decryption via DCP, even with fixups for unaligned buffers and the overhead of userspace-kernel-userspace switches due to cryptodev is still higher than software implementation: $ time openssl enc -aes-128-ecb -in $IFILE -out $OFILE -k test -nosalt $ time openssl enc -d -aes-128-ecb -in $OFILE -out $DFILE -k test -nosalt Also, since OpenSSH uses OpenSSL, this helped my testing too. [1] http://cryptodev-linux.org/ [2] https://github.com/nmav/cryptodev-linux/tree/master/tests Best regards, Marek Vasut -- 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 3/3] ARM: mxs: dts: Enable DCP for MXS
Dear Lothar Waßmann,
Hi,
Marek Vasut writes:
Enable the DCP by default on both i.MX23 and i.MX28.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Shawn Guo shawn@linaro.org
To: linux-crypto@vger.kernel.org
---
arch/arm/boot/dts/imx23.dtsi | 4 +++-
arch/arm/boot/dts/imx28.dtsi | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index 87faa6e..0630a9a 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -337,8 +337,10 @@
};
dcp@80028000 {
+ compatible = fsl,mxs-dcp;
reg = 0x80028000 0x2000;
- status = disabled;
+ interrupts = 53 54;
+ status = okay;
};
AFAICT the policy seems to be that nodes, that are always enabled
don't get a 'status' property at all.
This is new to me, thanks for letting me know!
As for the current DCP, please see my reply to Fabio in this thread.
Best regards,
Marek Vasut
--
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 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Hi Marek,
some small comments below.
Marek Vasut writes:
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
new file mode 100644
index 000..c2b35c7
--- /dev/null
+++ b/drivers/crypto/mxs-dcp.c
[...]
+/* AES 128 ECB and AES 128 CBC */
+static struct crypto_alg dcp_aes_algs[] = {
+ [0] = {
+ .cra_name = ecb(aes),
+ .cra_driver_name= ecb-aes-dcp,
+ .cra_priority = 400,
+ .cra_alignmask = 15,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_init = mxs_dcp_aes_fallback_init,
+ .cra_exit = mxs_dcp_aes_fallback_exit,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct dcp_async_ctx),
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize= AES_MIN_KEY_SIZE,
+ .max_keysize= AES_MAX_KEY_SIZE,
+ .setkey = mxs_dcp_aes_setkey,
+ .encrypt= mxs_dcp_aes_ecb_encrypt,
+ .decrypt= mxs_dcp_aes_ecb_decrypt
+ }
missing ',' after '}'
+ }
dto.
+ },
+ [1] = {
+ .cra_name = cbc(aes),
+ .cra_driver_name= cbc-aes-dcp,
+ .cra_priority = 400,
+ .cra_alignmask = 15,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_init = mxs_dcp_aes_fallback_init,
+ .cra_exit = mxs_dcp_aes_fallback_exit,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct dcp_async_ctx),
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize= AES_MIN_KEY_SIZE,
+ .max_keysize= AES_MAX_KEY_SIZE,
+ .setkey = mxs_dcp_aes_setkey,
+ .encrypt= mxs_dcp_aes_cbc_encrypt,
+ .decrypt= mxs_dcp_aes_cbc_decrypt,
+ .ivsize = AES_BLOCK_SIZE,
+ }
dto.
+ }
dto.
+ },
+};
+
+/* SHA1 */
+static struct ahash_alg dcp_sha1_alg = {
+ .init = dcp_sha_init,
+ .update = dcp_sha_update,
+ .final = dcp_sha_final,
+ .finup = dcp_sha_finup,
+ .digest = dcp_sha_digest,
+ .halg = {
+ .digestsize = SHA1_DIGEST_SIZE,
+ .base = {
+ .cra_name = sha1,
+ .cra_driver_name= sha1-dcp,
+ .cra_priority = 400,
+ .cra_alignmask = 63,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ .cra_blocksize = SHA1_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct dcp_async_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_init = dcp_sha_cra_init,
+ .cra_exit = dcp_sha_cra_exit,
+ }
dto.
+ }
dto.
+};
+
+/* SHA256 */
+static struct ahash_alg dcp_sha256_alg = {
+ .init = dcp_sha_init,
+ .update = dcp_sha_update,
+ .final = dcp_sha_final,
+ .finup = dcp_sha_finup,
+ .digest = dcp_sha_digest,
+ .halg = {
+ .digestsize = SHA256_DIGEST_SIZE,
+ .base = {
+ .cra_name = sha256,
+ .cra_driver_name= sha256-dcp,
+ .cra_priority = 400,
+ .cra_alignmask = 63,
+ .cra_flags = CRYPTO_ALG_ASYNC,
+ .cra_blocksize = SHA256_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct dcp_async_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_init = dcp_sha_cra_init,
+ .cra_exit = dcp_sha_cra_exit,
+ }
dto.
+ }
dto.
+static const struct of_device_id mxs_dcp_dt_ids[] = {
+
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote: For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. Well, yes, one could skip the CRC when the signing is enabled to gain a little speedup. Actually... Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. First, there is no encryption going on. Only doing a HMAC (digest (hash) using a key) of the image. Second, since NVRAM is accessible through efivarsfs, storing the hash in NVRAM wouldn't prevent an attacker from modifying the hash to match a modified image. There is a reason why the key for the HMAC is stored in the NVRAM in a BootServices variable that isn't accessible from the OS and is write-protected on hardware level from the OS. And that may even be useful for non-secure-boot people, as it ensures you boot right image after resume, boot it just once, etc... The HMAC approach isn't much more complicated, and it gives you all these benefits even with secure boot disabled. -- Vojtech Pavlik Director SUSE Labs -- 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: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 02:21:23PM +0200, Michal Marek wrote: Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. I think that part of the exercise is to minimize the number of writes to the NVRAM. The hash changes with every hibernation, obviously. The key should, too. -- Vojtech Pavlik Director SUSE Labs -- 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 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Hi Marek, + To compile this driver as a module, choose M here: the module + will be called atmel-sha. This is probably wrong? -- Veli-Pekka Peltola -- 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 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut ma...@denx.de wrote:
+config CRYPTO_DEV_MXS_DCP
+ tristate Support for Freescale MXS DCP
+ depends on ARCH_MXS
+ select CRYPTO_SHA1
+ select CRYPTO_SHA256
+ select CRYPTO_CBC
+ select CRYPTO_ECB
+ select CRYPTO_AES
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_ALGAPI
+ help
+ The Freescale i.MX23/i.MX28 has SHA1/SHA256 and AES128 CBC/ECB
+ co-processor on the die.
+
+ To compile this driver as a module, choose M here: the module
+ will be called atmel-sha.
Actually it will be called 'mxs-dcp'.
+ * There can even be only one instance of the MXS DCP due to the
+ * design of Linux Crypto API.
Is this true? Usually we don't want to create a global struct.
+
+/* AES 128 ECB and AES 128 CBC */
+static struct crypto_alg dcp_aes_algs[] = {
+ [0] = {
No need for explicitely add this [0]
+ .cra_name = ecb(aes),
+ .cra_driver_name= ecb-aes-dcp,
+ .cra_priority = 400,
+ .cra_alignmask = 15,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_init = mxs_dcp_aes_fallback_init,
+ .cra_exit = mxs_dcp_aes_fallback_exit,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct dcp_async_ctx),
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize= AES_MIN_KEY_SIZE,
+ .max_keysize= AES_MAX_KEY_SIZE,
+ .setkey = mxs_dcp_aes_setkey,
+ .encrypt= mxs_dcp_aes_ecb_encrypt,
+ .decrypt= mxs_dcp_aes_ecb_decrypt
+ }
+ }
+ },
+ [1] = {
Same here.
+static int mxs_dcp_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct dcp *sdcp = NULL;
+ int i, ret;
+
+ struct resource *iores;
+ int dcp_vmi_irq, dcp_irq;
+
+ mutex_lock(global_mutex);
+ if (global_sdcp) {
+ dev_err(dev, Only one DCP instance allowed!\n);
+ ret = -ENODEV;
+ goto err_mutex;
+ }
+
+ iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ dcp_vmi_irq = platform_get_irq(pdev, 0);
+ dcp_irq = platform_get_irq(pdev, 1);
+ if (!iores || dcp_vmi_irq 0 || dcp_irq 0) {
No need to check for !iores here.
You use it inside devm_ioremap_resource, which already does this checking.
+ /*
+* We do not enable context switching. Give the context buffer a
+* pointer to an illegal address so if context switching is
+* inadvertantly enabled, the DCP will return an error instead of
+* trashing good memory. The DCP DMA cannot access ROM, so any ROM
+* address will do.
+*/
+ writel(0x, sdcp-base + MXS_DCP_CONTEXT);
Can you use a define instead of this hardcoded number?
+static int mxs_dcp_remove(struct platform_device *pdev)
+{
+ struct dcp *sdcp;
+ int i;
+
+ sdcp = platform_get_drvdata(pdev);
+
+ kthread_stop(sdcp-thread[DCP_CHAN_HASH_SHA]);
+ kthread_stop(sdcp-thread[DCP_CHAN_CRYPTO]);
+
+ platform_set_drvdata(pdev, NULL);
+
+ dma_free_coherent(sdcp-dev, sizeof(struct dcp_coherent_block),
+ sdcp-coh, sdcp-coh_phys);
+
+ if (sdcp-caps MXS_DCP_CAPABILITY1_SHA256)
+ crypto_unregister_ahash(dcp_sha256_alg);
+
+ if (sdcp-caps MXS_DCP_CAPABILITY1_SHA1)
+ crypto_unregister_ahash(dcp_sha1_alg);
+
+ if (sdcp-caps MXS_DCP_CAPABILITY1_AES128) {
+ for (i = ARRAY_SIZE(dcp_aes_algs); i = 0; i--)
+ crypto_unregister_alg(dcp_aes_algs[i]);
+ }
+
+ mutex_lock(global_mutex);
+ global_sdcp = NULL;
+ mutex_unlock(global_mutex);
The order of the resources removal does not look correct here.
It should match the order of the error path in probe.
+
+ return 0;
+}
+
+static const struct of_device_id mxs_dcp_dt_ids[] = {
+ {.compatible = fsl,mxs-dcp, .data = NULL,},
In the other mxs/imx drivers we use:
.compatible = fsl,soc-dcp
You also need to provide a devicetree documentation for this binding.
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, mxs_dcp_dt_ids);
+
+static struct platform_driver mxs_dcp_driver = {
+
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到： Hi! For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. In current kernel design, The crc32 is only for the LZO in-kernel hibernate, doesn't apply to non-compress hibernate and userspace hibernate. Put signature to snapshot header can support any kind of caller that's trigger hibernate. Any userspace hibernate tool will take the snapshot image from kernel, so, we need put the signature(or hash result) to snapshot header before userspace write it to anywhere. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. That speed of hash is calculated from non-compress snapshot image, does not overlap with crc32. Actually... Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. And that may even be useful for non-secure-boot people, as it ensures you boot right image after resume, boot it just once, etc... Pavel The HMAC approach will not encrypt, just put the key of HMAC to boottime variable. If user doesn't enable UEFI secure boot, that's fine, the key of HMAC still cannot access in OS runtime. If user enable UEFI secure boot, then that's better! Because all EFI file will signed by the manufacturers or OSVs to make sure the code is secure, will not pass the key to runtime. Thanks a lot! Joey Lee -- 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: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
於 四，2013-09-26 於 14:22 +0200，Vojtech Pavlik 提到： On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote: For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. Well, yes, one could skip the CRC when the signing is enabled to gain a little speedup. In current kernel, CRC is for check the integrity of LZO compressed image, the purpose is different to check the integrity of snapshot image. So, CRC will not in non-compress hibernate or userspace hibernate code path On the other hand, attacker can easily change the CRC code in the header of LZO hibernate image. Thanks a lot! Joey Lee -- 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 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Dear Veli-Pekka Peltola, Hi Marek, + To compile this driver as a module, choose M here: the module + will be called atmel-sha. This is probably wrong? Certainly. Nice to have you back btw. ;-) Best regards, Marek Vasut -- 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 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver
Hi,
Marek Vasut writes:
Dear Lothar Waßmann,
Hi Marek,
some small comments below.
Marek Vasut writes:
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
new file mode 100644
index 000..c2b35c7
--- /dev/null
+++ b/drivers/crypto/mxs-dcp.c
[...]
+/* AES 128 ECB and AES 128 CBC */
+static struct crypto_alg dcp_aes_algs[] = {
+ [0] = {
+ .cra_name = ecb(aes),
+ .cra_driver_name= ecb-aes-dcp,
+ .cra_priority = 400,
+ .cra_alignmask = 15,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_init = mxs_dcp_aes_fallback_init,
+ .cra_exit = mxs_dcp_aes_fallback_exit,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct dcp_async_ctx),
+ .cra_type = crypto_ablkcipher_type,
+ .cra_module = THIS_MODULE,
+ .cra_u = {
+ .ablkcipher = {
+ .min_keysize= AES_MIN_KEY_SIZE,
+ .max_keysize= AES_MAX_KEY_SIZE,
+ .setkey = mxs_dcp_aes_setkey,
+ .encrypt= mxs_dcp_aes_ecb_encrypt,
+ .decrypt= mxs_dcp_aes_ecb_decrypt
+ }
missing ',' after '}'
Is this a problem? The last ',' is not needed by the C standard.
The problem arises when someone wants to append another item to the
list. Without the comma he has to change two lines which may cause
merge conflicts if two people add different items to the same struct.
That's why we usually have (unnecessary) commas on the last element of
a struct initializer (except when they are meant to be the last
element of course).
Lothar Waßmann
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
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: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, 2013-09-26 at 08:24 +0200, Jiri Kosina wrote:
On Wed, 25 Sep 2013, James Bottomley wrote:
I don't get this. Why is it important that current kernel can't
recreate the signature?
The thread model is an attack on the saved information (i.e. the suspend
image) between it being saved by the old kernel and used by the new one.
The important point isn't that the new kernel doesn't have access to
K_{N-1} it's that no-one does: the key is destroyed as soon as the old
kernel terminates however the verification public part P_{N-1} survives.
James,
could you please describe the exact scenario you think that the symmetric
keys aproach doesn't protect against, while the assymetric key aproach
does?
The crucial points, which I believe make the symmetric key aproach work
(and I feel quite embarassed by the fact that I haven't realized this
initially when coming up with the assymetric keys aproach) are:
- the kernel that is performing the actual resumption is trusted in the
secure boot model, i.e. you trust it to perform proper verification
- potentially malicious userspace (which is what we are protecting against
-- malicious root creating fake hibernation image and issuing reboot)
doesn't have access to the symmetric key
OK, so the scheme is to keep a symmetric key in BS that is passed into
the kernel each time (effectively a secret key) for signing and
validation?
The only two problems I see are
1. The key isn't generational (any compromise obtains it). This
can be fixed by using a set of keys generated on each boot and
passing in both K_{N-1} and K_N
2. No external agency other than the next kernel can do the
validation since the validating key has to be secret
The importance of 2 is just tripwire like detection ... perhaps it
doesn't really matter in a personal computer situation. It would matter
in an enterprise where images are stored and re-used but until servers
have UEFI secure boot, that's not going to be an issue.
James
--
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: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote:
The only two problems I see are
1. The key isn't generational (any compromise obtains it). This
can be fixed by using a set of keys generated on each boot and
passing in both K_{N-1} and K_N
I think this could be easily made optional, leaving the user with choice
of faster or safer boot.
Ideally, the key should be regenerated on each true reboot and kept the
same if it is just a resume. Unfortunately, I don't see a way to
distinguish those before we call ExitBootServices().
The reasoning behind that is that in the case of a kernel compromise, a
suspended-and-resumed kernel will still be compromised, so there is no
value in passing it a new key. A freshly booted kernel, though, should
get a new key, exactly because the attacker could have obtained a key
from the previous, compromised one.
This speeds up the ususal suspend-and-resume cycle, but provides full
security once the user performs a full reboot.
The question that remains is how to tell in advance.
2. No external agency other than the next kernel can do the
validation since the validating key has to be secret
This is true, but as you said, the relevance of this seems to be rather
questionable.
Indeed, it's hard to imagine a scenario that is also valid within the
secure boot threat model.
--
Vojtech Pavlik
Director SUSE Labs
--
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: IV generation in geode-aes
Hi, In geode-aes, there is not any IV generation mechanism. In fact IV is delivered to geode-aes's registered algorithms, from upper layers.For example in case of cbc-aes-geode algorithm, from cbc wrapper (cbc.c) via walk-iv: blkcipher_walk_init(walk, dst, src, nbytes); err = blkcipher_walk_virt(desc, walk); op-iv = walk.iv; ... Regards. On Thu, Sep 19, 2013 at 4:34 PM, Sohail sohailtari...@gmail.com wrote: Hi all, I could'nt understand the mechanism of IV generation in geode-aes. Can someone explain it in easy to understand manner? Thanks a lot. -- 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 -- 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: crypto: crypto_memneq - add equality testing of memory regions w/o timing leaks
Here is the latest iteration of the constant-time memory equality-testing patch: * This patch includes contributions and a signoff from Daniel Borkmann. * Moved the optimization flag -Os (used to prevent early return optimization) into the Makefile after seeing a report that #pragma gcc is considered broken and unmaintained. * Added #ifndef __HAVE_ARCH_CRYPTO_MEMNEQ to accommodate possible future arch-specific asm implementations. * For clarity, separated the size-independent function (__crypto_memneq_generic) from the fast-path optimization for 16 bytes (__crypto_memneq_16) using a switch so that future fast-path data widths can be easily added. * Reduce the number of #ifdefs by using sizeof(unsigned long) instead of BITS_PER_LONG. * Shortened the public function name to crypto_memneq. James On 26/09/2013 02:20, James Yonan wrote: When comparing MAC hashes, AEAD authentication tags, or other hash values in the context of authentication or integrity checking, it is important not to leak timing information to a potential attacker, i.e. when communication happens over a network. Bytewise memory comparisons (such as memcmp) are usually optimized so that they return a nonzero value as soon as a mismatch is found. E.g, on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch and up to ~850 cyc for a full match (cold). This early-return behavior can leak timing information as a side channel, allowing an attacker to iteratively guess the correct result. This patch adds a new method crypto_memneq (memory not equal to each other) to the crypto API that compares memory areas of the same length in roughly constant time (cache misses could change the timing, but since they don't reveal information about the content of the strings being compared, they are effectively benign). Iow, best and worst case behaviour take the same amount of time to complete (in contrast to memcmp). Note that crypto_memneq (unlike memcmp) can only be used to test for equality or inequality, NOT for lexicographical order. This, however, is not an issue for its use-cases within the crypto API. We tried to locate all of the places in the crypto API where memcmp was being used for authentication or integrity checking, and convert them over to crypto_memneq. crypto_memneq is declared noinline, placed in its own source file, and compiled with optimizations that might increase code size disabled (Os) because a smart compiler (or LTO) might notice that the return value is always compared against zero/nonzero, and might then reintroduce the same early-return optimization that we are trying to avoid. Using #pragma or __attribute__ optimization annotations of the code for disabling optimization was avoided as it seems to be considered broken or unmaintained for long time in GCC [1]. Therefore, we work around that by specifying the compile flag for memneq.o directly in the Makefile. We found that this seems to be most appropriate. As we use (Os), this patch also provides a loop-free fast-path for frequently used 16 byte digests. Similarly to kernel library string functions, leave an option for future even further optimized architecture specific assembler implementations. This was a joint work of James Yonan and Daniel Borkmann. Also thanks for feedback from Florian Weimer on this and earlier proposals [2]. [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html [2] https://lkml.org/lkml/2013/2/10/131 Signed-off-by: James Yonan ja...@openvpn.net Signed-off-by: Daniel Borkmann dbork...@redhat.com Cc: Florian Weimer f...@deneb.enyo.de --- crypto/Makefile | 7 ++- crypto/asymmetric_keys/rsa.c | 5 +- crypto/authenc.c | 6 +- crypto/authencesn.c | 8 +-- crypto/ccm.c | 4 +- crypto/gcm.c | 2 +- crypto/memneq.c | 138 +++ include/crypto/algapi.h | 18 +- 8 files changed, 174 insertions(+), 14 deletions(-) create mode 100644 crypto/memneq.c diff --git a/crypto/Makefile b/crypto/Makefile index 2d5ed08..b88cdf0 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -2,8 +2,13 @@ # Cryptographic API # +# memneq MUST be built with -Os or -O0 to prevent early-return optimizations +# that will defeat memneq's actual purpose to prevent timing attacks. +CFLAGS_REMOVE_memneq.o := -O1 -O2 -O3 +CFLAGS_memneq.o := -Os + obj-$(CONFIG_CRYPTO) += crypto.o -crypto-y := api.o cipher.o compress.o +crypto-y := api.o cipher.o compress.o memneq.o obj-$(CONFIG_CRYPTO_WORKQUEUE) += crypto_wq.o diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c index 4a6a069..1912b9b 100644 --- a/crypto/asymmetric_keys/rsa.c +++ b/crypto/asymmetric_keys/rsa.c @@ -13,6 +13,7 @@ #include linux/module.h #include linux/kernel.h #include linux/slab.h +#include crypto/algapi.h #include public_key.h MODULE_LICENSE(GPL); @@ -189,12 +190,12 @@ static int RSA_verify(const
Re: [PATCH 00/51] DMA mask changes
2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk: This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Huh, I think it was enough to send only 3 patches to the b43-dev@. Like: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks [PATCH 14/51] DMA-API: net: b43: (...) [PATCH 15/51] DMA-API: net: b43legacy: (...) ;) I believe Joe has some nice script for doing it that way. When fixing some coding style / formatting, he sends only related patches to the given ML. -- Rafał -- 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 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()
Hi Russell,
Thank you for the patch.
On Thursday 19 September 2013 22:56:02 Russell King wrote:
The code sequence:
isp-raw_dmamask = DMA_BIT_MASK(32);
isp-dev-dma_mask = isp-raw_dmamask;
isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.c |6 +++---
drivers/media/platform/omap3isp/isp.h |3 ---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index df3a0ec..1c36080 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
isp-pdata = pdata;
isp-ref_count = 0;
- isp-raw_dmamask = DMA_BIT_MASK(32);
- isp-dev-dma_mask = isp-raw_dmamask;
- isp-dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ ret = dma_coerce_mask_and_coherent(isp-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
platform_set_drvdata(pdev, isp);
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index cd3eff4..ce65d3a 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -152,7 +152,6 @@ struct isp_xclk {
* @mmio_base_phys: Array with physical L4 bus addresses for ISP register
* regions.
* @mmio_size: Array with ISP register regions size in bytes.
- * @raw_dmamask: Raw DMA mask
* @stat_lock: Spinlock for handling statistics
* @isp_mutex: Mutex for serializing requests to ISP.
* @crashed: Bitmask of crashed entities (indexed by entity ID)
@@ -190,8 +189,6 @@ struct isp_device {
unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
- u64 raw_dmamask;
-
/* ISP Obj */
spinlock_t stat_lock; /* common lock for statistic drivers */
struct mutex isp_mutex; /* For handling ref_count field */
--
Regards,
Laurent Pinchart
--
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
