Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support
On 3/7/2015 3:16 AM, Kim Phillips wrote: On Fri, 6 Mar 2015 11:49:43 -0500 Martin Hicks m...@bork.org wrote: On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips kim.phill...@freescale.com wrote: On Fri, 20 Feb 2015 12:00:10 -0500 Martin Hicks m...@bork.org wrote: The newer talitos hardware has support for AES in XTS mode. Assuming it's the same thing, AES-XCBC gets added with SEC v3.0 h/w. Assuming hw_supports() doesn't already support this algorithm AES-XCBC isn't the same thing as AES-XTS. Thanks. combination (technically via the mode bit), this needs to be reflected in the patch so the driver doesn't think SEC 2.x devices can do XTS, too. Right. I hadn't looked into how exactly hw_supports() works. It only indicates which execution units are present (in this case the AES unit). I actually think XTS gets introduced in SEC v3.3.2. I also have an MPC8379 (sec3.3) and it does not have XTS. Can you look internally to find out in which hardware it was introduced? Is there a SEC 3.3.1 that also has XTS? later MPC8315Es had a SEC v3.3.1, but AFAICT, it doesn't support XTS, so, yes, it's likely v3.3.2 and above (if any). There's a public application note on freescale.com: AN3645 - SEC 2x/3x Descriptor Programmer's Guide (Rev.3/2010) Table 4 - EUs Supported in Each SEC Version summarizes which algorithms / modes are supported for every talitos version. Unfortunately this goes up to SEC 3.3.1. Since XTS doesn't show up, 3.3.2 would be the first supporting it. Horia ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support
On Fri, 6 Mar 2015 11:49:43 -0500 Martin Hicks m...@bork.org wrote: On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips kim.phill...@freescale.com wrote: On Fri, 20 Feb 2015 12:00:10 -0500 Martin Hicks m...@bork.org wrote: The newer talitos hardware has support for AES in XTS mode. Assuming it's the same thing, AES-XCBC gets added with SEC v3.0 h/w. Assuming hw_supports() doesn't already support this algorithm AES-XCBC isn't the same thing as AES-XTS. Thanks. combination (technically via the mode bit), this needs to be reflected in the patch so the driver doesn't think SEC 2.x devices can do XTS, too. Right. I hadn't looked into how exactly hw_supports() works. It only indicates which execution units are present (in this case the AES unit). I actually think XTS gets introduced in SEC v3.3.2. I also have an MPC8379 (sec3.3) and it does not have XTS. Can you look internally to find out in which hardware it was introduced? Is there a SEC 3.3.1 that also has XTS? later MPC8315Es had a SEC v3.3.1, but AFAICT, it doesn't support XTS, so, yes, it's likely v3.3.2 and above (if any). I guess I just need a -features flag to conditionally register the XTS algorithm for 3.3.x and newer. Adding anything more complicated doesn't seem warranted at this time, although that could change if someone came along and needed to add a whole whack more of the AES modes that were introduced at various times in the different SEC revisions. OK. Note: there's some SEC node fixup code in u-boot that could be used for this job, too. + .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU | + DESC_HDR_SEL0_AESU | + DESC_HDR_MODE0_AESU_XTS, ... /* primary execution unit mode (MODE0) and derivatives */ #define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x0010) #define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020) +#define DESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420) I'd prefer these defines be kept as single bit definitions, and keep their names from the manual. An XTS-specific definition can be composed from them either after this, or manually in the desc_hdr_template assignment above. It doesn't look like there are divisible single-bit definitions for the MODE0 bits. The AES Cipher modes are composed of 5 bits called CipherMode, Extended CipherMode and Aux2. Individually they don't seem to mean anything. Unless you want something like: #define AES_MODE(cm, ecm, aux2) cpu_to_be32(((ecm6) | (aux25) | (cm1)) 20) #define DESC_HDR_MODE0_AESU_CBC AES_MODE(1, 0, 0) #define DESC_HDR_MODE0_AESU_XTS AES_MODE(1, 1, 0) the way you had it seems to be ok for now. Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support
On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips kim.phill...@freescale.com wrote: On Fri, 20 Feb 2015 12:00:10 -0500 Martin Hicks m...@bork.org wrote: The newer talitos hardware has support for AES in XTS mode. Assuming it's the same thing, AES-XCBC gets added with SEC v3.0 h/w. Assuming hw_supports() doesn't already support this algorithm AES-XCBC isn't the same thing as AES-XTS. combination (technically via the mode bit), this needs to be reflected in the patch so the driver doesn't think SEC 2.x devices can do XTS, too. Right. I hadn't looked into how exactly hw_supports() works. It only indicates which execution units are present (in this case the AES unit). I actually think XTS gets introduced in SEC v3.3.2. I also have an MPC8379 (sec3.3) and it does not have XTS. Can you look internally to find out in which hardware it was introduced? Is there a SEC 3.3.1 that also has XTS? I guess I just need a -features flag to conditionally register the XTS algorithm for 3.3.x and newer. Adding anything more complicated doesn't seem warranted at this time, although that could change if someone came along and needed to add a whole whack more of the AES modes that were introduced at various times in the different SEC revisions. + .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU | + DESC_HDR_SEL0_AESU | + DESC_HDR_MODE0_AESU_XTS, ... /* primary execution unit mode (MODE0) and derivatives */ #define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x0010) #define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020) +#define DESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420) I'd prefer these defines be kept as single bit definitions, and keep their names from the manual. An XTS-specific definition can be composed from them either after this, or manually in the desc_hdr_template assignment above. It doesn't look like there are divisible single-bit definitions for the MODE0 bits. The AES Cipher modes are composed of 5 bits called CipherMode, Extended CipherMode and Aux2. Individually they don't seem to mean anything. Unless you want something like: #define AES_MODE(cm, ecm, aux2) cpu_to_be32(((ecm6) | (aux25) | (cm1)) 20) #define DESC_HDR_MODE0_AESU_CBC AES_MODE(1, 0, 0) #define DESC_HDR_MODE0_AESU_XTS AES_MODE(1, 1, 0) Thanks, mh -- Martin Hicks P.Eng. | m...@bork.org Bork Consulting Inc. | +1 (613) 266-2296 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support
Hi Kim, On Fri, Mar 6, 2015 at 11:49 AM, Martin Hicks m...@bork.org wrote: On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips kim.phill...@freescale.com wrote: On Fri, 20 Feb 2015 12:00:10 -0500 Martin Hicks m...@bork.org wrote: The newer talitos hardware has support for AES in XTS mode. Assuming it's the same thing, AES-XCBC gets added with SEC v3.0 h/w. Assuming hw_supports() doesn't already support this algorithm AES-XCBC isn't the same thing as AES-XTS. combination (technically via the mode bit), this needs to be reflected in the patch so the driver doesn't think SEC 2.x devices can do XTS, too. Right. I hadn't looked into how exactly hw_supports() works. It only indicates which execution units are present (in this case the AES unit). I actually think XTS gets introduced in SEC v3.3.2. I also have an MPC8379 (sec3.3) and it does not have XTS. I'm wrong about the 8379. It's SEC3.0. So XTS was introduced somewhere between 3.0 and 3.3.2 Can you look internally to find out in which hardware it was introduced? Is there a SEC 3.3.1 that also has XTS? Can you still look into where XTS was added? I'm not even sure how many versions of hardware exist between 3.0 and 3.3.2 Thanks, mh I guess I just need a -features flag to conditionally register the XTS algorithm for 3.3.x and newer. Adding anything more complicated doesn't seem warranted at this time, although that could change if someone came along and needed to add a whole whack more of the AES modes that were introduced at various times in the different SEC revisions. + .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU | + DESC_HDR_SEL0_AESU | + DESC_HDR_MODE0_AESU_XTS, ... /* primary execution unit mode (MODE0) and derivatives */ #define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x0010) #define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020) +#define DESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420) I'd prefer these defines be kept as single bit definitions, and keep their names from the manual. An XTS-specific definition can be composed from them either after this, or manually in the desc_hdr_template assignment above. It doesn't look like there are divisible single-bit definitions for the MODE0 bits. The AES Cipher modes are composed of 5 bits called CipherMode, Extended CipherMode and Aux2. Individually they don't seem to mean anything. Unless you want something like: #define AES_MODE(cm, ecm, aux2) cpu_to_be32(((ecm6) | (aux25) | (cm1)) 20) #define DESC_HDR_MODE0_AESU_CBC AES_MODE(1, 0, 0) #define DESC_HDR_MODE0_AESU_XTS AES_MODE(1, 1, 0) Thanks, mh -- Martin Hicks P.Eng. | m...@bork.org Bork Consulting Inc. | +1 (613) 266-2296 -- Martin Hicks P.Eng. | m...@bork.org Bork Consulting Inc. | +1 (613) 266-2296 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support
On Fri, 20 Feb 2015 12:00:10 -0500 Martin Hicks m...@bork.org wrote: The newer talitos hardware has support for AES in XTS mode. Assuming it's the same thing, AES-XCBC gets added with SEC v3.0 h/w. Assuming hw_supports() doesn't already support this algorithm combination (technically via the mode bit), this needs to be reflected in the patch so the driver doesn't think SEC 2.x devices can do XTS, too. + .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU | + DESC_HDR_SEL0_AESU | + DESC_HDR_MODE0_AESU_XTS, ... /* primary execution unit mode (MODE0) and derivatives */ #define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x0010) #define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020) +#define DESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420) I'd prefer these defines be kept as single bit definitions, and keep their names from the manual. An XTS-specific definition can be composed from them either after this, or manually in the desc_hdr_template assignment above. Thanks, Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support
On 2/20/2015 7:00 PM, Martin Hicks wrote:
The newer talitos hardware has support for AES in XTS mode.
Signed-off-by: Martin Hicks m...@bork.org
---
checkpatch complains about formatting, please check.
drivers/crypto/talitos.c | 33 +
drivers/crypto/talitos.h |1 +
2 files changed, 34 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 6b2a19a..38cbde1 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -40,9 +40,11 @@
#include linux/spinlock.h
#include linux/rtnetlink.h
#include linux/slab.h
+#include linux/device-mapper.h
#include crypto/algapi.h
#include crypto/aes.h
+#include crypto/xts.h
#include crypto/des.h
#include crypto/sha.h
#include crypto/md5.h
@@ -1464,9 +1466,22 @@ static struct talitos_edesc
*ablkcipher_edesc_alloc(struct ablkcipher_request *
areq, bool encrypt)
{
struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(areq);
+ struct crypto_tfm *tfm = (struct crypto_tfm *)cipher;
struct talitos_ctx *ctx = crypto_ablkcipher_ctx(cipher);
unsigned int ivsize = crypto_ablkcipher_ivsize(cipher);
+ /*
+ * AES-XTS uses the first two AES Context registers for:
+ *
+ * Register 1: Sector Number (Little Endian)
+ * Register 2: Sector Size (Big Endian)
+ *
+ * Whereas AES-CBC uses registers 1/2 as a 16-byte IV.
+ */
+ if (!strcmp(crypto_tfm_alg_name(tfm),xts(aes)))
I guess it would be better to use ctx-desc_hdr_template instead of
string comparison.
+ /* Fixed sized sector */
+ *((u64 *)areq-info + 1) = cpu_to_be64((1SECTOR_SHIFT));
+
return talitos_edesc_alloc(ctx-dev, NULL, areq-src, areq-dst,
areq-info, 0, areq-nbytes, 0, ivsize, 0,
areq-base.flags, areq-base, encrypt);
@@ -2192,6 +2207,24 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE0_DEU_CBC |
DESC_HDR_MODE0_DEU_3DES,
},
+ { .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+ .alg.crypto = {
+ .cra_name = xts(aes),
+ .cra_driver_name = xts-aes-talitos,
+ .cra_blocksize = XTS_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_ASYNC,
+ .cra_ablkcipher = {
+ .min_keysize = AES_MIN_KEY_SIZE * 2,
+ .max_keysize = AES_MAX_KEY_SIZE * 2,
+ .ivsize = XTS_BLOCK_SIZE,
+ }
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+ DESC_HDR_SEL0_AESU |
+ DESC_HDR_MODE0_AESU_XTS,
+ },
+
/* AHASH algorithms. */
{ .type = CRYPTO_ALG_TYPE_AHASH,
.alg.hash = {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index a6f73e2..735da82 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -316,6 +316,7 @@ extern int talitos_submit(struct device *dev, int ch,
struct talitos_edesc *edes
/* primary execution unit mode (MODE0) and derivatives */
#define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x0010)
#define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020)
+#define DESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420)
#define DESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x0040)
#define DESC_HDR_MODE0_DEU_3DES cpu_to_be32(0x0020)
#define DESC_HDR_MODE0_MDEU_CONTcpu_to_be32(0x0800)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] crypto: talitos: Add AES-XTS Support
The newer talitos hardware has support for AES in XTS mode.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 33 +
drivers/crypto/talitos.h |1 +
2 files changed, 34 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 6b2a19a..38cbde1 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -40,9 +40,11 @@
#include linux/spinlock.h
#include linux/rtnetlink.h
#include linux/slab.h
+#include linux/device-mapper.h
#include crypto/algapi.h
#include crypto/aes.h
+#include crypto/xts.h
#include crypto/des.h
#include crypto/sha.h
#include crypto/md5.h
@@ -1464,9 +1466,22 @@ static struct talitos_edesc
*ablkcipher_edesc_alloc(struct ablkcipher_request *
areq, bool encrypt)
{
struct crypto_ablkcipher *cipher = crypto_ablkcipher_reqtfm(areq);
+ struct crypto_tfm *tfm = (struct crypto_tfm *)cipher;
struct talitos_ctx *ctx = crypto_ablkcipher_ctx(cipher);
unsigned int ivsize = crypto_ablkcipher_ivsize(cipher);
+ /*
+* AES-XTS uses the first two AES Context registers for:
+*
+* Register 1: Sector Number (Little Endian)
+* Register 2: Sector Size (Big Endian)
+*
+* Whereas AES-CBC uses registers 1/2 as a 16-byte IV.
+*/
+ if (!strcmp(crypto_tfm_alg_name(tfm),xts(aes)))
+ /* Fixed sized sector */
+ *((u64 *)areq-info + 1) = cpu_to_be64((1SECTOR_SHIFT));
+
return talitos_edesc_alloc(ctx-dev, NULL, areq-src, areq-dst,
areq-info, 0, areq-nbytes, 0, ivsize, 0,
areq-base.flags, areq-base, encrypt);
@@ -2192,6 +2207,24 @@ static struct talitos_alg_template driver_algs[] = {
DESC_HDR_MODE0_DEU_CBC |
DESC_HDR_MODE0_DEU_3DES,
},
+ { .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
+ .alg.crypto = {
+ .cra_name = xts(aes),
+ .cra_driver_name = xts-aes-talitos,
+ .cra_blocksize = XTS_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_ASYNC,
+ .cra_ablkcipher = {
+ .min_keysize = AES_MIN_KEY_SIZE * 2,
+ .max_keysize = AES_MAX_KEY_SIZE * 2,
+ .ivsize = XTS_BLOCK_SIZE,
+ }
+ },
+ .desc_hdr_template = DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU |
+ DESC_HDR_SEL0_AESU |
+ DESC_HDR_MODE0_AESU_XTS,
+ },
+
/* AHASH algorithms. */
{ .type = CRYPTO_ALG_TYPE_AHASH,
.alg.hash = {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index a6f73e2..735da82 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -316,6 +316,7 @@ extern int talitos_submit(struct device *dev, int ch,
struct talitos_edesc *edes
/* primary execution unit mode (MODE0) and derivatives */
#defineDESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x0010)
#defineDESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x0020)
+#defineDESC_HDR_MODE0_AESU_XTS cpu_to_be32(0x0420)
#defineDESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x0040)
#defineDESC_HDR_MODE0_DEU_3DES cpu_to_be32(0x0020)
#defineDESC_HDR_MODE0_MDEU_CONTcpu_to_be32(0x0800)
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
