Re: [PATCH] crypto: serpent - add x86_64/avx assembler implementation
Johannes Goetzfried
writes:
> +
> +static int __init serpent_init(void)
> +{
> + u64 xcr0;
> +
> + if (!cpu_has_avx || !cpu_has_osxsave) {
> + printk(KERN_INFO "AVX instructions are not detected.\n");
> + return -ENODEV;
> + }
> +
> + xcr0 = xgetbv(XCR_XFEATURE_ENABLED_MASK);
> + if ((xcr0 & (XSTATE_SSE | XSTATE_YMM)) != (XSTATE_SSE | XSTATE_YMM)) {
> + printk(KERN_INFO "AVX detected but unusable.\n");
> + return -ENODEV;
> + }
> +
> + return crypto_register_algs(serpent_algs, ARRAY_SIZE(serpent_algs));
> +}
> +
> +static void __exit serpent_exit(void)
> +{
> + crypto_unregister_algs(serpent_algs, ARRAY_SIZE(serpent_algs));
> +}
> +
> +module_init(serpent_init);
> +module_exit(serpent_exit);
> +
> +MODULE_DESCRIPTION("Serpent Cipher Algorithm, AVX optimized");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("serpent");
The driver needs CPUID annotations now (since 3.3), so that it can be
autoloaded. Something like:
#include
static const struct x86_cpu_id avx_cpu_id[] = {
X86_FEATURE_MATCH(X86_FEATURE_AVX),
{}
};
MODULE_DEVICE_TABLE(x86cpu, avx_cpu_id);
Replace the manual check in init with
if (!x86_match_cpu(avx_cpu_id))
return -ENODEV;
Also drivers should never print anything when they cannot find hardware.
Remove that printk.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
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] crypto: aesni-intel - fix unaligned cbc decrypt for x86-32
The 32 bit variant of cbc(aes) decrypt is using instructions requiring 128 bit aligned memory locations but fails to ensure this constraint in the code. Fix this by loading the data into intermediate registers with load unaligned instructions. This fixes reported general protection faults related to aesni. References: https://bugzilla.kernel.org/show_bug.cgi?id=43223 Reported-by: Daniel Cc: sta...@kernel.org [v2.6.39+] Signed-off-by: Mathias Krause --- arch/x86/crypto/aesni-intel_asm.S |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index be6d9e3..3470624 100644 --- a/arch/x86/crypto/aesni-intel_asm.S +++ b/arch/x86/crypto/aesni-intel_asm.S @@ -2460,10 +2460,12 @@ ENTRY(aesni_cbc_dec) pxor IN3, STATE4 movaps IN4, IV #else - pxor (INP), STATE2 - pxor 0x10(INP), STATE3 pxor IN1, STATE4 movaps IN2, IV + movups (INP), IN1 + pxor IN1, STATE2 + movups 0x10(INP), IN2 + pxor IN2, STATE3 #endif movups STATE1, (OUTP) movups STATE2, 0x10(OUTP) -- 1.7.10 -- 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/4] mv_cesa: no need to write to that FPGA_INT_STATUS field
Hi, On Mon, May 28, 2012 at 09:58:32AM +0800, cloudy.linux wrote: > On 2012-5-25 21:54, Phil Sutter wrote: > > Also drop the whole definition, since it's unused otherwise. > > > > Signed-off-by: Phil Sutter > > --- > > drivers/crypto/mv_cesa.c |1 - > > drivers/crypto/mv_cesa.h |7 --- > > 2 files changed, 0 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/crypto/mv_cesa.c b/drivers/crypto/mv_cesa.c > > index 8327bed..4a1f872 100644 > > --- a/drivers/crypto/mv_cesa.c > > +++ b/drivers/crypto/mv_cesa.c > > @@ -908,7 +908,6 @@ irqreturn_t crypto_int(int irq, void *priv) > >"got an interrupt but no pending timer?\n"); > > } > > val&= ~SEC_INT_ACCEL0_DONE; > > - writel(val, cpg->reg + FPGA_INT_STATUS); > > writel(val, cpg->reg + SEC_ACCEL_INT_STATUS); > > BUG_ON(cpg->eng_st != ENGINE_BUSY); > > cpg->eng_st = ENGINE_W_DEQUEUE; > > diff --git a/drivers/crypto/mv_cesa.h b/drivers/crypto/mv_cesa.h > > index 08fcb11..81ce109 100644 > > --- a/drivers/crypto/mv_cesa.h > > +++ b/drivers/crypto/mv_cesa.h > > @@ -29,13 +29,6 @@ > > #define SEC_ST_ACT_0 (1<< 0) > > #define SEC_ST_ACT_1 (1<< 1) > > > > -/* > > - * FPGA_INT_STATUS looks like a FPGA leftover and is documented only in > > Errata > > - * 4.12. It looks like that it was part of an IRQ-controller in FPGA and > > - * someone forgot to remove it while switching to the core and moving to > > - * SEC_ACCEL_INT_STATUS. > > - */ > > -#define FPGA_INT_STATUS0xdd68 > > #define SEC_ACCEL_INT_STATUS 0xde20 > > #define SEC_INT_AUTH_DONE (1<< 0) > > #define SEC_INT_DES_E_DONE(1<< 1) > > According to the functional errata of 88F5182, the FPGA_INT_STATUS is > needed (at least for 88F5182-A1/A2). Here is the quote from that errata: > > 4.12 Clearing the Cryptographic Engines and Security Accelerator > Interrupt Cause Register > Type: Guideline > Ref#: GL-CESA-100 > Relevant for: 88F5182-A1/A2 > > Description: > Writing 0 to bits[6:0] of the Crytographic Engines ... Interrupt Cause > register (offset 0x9DE20) has no effect. > > Steps to be performed by the designer > Before writing 0 to any of the bits[6:0] of the Cryptographic Engines .. > Interrupt Cause register, the software must write 0 to the corresponding > bit of the internal register at offset 0x9DD68. > Writing to offset 0x9DD68 is not possible when any of the Security > Accelerators' sessions are active. Therefore, the software must verify > that no channel is active before clearing any of those interrupts. Oh, that explains why it's not needed on Kirkwood but still left there. I could make it compile-time optional, depending on ARCH_ORION5X e.g. or simply drop the patch and leave it alone since it really doesn't hurt that much. Anyway, thanks a lot for your kind review! Greetings, Phil Phil Sutter Software Engineer -- Viprinet GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49-6721-49030-0 Direct line/Durchwahl: +49-6721-49030-134 Fax:+49-6721-49030-209 phil.sut...@viprinet.com http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein Commercial register/Handelsregister: Amtsgericht Mainz HRB40380 CEO/Geschäftsführer: Simon Kissel -- 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: support for MV_CESA with TDMA
Hi, On Sun, May 27, 2012 at 10:03:07PM +0800, cloudy.linux wrote: > Could the source code from the manufacturers of hardwares using kirkwood > be helpful? > I saw the source code of ls-wvl from buffalo contains driver for CESA. > And it deals with both IDMA and TDMA. If you need, I can send you the > download link. Actually, I do have the sources. Just had doubts about how useful it would be to write code for something I couldn't test at all. OTOH, that's probably a better start than nothing. > I also have to point out that CESA of some orion revisions has hardware > flaws that needs to be addressed which currently doesn't. Information > about those flaws can be found in 88F5182_Functional_Errata.pdf which is > available on the net. OK, thanks for the pointer! Looks like implementing combined (crypto/digest) operation for Orion will be no fun at least. Greetings, Phil Phil Sutter Software Engineer -- Viprinet GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49-6721-49030-0 Direct line/Durchwahl: +49-6721-49030-134 Fax:+49-6721-49030-209 phil.sut...@viprinet.com http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein Commercial register/Handelsregister: Amtsgericht Mainz HRB40380 CEO/Geschäftsführer: Simon Kissel -- 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 1/2] crypto: Add new test cases for Blackfin CRC crypto driver.
On Tue, May 29, 2012 at 06:28:45PM +0800, Sonic Zhang wrote: > PING Please be patient. Your patch is in my queue. Cheers, -- Email: Herbert Xu 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 2/2] crypto: bfin_crc: CRC hardware accelerator driver for BF60x family processors.
PING
On Fri, May 25, 2012 at 5:54 PM, Sonic Zhang wrote:
> From: Sonic Zhang
>
> The CRC peripheral is a hardware block used to compute the CRC of the block
> of data. This is based on a CRC32 engine which computes the CRC value of 32b
> data words presented to it. For data words of < 32b in size, this driver
> pack 0 automatically into 32b data units. This driver implements the async
> hash crypto framework API.
>
> Signed-off-by: Sonic Zhang
> ---
> drivers/crypto/Kconfig | 7 +
> drivers/crypto/Makefile | 3 +-
> drivers/crypto/bfin_crc.c | 789
> +
> 3 files changed, 798 insertions(+), 1 deletions(-)
> create mode 100644 drivers/crypto/bfin_crc.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 69fdf18..a520b93 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -306,4 +306,11 @@ if CRYPTO_DEV_UX500
> source "drivers/crypto/ux500/Kconfig"
> endif # if CRYPTO_DEV_UX500
>
> +config CRYPTO_DEV_BFIN_CRC
> + tristate "Support for Blackfin CRC hareware accelerator"
> + depends on BF60x
> + help
> + Blackfin processors have CRC hardware accelerator. Select this if
> you
> + want to use the Blackfin CRC module.
> +
> endif # CRYPTO_HW
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index 0139032..d5062bb 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -14,4 +14,5 @@ obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
> obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o
> obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
> obj-$(CONFIG_CRYPTO_DEV_TEGRA_AES) += tegra-aes.o
> -obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
> \ No newline at end of file
> +obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
> +obj-$(CONFIG_CRYPTO_DEV_BFIN_CRC) += bfin_crc.o
> diff --git a/drivers/crypto/bfin_crc.c b/drivers/crypto/bfin_crc.c
> new file mode 100644
> index 000..477b6a3
> --- /dev/null
> +++ b/drivers/crypto/bfin_crc.c
> @@ -0,0 +1,789 @@
> +/*
> + * Cryptographic API.
> + *
> + * Support Blackfin CRC HW acceleration.
> + *
> + * Copyright 2012 Analog Devices Inc.
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define CRC_CCRYPTO_QUEUE_LENGTH 5
> +
> +#define DRIVER_NAME "bfin-hmac-crc"
> +#define CHKSUM_DIGEST_SIZE 4
> +#define CHKSUM_BLOCK_SIZE 1
> +
> +#define CRC_MAX_DMA_DESC 100
> +
> +#define CRC_CRYPTO_STATE_UPDATE 1
> +#define CRC_CRYPTO_STATE_FINALUPDATE 2
> +#define CRC_CRYPTO_STATE_FINISH 3
> +
> +struct bfin_crypto_crc {
> + struct list_head list;
> + struct device *dev;
> + spinlock_t lock;
> +
> + int irq;
> + int dma_ch;
> + u32 poly;
> + volatile struct crc_register *regs;
> +
> + struct ahash_request *req; /* current request in operation */
> + struct dma_desc_array *sg_cpu; /* virt addr of sg dma descriptors */
> + dma_addr_t sg_dma; /* phy addr of sg dma descriptors */
> + u8 *sg_mid_buf;
> +
> + struct tasklet_struct done_task;
> + struct crypto_queue queue; /* waiting requests */
> +
> + u8 busy:1; /* crc device in operation flag */
> +};
> +
> +struct bfin_crypto_crc_list {
> + struct list_head dev_list;
> + spinlock_t lock;
> +} crc_list;
> +
> +struct bfin_crypto_crc_reqctx {
> + struct bfin_crypto_crc *crc;
> +
> + unsigned int total; /* total request bytes */
> + size_t sg_buflen; /* bytes for this update */
> + unsigned int sg_nents;
> + struct scatterlist *sg; /* sg list head for this update*/
> + struct scatterlist bufsl[2]; /* chained sg list */
> +
> + size_t bufnext_len;
> + size_t buflast_len;
> + u8 bufnext[CHKSUM_DIGEST_SIZE]; /* extra bytes
> for next udpate */
> + u8 buflast[CHKSUM_DIGEST_SIZE]; /* extra bytes
> from last udpate */
> +
> + u8 flag;
> +};
> +
> +struct bfin_crypto_crc_ctx {
> + struct bfin_crypto_crc *crc;
> + u32 key;
> +};
> +
> +
> +/*
> + * derive number of elements in scatterlist
> + */
> +static int sg_count(struct scatterlist *sg_list)
> +{
> + struct scatterlist *sg = sg_list;
> + int sg_nents = 1;
> +
> + if (sg_list == NULL)
> + return 0;
> +
> + while (!sg_is_last(
Re: [PATCH 1/2] crypto: Add new test cases for Blackfin CRC crypto driver.
PING
On Fri, May 25, 2012 at 5:54 PM, Sonic Zhang wrote:
> From: Sonic Zhang
>
> Signed-off-by: Sonic Zhang
> ---
> crypto/tcrypt.c | 3 ++
> crypto/testmgr.c | 9 +
> crypto/testmgr.h | 90
> ++
> 3 files changed, 102 insertions(+), 0 deletions(-)
>
> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
> index 8f147bf..750cce4 100644
> --- a/crypto/tcrypt.c
> +++ b/crypto/tcrypt.c
> @@ -1192,6 +1192,9 @@ static int do_test(int m)
> case 109:
> ret += tcrypt_test("vmac(aes)");
> break;
> + case 110:
> + ret += tcrypt_test("hmac(crc32)");
> + break;
>
> case 150:
> ret += tcrypt_test("ansi_cprng");
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 5674878..eb6d20f 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -2220,6 +2220,15 @@ static const struct alg_test_desc alg_test_descs[] = {
> }
> }
> }, {
> + .alg = "hmac(crc32)",
> + .test = alg_test_hash,
> + .suite = {
> + .hash = {
> + .vecs = bfin_crc_tv_template,
> + .count = BFIN_CRC_TEST_VECTORS
> + }
> + }
> + }, {
> .alg = "hmac(md5)",
> .test = alg_test_hash,
> .suite = {
> diff --git a/crypto/testmgr.h b/crypto/testmgr.h
> index 36e5a8e..34a9d51 100644
> --- a/crypto/testmgr.h
> +++ b/crypto/testmgr.h
> @@ -14858,4 +14858,94 @@ static struct hash_testvec crc32c_tv_template[] = {
> },
> };
>
> +/*
> + * Blakcifn CRC test vectors
> + */
> +#define BFIN_CRC_TEST_VECTORS 6
> +
> +static struct hash_testvec bfin_crc_tv_template[] = {
> + {
> + .psize = 0,
> + .digest = "\x00\x00\x00\x00",
> + },
> + {
> + .key = "\x87\xa9\xcb\xed",
> + .ksize = 4,
> + .psize = 0,
> + .digest = "\x87\xa9\xcb\xed",
> + },
> + {
> + .key = "\xff\xff\xff\xff",
> + .ksize = 4,
> + .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
> + "\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
> + "\x11\x12\x13\x14\x15\x16\x17\x18"
> + "\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
> + "\x21\x22\x23\x24\x25\x26\x27\x28",
> + .psize = 40,
> + .digest = "\x84\x0c\x8d\xa2",
> + },
> + {
> + .key = "\xff\xff\xff\xff",
> + .ksize = 4,
> + .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
> + "\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
> + "\x11\x12\x13\x14\x15\x16\x17\x18"
> + "\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
> + "\x21\x22\x23\x24\x25\x26",
> + .psize = 38,
> + .digest = "\x8c\x58\xec\xb7",
> + },
> + {
> + .key = "\xff\xff\xff\xff",
> + .ksize = 4,
> + .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
> + "\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
> + "\x11\x12\x13\x14\x15\x16\x17\x18"
> + "\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
> + "\x21\x22\x23\x24\x25\x26\x27",
> + .psize = 39,
> + .digest = "\xdc\x50\x28\x7b",
> + },
> + {
> + .key = "\xff\xff\xff\xff",
> + .ksize = 4,
> + .plaintext = "\x01\x02\x03\x04\x05\x06\x07\x08"
> + "\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10"
> + "\x11\x12\x13\x14\x15\x16\x17\x18"
> + "\x19\x1a\x1b\x1c\x1d\x1e\x1f\x20"
> + "\x21\x22\x23\x24\x25\x26\x27\x28"
> + "\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30"
> + "\x31\x32\x33\x34\x35\x36\x37\x38"
> + "\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40"
> + "\x41\x42\x43\x44\x45\x46\x47\x48"
> + "\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50"
> + "\x51\x52\x53\x54\x55\x56\x57\x58"
> + "\x59\x5a\x5b\x5c\x5d\x5e\x5f\x60"
> + "\x61\x62\x63\x64\x65\x66\x67\x68"
> + "\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70"
> + "\x71\x72\x73\x74\x75\x76\x77\x78"
> + "\x79\x7a\x7b\x7c\x7d\x7e\x7f\x80"
> + "\x81\x82\x83\x84\x85\x86\x87\x88"
> + "\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90"
> + "\x91\x92\x93\x94\x95\x96\x97\x98"
> +
