* [PATCH 2/6] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2017-01-02 18:21 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, linux-arm-kernel, Ard Biesheuvel
In-Reply-To: <1483381268-12987-1-git-send-email-ard.biesheuvel@linaro.org>
The bit-sliced NEON implementation of AES only performs optimally if
it can process 8 blocks of input in parallel. This is due to the nature
of bit slicing, where the n-th bit of each byte of AES state of each input
block is collected into NEON register 'n', for registers q0 - q7.
This implies that the amount of work for the transform is fixed,
regardless of whether we are handling just one block or 8 in parallel.
So let's try a bit harder to iterate over the input in suitably sized
chunks, by setting the newly introduced walksize attribute to 8x the value
of AES_BLOCK_SIZE, and tweaking the loops to only process multiples of the
walk size, unless we are handling the last chunk in the input stream.
Note that the skcipher walk API guarantees that a step in the walk never
returns less than 'walksize' bytes if there are at least that many bytes
of input still available. However, it does *not* guarantee that those steps
produce an exact multiple of the walk size.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/aesbs-glue.c | 67 +++++++++++---------
1 file changed, 38 insertions(+), 29 deletions(-)
diff --git a/arch/arm/crypto/aesbs-glue.c b/arch/arm/crypto/aesbs-glue.c
index d8e06de72ef3..f3019333c2eb 100644
--- a/arch/arm/crypto/aesbs-glue.c
+++ b/arch/arm/crypto/aesbs-glue.c
@@ -121,39 +121,26 @@ static int aesbs_cbc_encrypt(struct skcipher_request *req)
return crypto_cbc_encrypt_walk(req, aesbs_encrypt_one);
}
-static inline void aesbs_decrypt_one(struct crypto_skcipher *tfm,
- const u8 *src, u8 *dst)
-{
- struct aesbs_cbc_ctx *ctx = crypto_skcipher_ctx(tfm);
-
- AES_decrypt(src, dst, &ctx->dec.rk);
-}
-
static int aesbs_cbc_decrypt(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct aesbs_cbc_ctx *ctx = crypto_skcipher_ctx(tfm);
struct skcipher_walk walk;
- unsigned int nbytes;
int err;
- for (err = skcipher_walk_virt(&walk, req, false);
- (nbytes = walk.nbytes); err = skcipher_walk_done(&walk, nbytes)) {
- u32 blocks = nbytes / AES_BLOCK_SIZE;
- u8 *dst = walk.dst.virt.addr;
- u8 *src = walk.src.virt.addr;
- u8 *iv = walk.iv;
-
- if (blocks >= 8) {
- kernel_neon_begin();
- bsaes_cbc_encrypt(src, dst, nbytes, &ctx->dec, iv);
- kernel_neon_end();
- nbytes %= AES_BLOCK_SIZE;
- continue;
- }
+ err = skcipher_walk_virt(&walk, req, false);
+
+ while (walk.nbytes) {
+ unsigned int nbytes = walk.nbytes;
+
+ if (nbytes < walk.total)
+ nbytes = round_down(nbytes, walk.stride);
- nbytes = crypto_cbc_decrypt_blocks(&walk, tfm,
- aesbs_decrypt_one);
+ kernel_neon_begin();
+ bsaes_cbc_encrypt(walk.src.virt.addr, walk.dst.virt.addr,
+ nbytes, &ctx->dec, walk.iv);
+ kernel_neon_end();
+ err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
}
return err;
}
@@ -186,6 +173,12 @@ static int aesbs_ctr_encrypt(struct skcipher_request *req)
__be32 *ctr = (__be32 *)walk.iv;
u32 headroom = UINT_MAX - be32_to_cpu(ctr[3]);
+ if (walk.nbytes < walk.total) {
+ blocks = round_down(blocks,
+ walk.stride / AES_BLOCK_SIZE);
+ tail = walk.nbytes - blocks * AES_BLOCK_SIZE;
+ }
+
/* avoid 32 bit counter overflow in the NEON code */
if (unlikely(headroom < blocks)) {
blocks = headroom + 1;
@@ -198,6 +191,9 @@ static int aesbs_ctr_encrypt(struct skcipher_request *req)
kernel_neon_end();
inc_be128_ctr(ctr, blocks);
+ if (tail > 0 && tail < AES_BLOCK_SIZE)
+ break;
+
err = skcipher_walk_done(&walk, tail);
}
if (walk.nbytes) {
@@ -227,11 +223,16 @@ static int aesbs_xts_encrypt(struct skcipher_request *req)
AES_encrypt(walk.iv, walk.iv, &ctx->twkey);
while (walk.nbytes) {
+ unsigned int nbytes = walk.nbytes;
+
+ if (nbytes < walk.total)
+ nbytes = round_down(nbytes, walk.stride);
+
kernel_neon_begin();
bsaes_xts_encrypt(walk.src.virt.addr, walk.dst.virt.addr,
- walk.nbytes, &ctx->enc, walk.iv);
+ nbytes, &ctx->enc, walk.iv);
kernel_neon_end();
- err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
+ err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
}
return err;
}
@@ -249,11 +250,16 @@ static int aesbs_xts_decrypt(struct skcipher_request *req)
AES_encrypt(walk.iv, walk.iv, &ctx->twkey);
while (walk.nbytes) {
+ unsigned int nbytes = walk.nbytes;
+
+ if (nbytes < walk.total)
+ nbytes = round_down(nbytes, walk.stride);
+
kernel_neon_begin();
bsaes_xts_decrypt(walk.src.virt.addr, walk.dst.virt.addr,
- walk.nbytes, &ctx->dec, walk.iv);
+ nbytes, &ctx->dec, walk.iv);
kernel_neon_end();
- err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
+ err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
}
return err;
}
@@ -272,6 +278,7 @@ static struct skcipher_alg aesbs_algs[] = { {
.min_keysize = AES_MIN_KEY_SIZE,
.max_keysize = AES_MAX_KEY_SIZE,
.ivsize = AES_BLOCK_SIZE,
+ .walksize = 8 * AES_BLOCK_SIZE,
.setkey = aesbs_cbc_set_key,
.encrypt = aesbs_cbc_encrypt,
.decrypt = aesbs_cbc_decrypt,
@@ -290,6 +297,7 @@ static struct skcipher_alg aesbs_algs[] = { {
.max_keysize = AES_MAX_KEY_SIZE,
.ivsize = AES_BLOCK_SIZE,
.chunksize = AES_BLOCK_SIZE,
+ .walksize = 8 * AES_BLOCK_SIZE,
.setkey = aesbs_ctr_set_key,
.encrypt = aesbs_ctr_encrypt,
.decrypt = aesbs_ctr_encrypt,
@@ -307,6 +315,7 @@ static struct skcipher_alg aesbs_algs[] = { {
.min_keysize = 2 * AES_MIN_KEY_SIZE,
.max_keysize = 2 * AES_MAX_KEY_SIZE,
.ivsize = AES_BLOCK_SIZE,
+ .walksize = 8 * AES_BLOCK_SIZE,
.setkey = aesbs_xts_set_key,
.encrypt = aesbs_xts_encrypt,
.decrypt = aesbs_xts_decrypt,
--
2.7.4
^ permalink raw reply related
* [PATCH 1/6] crypto: generic/aes - export encrypt and decrypt entry points
From: Ard Biesheuvel @ 2017-01-02 18:21 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, linux-arm-kernel, Ard Biesheuvel
In-Reply-To: <1483381268-12987-1-git-send-email-ard.biesheuvel@linaro.org>
The generic AES code already shares its key schedule generation
routines (and its S-boxes) with other implementations via external
linkage. In the same way, export the core encrypt/decrypt routines
so they may be reused by other drivers as well.
This facility will be used by the bit slicing implementation of AES
in XTS mode for arm64, where using the 8-way cipher (and its ~2 KB
expanded key schedule) to generate the initial tweak is suboptimal.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
crypto/aes_generic.c | 10 ++++++----
include/crypto/aes.h | 3 +++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/crypto/aes_generic.c b/crypto/aes_generic.c
index 3dd101144a58..26fd7b8c2e5f 100644
--- a/crypto/aes_generic.c
+++ b/crypto/aes_generic.c
@@ -1326,7 +1326,7 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key);
f_rl(bo, bi, 3, k); \
} while (0)
-static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+void crypto_aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
{
const struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
const __le32 *src = (const __le32 *)in;
@@ -1366,6 +1366,7 @@ static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
dst[2] = cpu_to_le32(b0[2]);
dst[3] = cpu_to_le32(b0[3]);
}
+EXPORT_SYMBOL_GPL(crypto_aes_encrypt);
/* decrypt a block of text */
@@ -1398,7 +1399,7 @@ static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
i_rl(bo, bi, 3, k); \
} while (0)
-static void aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+void crypto_aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
{
const struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
const __le32 *src = (const __le32 *)in;
@@ -1438,6 +1439,7 @@ static void aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
dst[2] = cpu_to_le32(b0[2]);
dst[3] = cpu_to_le32(b0[3]);
}
+EXPORT_SYMBOL_GPL(crypto_aes_decrypt);
static struct crypto_alg aes_alg = {
.cra_name = "aes",
@@ -1453,8 +1455,8 @@ static struct crypto_alg aes_alg = {
.cia_min_keysize = AES_MIN_KEY_SIZE,
.cia_max_keysize = AES_MAX_KEY_SIZE,
.cia_setkey = crypto_aes_set_key,
- .cia_encrypt = aes_encrypt,
- .cia_decrypt = aes_decrypt
+ .cia_encrypt = crypto_aes_encrypt,
+ .cia_decrypt = crypto_aes_decrypt
}
}
};
diff --git a/include/crypto/aes.h b/include/crypto/aes.h
index 7524ba3b6f3c..297fbba5d27b 100644
--- a/include/crypto/aes.h
+++ b/include/crypto/aes.h
@@ -32,6 +32,9 @@ extern const u32 crypto_fl_tab[4][256];
extern const u32 crypto_it_tab[4][256];
extern const u32 crypto_il_tab[4][256];
+void crypto_aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in);
+void crypto_aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in);
+
int crypto_aes_set_key(struct crypto_tfm *tfm, const u8 *in_key,
unsigned int key_len);
int crypto_aes_expand_key(struct crypto_aes_ctx *ctx, const u8 *in_key,
--
2.7.4
^ permalink raw reply related
* [PATCH 0/6] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Ard Biesheuvel @ 2017-01-02 18:21 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, linux-arm-kernel, Ard Biesheuvel
This series adds SIMD implementations for arm64 and ARM of ChaCha20 (*),
and a port of the ARM bit-sliced AES algorithm to arm64, and
Patch #1 is a prerequisite for the AES-XTS implementation in #6, which needs
a secondary AES transform to generate the initial tweak.
Patch #2 optimizes the bit-sliced AES glue code for ARM to iterate over the
input in the most efficient manner possible.
Patch #3 adds a NEON implementation of ChaCha20 for ARM.
Patch #4 adds a NEON implementation of ChaCha20 for arm64.
Patch #5 modifies the existing NEON and ARMv8 Crypto Extensions implementations
of AES-CTR to be available as a synchronous skcipher as well. This is intended
for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
[ccm, gcm] in softirq context, which supports SIMD algorithms on arm64.
Patch #6 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CTR
and XTS modes.
Ard Biesheuvel (6):
crypto: generic/aes - export encrypt and decrypt entry points
crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
crypto: arm/chacha20 - implement NEON version based on SSE3 code
crypto: arm64/chacha20 - implement NEON version based on SSE3 code
crypto: arm64/aes-blk - expose AES-CTR as synchronous cipher as well
crypto: arm64/aes - reimplement bit-sliced ARM/NEON implementation for
arm64
arch/arm/crypto/Kconfig | 6 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/aesbs-glue.c | 67 +-
arch/arm/crypto/chacha20-neon-core.S | 524 ++++++++++++
arch/arm/crypto/chacha20-neon-glue.c | 128 +++
arch/arm64/crypto/Kconfig | 13 +
arch/arm64/crypto/Makefile | 6 +
arch/arm64/crypto/aes-glue.c | 25 +-
arch/arm64/crypto/aes-neonbs-core.S | 879 ++++++++++++++++++++
arch/arm64/crypto/aes-neonbs-glue.c | 344 ++++++++
arch/arm64/crypto/chacha20-neon-core.S | 450 ++++++++++
arch/arm64/crypto/chacha20-neon-glue.c | 127 +++
crypto/aes_generic.c | 10 +-
include/crypto/aes.h | 3 +
14 files changed, 2549 insertions(+), 35 deletions(-)
create mode 100644 arch/arm/crypto/chacha20-neon-core.S
create mode 100644 arch/arm/crypto/chacha20-neon-glue.c
create mode 100644 arch/arm64/crypto/aes-neonbs-core.S
create mode 100644 arch/arm64/crypto/aes-neonbs-glue.c
create mode 100644 arch/arm64/crypto/chacha20-neon-core.S
create mode 100644 arch/arm64/crypto/chacha20-neon-glue.c
--
2.7.4
^ permalink raw reply
* Urgent Please;;
From: Dr. David White @ 2017-01-02 17:34 UTC (permalink / raw)
Dear,
With due respect to your person and much sincerity of purpose. I have a business proposal which I will like to handle with you and $14.5 Million USD is involve. But be rest assured that everything is legal and risk free as I have concluded all the arrangements and the legal papers that will back the transaction up. Kindly indicate your interest as to enable me tell you more detail of the proposal. Waiting for your urgent response.
Yours Faithfully,
Dr. David White
^ permalink raw reply
* Re: [PATCH 0/3] crypto: picoxcell - Cleanups removing non-DT code
From: Javier Martinez Canillas @ 2017-01-02 17:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Jamie Iles, David S. Miller, linux-crypto,
Herbert Xu, linux-arm-kernel
In-Reply-To: <2309314.lMWYhcWsTB@wuerfel>
Hello Arnd,
On 01/02/2017 02:10 PM, Arnd Bergmann wrote:
> On Monday, January 2, 2017 2:06:56 PM CET Javier Martinez Canillas wrote:
>>
>> This small series contains a couple of cleanups that removes some driver's code
>> that isn't needed due the driver being for a DT-only platform.
>>
>> The changes were suggested by Arnd Bergmann as a response to a previous patch:
>> https://lkml.org/lkml/2017/1/2/342
>>
>> Patch #1 allows the driver to be built when the COMPILE_TEST option is enabled.
>> Patch #2 removes the platform ID table since isn't needed for DT-only drivers.
>> Patch #3 removes a wrapper function that's also not needed if driver is DT-only.
>>
>>
>
> Looks good, but I don't know if the first patch causes some build warnings
Thanks for looking at the patches.
> on non-ARM platforms, better wait at least for the 0-day build results,
> and maybe build-test on x86-32 and x86-64.
>
I should had mentioned that I built tested for arm, arm64, x86-32 and x86-64,
and saw now issues. But I agree with you that it's better to wait for the
0-day builder in case it reports issues on some platforms.
> Arnd
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH 0/3] crypto: picoxcell - Cleanups removing non-DT code
From: Arnd Bergmann @ 2017-01-02 17:10 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Herbert Xu, linux-kernel, linux-crypto, Jamie Iles,
David S. Miller, linux-arm-kernel
In-Reply-To: <1483376819-26726-1-git-send-email-javier@osg.samsung.com>
On Monday, January 2, 2017 2:06:56 PM CET Javier Martinez Canillas wrote:
>
> This small series contains a couple of cleanups that removes some driver's code
> that isn't needed due the driver being for a DT-only platform.
>
> The changes were suggested by Arnd Bergmann as a response to a previous patch:
> https://lkml.org/lkml/2017/1/2/342
>
> Patch #1 allows the driver to be built when the COMPILE_TEST option is enabled.
> Patch #2 removes the platform ID table since isn't needed for DT-only drivers.
> Patch #3 removes a wrapper function that's also not needed if driver is DT-only.
>
>
Looks good, but I don't know if the first patch causes some build warnings
on non-ARM platforms, better wait at least for the 0-day build results,
and maybe build-test on x86-32 and x86-64.
Arnd
^ permalink raw reply
* [PATCH 3/3] crypto: picoxcell - Remove spacc_is_compatible() wrapper function
From: Javier Martinez Canillas @ 2017-01-02 17:06 UTC (permalink / raw)
To: linux-kernel
Cc: Herbert Xu, Arnd Bergmann, Javier Martinez Canillas, linux-crypto,
Jamie Iles, David S. Miller, linux-arm-kernel
In-Reply-To: <1483376819-26726-1-git-send-email-javier@osg.samsung.com>
The function is used to check either the platform device ID name or the OF
node's compatible (depending how the device was registered) to know which
device type was registered.
But the driver is for a DT-only platform and so there's no need for this
level of indirection since the devices can only be registered via OF.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/crypto/picoxcell_crypto.c | 21 +++------------------
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
index 539effbbfc7a..b6f14844702e 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -1616,32 +1616,17 @@ static const struct of_device_id spacc_of_id_table[] = {
MODULE_DEVICE_TABLE(of, spacc_of_id_table);
#endif /* CONFIG_OF */
-static bool spacc_is_compatible(struct platform_device *pdev,
- const char *spacc_type)
-{
- const struct platform_device_id *platid = platform_get_device_id(pdev);
-
- if (platid && !strcmp(platid->name, spacc_type))
- return true;
-
-#ifdef CONFIG_OF
- if (of_device_is_compatible(pdev->dev.of_node, spacc_type))
- return true;
-#endif /* CONFIG_OF */
-
- return false;
-}
-
static int spacc_probe(struct platform_device *pdev)
{
int i, err, ret = -EINVAL;
struct resource *mem, *irq;
+ struct device_node *np = pdev->dev.of_node;
struct spacc_engine *engine = devm_kzalloc(&pdev->dev, sizeof(*engine),
GFP_KERNEL);
if (!engine)
return -ENOMEM;
- if (spacc_is_compatible(pdev, "picochip,spacc-ipsec")) {
+ if (of_device_is_compatible(np, "picochip,spacc-ipsec")) {
engine->max_ctxs = SPACC_CRYPTO_IPSEC_MAX_CTXS;
engine->cipher_pg_sz = SPACC_CRYPTO_IPSEC_CIPHER_PG_SZ;
engine->hash_pg_sz = SPACC_CRYPTO_IPSEC_HASH_PG_SZ;
@@ -1650,7 +1635,7 @@ static int spacc_probe(struct platform_device *pdev)
engine->num_algs = ARRAY_SIZE(ipsec_engine_algs);
engine->aeads = ipsec_engine_aeads;
engine->num_aeads = ARRAY_SIZE(ipsec_engine_aeads);
- } else if (spacc_is_compatible(pdev, "picochip,spacc-l2")) {
+ } else if (of_device_is_compatible(np, "picochip,spacc-l2")) {
engine->max_ctxs = SPACC_CRYPTO_L2_MAX_CTXS;
engine->cipher_pg_sz = SPACC_CRYPTO_L2_CIPHER_PG_SZ;
engine->hash_pg_sz = SPACC_CRYPTO_L2_HASH_PG_SZ;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] crypto: picoxcell - Remove platform device ID table
From: Javier Martinez Canillas @ 2017-01-02 17:06 UTC (permalink / raw)
To: linux-kernel
Cc: Herbert Xu, Arnd Bergmann, Javier Martinez Canillas, linux-crypto,
Jamie Iles, David S. Miller, linux-arm-kernel
In-Reply-To: <1483376819-26726-1-git-send-email-javier@osg.samsung.com>
This driver is only used in the picoxcell platform and this is DT-only.
So only a OF device ID table is needed and there's no need to have a
platform device ID table. This patch removes the unneeded table.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/crypto/picoxcell_crypto.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
index 47576098831f..539effbbfc7a 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -1803,12 +1803,6 @@ static int spacc_remove(struct platform_device *pdev)
return 0;
}
-static const struct platform_device_id spacc_id_table[] = {
- { "picochip,spacc-ipsec", },
- { "picochip,spacc-l2", },
- { }
-};
-
static struct platform_driver spacc_driver = {
.probe = spacc_probe,
.remove = spacc_remove,
@@ -1819,7 +1813,6 @@ static struct platform_driver spacc_driver = {
#endif /* CONFIG_PM */
.of_match_table = of_match_ptr(spacc_of_id_table),
},
- .id_table = spacc_id_table,
};
module_platform_driver(spacc_driver);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] crypto: picoxcell - Allow driver to build COMPILE_TEST is enabled
From: Javier Martinez Canillas @ 2017-01-02 17:06 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Javier Martinez Canillas, Herbert Xu, linux-crypto,
David S. Miller
In-Reply-To: <1483376819-26726-1-git-send-email-javier@osg.samsung.com>
Driver only has runtime but no build time dependency with ARCH_PICOXCELL.
So it can be built for testing purposes if COMPILE_TEST option is enabled.
This is useful to have more build coverage and make sure that the driver
is not affected by changes that could cause build regressions.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 79564785ae30..35b1c4829696 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -339,7 +339,7 @@ config CRYPTO_DEV_OMAP_DES
config CRYPTO_DEV_PICOXCELL
tristate "Support for picoXcell IPSEC and Layer2 crypto engines"
- depends on ARCH_PICOXCELL && HAVE_CLK
+ depends on (ARCH_PICOXCELL || COMPILE_TEST) && HAVE_CLK
select CRYPTO_AEAD
select CRYPTO_AES
select CRYPTO_AUTHENC
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] crypto: picoxcell - Cleanups removing non-DT code
From: Javier Martinez Canillas @ 2017-01-02 17:06 UTC (permalink / raw)
To: linux-kernel
Cc: Herbert Xu, Arnd Bergmann, Javier Martinez Canillas, linux-crypto,
Jamie Iles, David S. Miller, linux-arm-kernel
Hello,
This small series contains a couple of cleanups that removes some driver's code
that isn't needed due the driver being for a DT-only platform.
The changes were suggested by Arnd Bergmann as a response to a previous patch:
https://lkml.org/lkml/2017/1/2/342
Patch #1 allows the driver to be built when the COMPILE_TEST option is enabled.
Patch #2 removes the platform ID table since isn't needed for DT-only drivers.
Patch #3 removes a wrapper function that's also not needed if driver is DT-only.
Best regards,
Javier Martinez Canillas (3):
crypto: picoxcell - Allow driver to build COMPILE_TEST is enabled
crypto: picoxcell - Remove platform device ID table
crypto: picoxcell - Remove spacc_is_compatible() wrapper function
drivers/crypto/Kconfig | 2 +-
drivers/crypto/picoxcell_crypto.c | 28 +++-------------------------
2 files changed, 4 insertions(+), 26 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Javier Martinez Canillas @ 2017-01-02 16:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, Herbert Xu, linux-crypto,
Jamie Iles, David S. Miller
In-Reply-To: <2972455.z8LBYOSBAA@wuerfel>
On 01/02/2017 01:24 PM, Arnd Bergmann wrote:
> On Monday, January 2, 2017 1:13:24 PM CET Javier Martinez Canillas wrote:
>> Hello Arnd,
>>
>> On 01/02/2017 01:05 PM, Arnd Bergmann wrote:
>>> On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
>>>> If the driver is built as a module, autoload won't work because the module
>>>> alias information is not filled. So user-space can't match the registered
>>>> device with the corresponding module if the device isn't registered via OF.
>>>>
>>>> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>>>
>>> I think we can just remove the table, as the platform only supports
>>> booting through DT anyway.
>>>
>>
>> Agreed. I should had checked if mach-picoxcell was DT-only indeed.
>>
>> Should I also make the driver to depend on OF and remove the #ifdefery then?
>
> I don't think we need a dependency, the #ifdef checks in there were needed
> only to make the driver smaller if OF is disabled and it should still build
> fine if someone tries to compile it for CONFIG_COMPILE_TEST without
> CONFIG_OF.
>
OK, the driver doesn't depend on COMPILE_TEST though but I agree with you
since it seems the driver only has runtime but no build time dependencies
with ARCH_PICOXCELL.
> If we remove the platform ID, we can however also remove the
> spacc_is_compatible() function and just call of_device_is_compatible()
> in its place.
>
Yes.
> Arnd
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Arnd Bergmann @ 2017-01-02 16:24 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-arm-kernel, linux-kernel, Herbert Xu, linux-crypto,
Jamie Iles, David S. Miller
In-Reply-To: <ab87e239-6623-764b-998d-3d8148a6adf1@osg.samsung.com>
On Monday, January 2, 2017 1:13:24 PM CET Javier Martinez Canillas wrote:
> Hello Arnd,
>
> On 01/02/2017 01:05 PM, Arnd Bergmann wrote:
> > On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
> >> If the driver is built as a module, autoload won't work because the module
> >> alias information is not filled. So user-space can't match the registered
> >> device with the corresponding module if the device isn't registered via OF.
> >>
> >> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> >
> > I think we can just remove the table, as the platform only supports
> > booting through DT anyway.
> >
>
> Agreed. I should had checked if mach-picoxcell was DT-only indeed.
>
> Should I also make the driver to depend on OF and remove the #ifdefery then?
I don't think we need a dependency, the #ifdef checks in there were needed
only to make the driver smaller if OF is disabled and it should still build
fine if someone tries to compile it for CONFIG_COMPILE_TEST without
CONFIG_OF.
If we remove the platform ID, we can however also remove the
spacc_is_compatible() function and just call of_device_is_compatible()
in its place.
Arnd
^ permalink raw reply
* Re: [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Javier Martinez Canillas @ 2017-01-02 16:13 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: linux-kernel, Herbert Xu, linux-crypto, Jamie Iles,
David S. Miller
In-Reply-To: <2761495.aqgObxUbGB@wuerfel>
Hello Arnd,
On 01/02/2017 01:05 PM, Arnd Bergmann wrote:
> On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
>> If the driver is built as a module, autoload won't work because the module
>> alias information is not filled. So user-space can't match the registered
>> device with the corresponding module if the device isn't registered via OF.
>>
>> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> I think we can just remove the table, as the platform only supports
> booting through DT anyway.
>
Agreed. I should had checked if mach-picoxcell was DT-only indeed.
Should I also make the driver to depend on OF and remove the #ifdefery then?
> Arnd
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Arnd Bergmann @ 2017-01-02 16:05 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Javier Martinez Canillas, linux-kernel, Herbert Xu, linux-crypto,
Jamie Iles, David S. Miller
In-Reply-To: <1483371482-4956-1-git-send-email-javier@osg.samsung.com>
On Monday, January 2, 2017 12:38:02 PM CET Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module if the device isn't registered via OF.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
I think we can just remove the table, as the platform only supports
booting through DT anyway.
Arnd
^ permalink raw reply
* [PATCH] crypto: picoxcell - Fix module autoload for non-OF registration
From: Javier Martinez Canillas @ 2017-01-02 15:38 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, Jamie Iles, David S. Miller,
linux-crypto, Herbert Xu, linux-arm-kernel
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module if the device isn't registered via OF.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/crypto/picoxcell_crypto.ko | grep alias
alias: of:N*T*Cpicochip,spacc-l2C*
alias: of:N*T*Cpicochip,spacc-l2
alias: of:N*T*Cpicochip,spacc-ipsecC*
alias: of:N*T*Cpicochip,spacc-ipsec
After this patch:
$ modinfo drivers/crypto/picoxcell_crypto.ko | grep alias
alias: of:N*T*Cpicochip,spacc-l2C*
alias: of:N*T*Cpicochip,spacc-l2
alias: of:N*T*Cpicochip,spacc-ipsecC*
alias: of:N*T*Cpicochip,spacc-ipsec
alias: platform:picochip,spacc-l2
alias: platform:picochip,spacc-ipsec
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/crypto/picoxcell_crypto.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
index 47576098831f..64449b7c00af 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -1808,6 +1808,7 @@ static const struct platform_device_id spacc_id_table[] = {
{ "picochip,spacc-l2", },
{ }
};
+MODULE_DEVICE_TABLE(platform, spacc_id_table);
static struct platform_driver spacc_driver = {
.probe = spacc_probe,
--
2.7.4
^ permalink raw reply related
* [PATCH] crypto: kpp - clear CRYPTO_ALG_DEAD bit in prepare_alg
From: Salvatore Benedetto @ 2017-01-02 13:33 UTC (permalink / raw)
To: herbert; +Cc: salvatore.benedetto, linux-crypto
Make sure CRYPTO_ALG_DEAD is not set when preparing for
alg registration. This fixes qat-dh registration that occurs
when reloading qat_c62x module.
Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
---
crypto/kpp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/kpp.c b/crypto/kpp.c
index d36ce05..d1adef8e 100644
--- a/crypto/kpp.c
+++ b/crypto/kpp.c
@@ -101,6 +101,7 @@ static void kpp_prepare_alg(struct kpp_alg *alg)
base->cra_type = &crypto_kpp_type;
base->cra_flags &= ~CRYPTO_ALG_TYPE_MASK;
+ base->cra_flags &= ~CRYPTO_ALG_DEAD;
base->cra_flags |= CRYPTO_ALG_TYPE_KPP;
}
--
2.4.11
^ permalink raw reply related
* Re: [RFC PATCH v2] crypto: Add IV generation algorithms
From: Binoy Jayan @ 2017-01-02 7:05 UTC (permalink / raw)
To: Herbert Xu
Cc: Milan Broz, Oded, Ofir, David S. Miller, linux-crypto, Mark Brown,
Arnd Bergmann, Linux kernel mailing list, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra
In-Reply-To: <20170102065325.GA19553@gondor.apana.org.au>
On 2 January 2017 at 12:23, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote:
>>
>> Even if ciphers are allocated this way, all the encryption requests
>> for cbc should still go through IV generators? So that should mean,
>> create one instance of IV generator using 'crypto_alloc_skcipher'
>> and create tfms_count instances of the generator depending on the
>> number of keys.
>
> Right. The actual number of underlying tfms that do the work
> won't change compared to the status quo. We're just structuring
> it such that if the overall scheme is supported by the hardware
> then we can feed more than one sector at a time to it.
Thank you Herbert.
^ permalink raw reply
* Re: [RFC PATCH v2] crypto: Add IV generation algorithms
From: Herbert Xu @ 2017-01-02 6:53 UTC (permalink / raw)
To: Binoy Jayan
Cc: Milan Broz, Oded, Ofir, David S. Miller, linux-crypto, Mark Brown,
Arnd Bergmann, Linux kernel mailing list, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra
In-Reply-To: <CAHv-k_8FmeKk_3zUAVCqHp82nHmiWsyfZ_BW+z=SC5VVOrFsAA@mail.gmail.com>
On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote:
>
> Even if ciphers are allocated this way, all the encryption requests
> for cbc should still go through IV generators? So that should mean,
> create one instance of IV generator using 'crypto_alloc_skcipher'
> and create tfms_count instances of the generator depending on the
> number of keys.
Right. The actual number of underlying tfms that do the work
won't change compared to the status quo. We're just structuring
it such that if the overall scheme is supported by the hardware
then we can feed more than one sector at a time to it.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH v2] crypto: Add IV generation algorithms
From: Binoy Jayan @ 2017-01-02 6:46 UTC (permalink / raw)
To: Herbert Xu
Cc: Milan Broz, Oded, Ofir, David S. Miller, linux-crypto, Mark Brown,
Arnd Bergmann, Linux kernel mailing list, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra
In-Reply-To: <20161230102723.GA15713@gondor.apana.org.au>
Hi Herbert,
On 30 December 2016 at 15:57, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> This is just a matter of structuring the key for the IV generator.
> The IV generator's key in this case should be a combination of the
> key to the underlying CBC plus the set of all keys for the IV
> generator itself. It should then allocate the required number of
> tfms as is currently done by crypt_alloc_tfms in dm-crypt.
Since I used template ciphers for the iv algorithms, I use
crypto_spawn_skcipher_alg and skcipher_register_instance
for creating the underlying cbc algorithm. I guess you suggest
to change that to make use of crypto_alloc_skcipher.
Even if ciphers are allocated this way, all the encryption requests
for cbc should still go through IV generators? So that should mean,
create one instance of IV generator using 'crypto_alloc_skcipher'
and create tfms_count instances of the generator depending on the
number of keys.
Thanks,
Binoy
^ permalink raw reply
* [PATCH] crypto: Replaced gcc specific attributes with macros from compiler.h
From: gidisrael @ 2016-12-31 15:56 UTC (permalink / raw)
To: linux-kernel, linux-crypto, herbert, davem, nhorman, joe, akpm
Cc: Gideon Israel Dsouza
From: Gideon Israel Dsouza <gidisrael@gmail.com>
Continuing from this commit: 52f5684c8e1e
("kernel: use macros from compiler.h instead of __attribute__((...))")
I submitted 4 total patches. They are part of task I've taken up to
increase compiler portability in the kernel. I've cleaned up the
subsystems under /kernel /mm /block and /security, this patch targets
/crypto.
There is <linux/compiler.h> which provides macros for various gcc specific
constructs. Eg: __weak for __attribute__((weak)). I've cleaned all
instances of gcc specific attributes with the right macros for the crypto
subsystem.
I had to make one additional change into compiler-gcc.h for the case when
one wants to use this: __attribute__((aligned) and not specify an alignment
factor. From the gcc docs, this will result in the largest alignment for
that data type on the target machine so I've named the macro
__aligned_largest. Please advise if another name is more appropriate.
Signed-off-by: Gideon Israel Dsouza <gidisrael@gmail.com>
---
crypto/ablkcipher.c | 5 +++--
crypto/acompress.c | 3 ++-
crypto/aead.c | 3 ++-
crypto/ahash.c | 3 ++-
crypto/akcipher.c | 3 ++-
crypto/blkcipher.c | 7 ++++---
crypto/cts.c | 5 +++--
crypto/kpp.c | 3 ++-
crypto/pcbc.c | 3 ++-
crypto/rng.c | 3 ++-
crypto/scompress.c | 3 ++-
crypto/shash.c | 9 +++++----
crypto/skcipher.c | 3 ++-
include/linux/compiler-gcc.h | 1 +
14 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index d676fc5..d880a48 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/seq_file.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <net/netlink.h>
#include <crypto/scatterwalk.h>
@@ -394,7 +395,7 @@ static int crypto_ablkcipher_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_ablkcipher_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_ablkcipher_show(struct seq_file *m, struct crypto_alg *alg)
{
struct ablkcipher_alg *ablkcipher = &alg->cra_ablkcipher;
@@ -468,7 +469,7 @@ static int crypto_givcipher_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_givcipher_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_givcipher_show(struct seq_file *m, struct crypto_alg *alg)
{
struct ablkcipher_alg *ablkcipher = &alg->cra_ablkcipher;
diff --git a/crypto/acompress.c b/crypto/acompress.c
index 887783d..47d1162 100644
--- a/crypto/acompress.c
+++ b/crypto/acompress.c
@@ -20,6 +20,7 @@
#include <linux/crypto.h>
#include <crypto/algapi.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <net/netlink.h>
#include <crypto/internal/acompress.h>
#include <crypto/internal/scompress.h>
@@ -50,7 +51,7 @@ static int crypto_acomp_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_acomp_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_acomp_show(struct seq_file *m, struct crypto_alg *alg)
{
diff --git a/crypto/aead.c b/crypto/aead.c
index 3f5c5ff..f794b30 100644
--- a/crypto/aead.c
+++ b/crypto/aead.c
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/seq_file.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <net/netlink.h>
#include "internal.h"
@@ -132,7 +133,7 @@ static int crypto_aead_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_aead_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_aead_show(struct seq_file *m, struct crypto_alg *alg)
{
struct aead_alg *aead = container_of(alg, struct aead_alg, base);
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 2ce8bcb..e58c497 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -23,6 +23,7 @@
#include <linux/slab.h>
#include <linux/seq_file.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <net/netlink.h>
#include "internal.h"
@@ -493,7 +494,7 @@ static int crypto_ahash_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_ahash_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_ahash_show(struct seq_file *m, struct crypto_alg *alg)
{
seq_printf(m, "type : ahash\n");
diff --git a/crypto/akcipher.c b/crypto/akcipher.c
index def301e..cfbdb06 100644
--- a/crypto/akcipher.c
+++ b/crypto/akcipher.c
@@ -17,6 +17,7 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/crypto.h>
+#include <linux/compiler.h>
#include <crypto/algapi.h>
#include <linux/cryptouser.h>
#include <net/netlink.h>
@@ -47,7 +48,7 @@ static int crypto_akcipher_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_akcipher_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_akcipher_show(struct seq_file *m, struct crypto_alg *alg)
{
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index a832426..6c43a0a 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -1,6 +1,6 @@
/*
* Block chaining cipher operations.
- *
+ *
* Generic encrypt/decrypt wrapper for ciphers, handles operations across
* multiple page boundaries by using temporary blocks. In user context,
* the kernel is given a chance to schedule us once per page.
@@ -9,7 +9,7 @@
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option)
+ * Software Foundation; either version 2 of the License, or (at your option)
* any later version.
*
*/
@@ -25,6 +25,7 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <net/netlink.h>
#include "internal.h"
@@ -534,7 +535,7 @@ static int crypto_blkcipher_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_blkcipher_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_blkcipher_show(struct seq_file *m, struct crypto_alg *alg)
{
seq_printf(m, "type : blkcipher\n");
diff --git a/crypto/cts.c b/crypto/cts.c
index 00254d7..a1335d6 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -49,6 +49,7 @@
#include <linux/scatterlist.h>
#include <crypto/scatterwalk.h>
#include <linux/slab.h>
+#include <linux/compiler.h>
struct crypto_cts_ctx {
struct crypto_skcipher *child;
@@ -103,7 +104,7 @@ static int cts_cbc_encrypt(struct skcipher_request *req)
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct skcipher_request *subreq = &rctx->subreq;
int bsize = crypto_skcipher_blocksize(tfm);
- u8 d[bsize * 2] __attribute__ ((aligned(__alignof__(u32))));
+ u8 d[bsize * 2] __aligned(__alignof__(u32));
struct scatterlist *sg;
unsigned int offset;
int lastn;
@@ -183,7 +184,7 @@ static int cts_cbc_decrypt(struct skcipher_request *req)
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct skcipher_request *subreq = &rctx->subreq;
int bsize = crypto_skcipher_blocksize(tfm);
- u8 d[bsize * 2] __attribute__ ((aligned(__alignof__(u32))));
+ u8 d[bsize * 2] __aligned(__alignof__(u32));
struct scatterlist *sg;
unsigned int offset;
u8 *space;
diff --git a/crypto/kpp.c b/crypto/kpp.c
index d36ce05..a90edc2 100644
--- a/crypto/kpp.c
+++ b/crypto/kpp.c
@@ -19,6 +19,7 @@
#include <linux/crypto.h>
#include <crypto/algapi.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <net/netlink.h>
#include <crypto/kpp.h>
#include <crypto/internal/kpp.h>
@@ -47,7 +48,7 @@ static int crypto_kpp_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_kpp_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_kpp_show(struct seq_file *m, struct crypto_alg *alg)
{
diff --git a/crypto/pcbc.c b/crypto/pcbc.c
index e4538e0..11d2486 100644
--- a/crypto/pcbc.c
+++ b/crypto/pcbc.c
@@ -20,6 +20,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/slab.h>
+#include <linux/compiler.h>
struct crypto_pcbc_ctx {
struct crypto_cipher *child;
@@ -146,7 +147,7 @@ static int crypto_pcbc_decrypt_inplace(struct skcipher_request *req,
unsigned int nbytes = walk->nbytes;
u8 *src = walk->src.virt.addr;
u8 *iv = walk->iv;
- u8 tmpbuf[bsize] __attribute__ ((aligned(__alignof__(u32))));
+ u8 tmpbuf[bsize] __aligned(__alignof__(u32));
do {
memcpy(tmpbuf, src, bsize);
diff --git a/crypto/rng.c b/crypto/rng.c
index b81cffb..f46dac5 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -23,6 +23,7 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <net/netlink.h>
#include "internal.h"
@@ -95,7 +96,7 @@ static int crypto_rng_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_rng_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_rng_show(struct seq_file *m, struct crypto_alg *alg)
{
seq_printf(m, "type : rng\n");
diff --git a/crypto/scompress.c b/crypto/scompress.c
index 35e396d..6b048b3 100644
--- a/crypto/scompress.c
+++ b/crypto/scompress.c
@@ -18,6 +18,7 @@
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/crypto.h>
+#include <linux/compiler.h>
#include <linux/vmalloc.h>
#include <crypto/algapi.h>
#include <linux/cryptouser.h>
@@ -57,7 +58,7 @@ static int crypto_scomp_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_scomp_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_scomp_show(struct seq_file *m, struct crypto_alg *alg)
{
diff --git a/crypto/shash.c b/crypto/shash.c
index a051541..5e31c8d 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -19,6 +19,7 @@
#include <linux/seq_file.h>
#include <linux/cryptouser.h>
#include <net/netlink.h>
+#include <linux/compiler.h>
#include "internal.h"
@@ -67,7 +68,7 @@ EXPORT_SYMBOL_GPL(crypto_shash_setkey);
static inline unsigned int shash_align_buffer_size(unsigned len,
unsigned long mask)
{
- typedef u8 __attribute__ ((aligned)) u8_aligned;
+ typedef u8 __aligned_largest u8_aligned;
return len + (mask & ~(__alignof__(u8_aligned) - 1));
}
@@ -80,7 +81,7 @@ static int shash_update_unaligned(struct shash_desc *desc, const u8 *data,
unsigned int unaligned_len = alignmask + 1 -
((unsigned long)data & alignmask);
u8 ubuf[shash_align_buffer_size(unaligned_len, alignmask)]
- __attribute__ ((aligned));
+ __aligned_largest;
u8 *buf = PTR_ALIGN(&ubuf[0], alignmask + 1);
int err;
@@ -116,7 +117,7 @@ static int shash_final_unaligned(struct shash_desc *desc, u8 *out)
struct shash_alg *shash = crypto_shash_alg(tfm);
unsigned int ds = crypto_shash_digestsize(tfm);
u8 ubuf[shash_align_buffer_size(ds, alignmask)]
- __attribute__ ((aligned));
+ __aligned_largest;
u8 *buf = PTR_ALIGN(&ubuf[0], alignmask + 1);
int err;
@@ -403,7 +404,7 @@ static int crypto_shash_report(struct sk_buff *skb, struct crypto_alg *alg)
#endif
static void crypto_shash_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_shash_show(struct seq_file *m, struct crypto_alg *alg)
{
struct shash_alg *salg = __crypto_shash_alg(alg);
diff --git a/crypto/skcipher.c b/crypto/skcipher.c
index 0e1e6c3..1a0bd92 100644
--- a/crypto/skcipher.c
+++ b/crypto/skcipher.c
@@ -19,6 +19,7 @@
#include <crypto/scatterwalk.h>
#include <linux/bug.h>
#include <linux/cryptouser.h>
+#include <linux/compiler.h>
#include <linux/list.h>
#include <linux/module.h>
#include <linux/rtnetlink.h>
@@ -807,7 +808,7 @@ static void crypto_skcipher_free_instance(struct crypto_instance *inst)
}
static void crypto_skcipher_show(struct seq_file *m, struct crypto_alg *alg)
- __attribute__ ((unused));
+ __maybe_unused;
static void crypto_skcipher_show(struct seq_file *m, struct crypto_alg *alg)
{
struct skcipher_alg *skcipher = container_of(alg, struct skcipher_alg,
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 0444b13..fddd1a5 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -116,6 +116,7 @@
*/
#define __pure __attribute__((pure))
#define __aligned(x) __attribute__((aligned(x)))
+#define __aligned_largest __attribute__((aligned))
#define __printf(a, b) __attribute__((format(printf, a, b)))
#define __scanf(a, b) __attribute__((format(scanf, a, b)))
#define __attribute_const__ __attribute__((__const__))
--
2.7.4
^ permalink raw reply related
* Geode LX AES/RNG driver triggers warning
From: David Gstir @ 2016-12-30 23:58 UTC (permalink / raw)
To: linux-geode, linux-crypto
Cc: linux-kernel, teheo, prasannatsmkumar, Richard Weinberger
Hi!
I recently tested kernel v4.9 on my AMD Geode platform and noticed that its AES hardware driver triggers this warning on initialization:
[ 1.265708] ------------[ cut here ]------------
[ 1.267932] WARNING: CPU: 0 PID: 1 at drivers/base/dd.c:344 driver_probe_device+0x5d/0x1ad
[ 1.272427] CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.0 #2
[ 1.277416] cf82be70 c1153046 cf82be8c c102a98b 00000158 c11ad3ab cf8b9868 c14342b4
[ 1.297179] c14342b4 cf82bea0 c102aa0e 00000009 00000000 00000000 cf82beb8 c11ad3ab
[ 1.316912] 00000000 cf8b9868 c14342b4 cf8b989c cf82becc c11ad553 00000000 c14342b4
[ 1.336645] Call Trace:
[ 1.340044] [<c1153046>] dump_stack+0x16/0x18
[ 1.345423] [<c102a98b>] __warn+0xa0/0xb7
[ 1.349743] [<c11ad3ab>] ? driver_probe_device+0x5d/0x1ad
[ 1.354224] [<c102aa0e>] warn_slowpath_null+0x11/0x16
[ 1.357663] [<c11ad3ab>] driver_probe_device+0x5d/0x1ad
[ 1.361621] [<c11ad553>] __driver_attach+0x58/0x74
[ 1.364282] [<c11ac1d7>] bus_for_each_dev+0x4b/0x68
[ 1.367202] [<c11ad6c2>] driver_attach+0x14/0x16
[ 1.373345] [<c11ad4fb>] ? driver_probe_device+0x1ad/0x1ad
[ 1.378087] [<c11ac7b4>] bus_add_driver+0xaf/0x181
[ 1.380750] [<c1467007>] ? firmware_map_add_early+0xaa/0xaa
[ 1.385746] [<c11ad9f7>] driver_register+0x6f/0xa4
[ 1.388405] [<c1467007>] ? firmware_map_add_early+0xaa/0xaa
[ 1.393414] [<c117ae35>] __pci_register_driver+0x27/0x2a
[ 1.397628] [<c146701b>] geode_aes_driver_init+0x14/0x16
[ 1.401846] [<c144ab1e>] do_one_initcall+0x7c/0xec
[ 1.404516] [<c103a5a0>] ? parse_args+0x1c3/0x283
[ 1.410913] [<c144ac48>] ? kernel_init_freeable+0xba/0x157
[ 1.411646] [<c144ac68>] kernel_init_freeable+0xda/0x157
[ 1.415872] [<c12f998d>] ? rest_init+0x59/0x59
[ 1.421489] [<c12f9995>] kernel_init+0x8/0xcb
[ 1.426856] [<c12fbb77>] ret_from_fork+0x1b/0x28
[ 1.428999] ---[ end trace 24dfe638898c8e1f ]---
I narrowed it down to commit 6e9b5e76882c ("hwrng: geode - Migrate to managed API") which seems to introduce this. It looks to me like some issue between devres, the Geode hwrng and AES drivers which both use the same PCI device.
I'm no expert here, but I curious if this will cause any issues when using the hardware crypto drivers and also what's the best way to get rid of this?
Thanks,
David
^ permalink raw reply
* [PATCH] crypto: testmgr - use kmemdup instead of kmalloc+memcpy
From: Eric Biggers @ 2016-12-30 20:12 UTC (permalink / raw)
To: linux-crypto; +Cc: Herbert Xu, David S. Miller, Laura Abbott, Eric Biggers
From: Eric Biggers <ebiggers@google.com>
It's recommended to use kmemdup instead of kmalloc followed by memcpy.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/testmgr.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 44e888b0b041..881176ebd8a8 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1463,13 +1463,12 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
int ilen = ctemplate[i].inlen;
void *input_vec;
- input_vec = kmalloc(ilen, GFP_KERNEL);
+ input_vec = kmemdup(ctemplate[i].input, ilen, GFP_KERNEL);
if (!input_vec) {
ret = -ENOMEM;
goto out;
}
- memcpy(input_vec, ctemplate[i].input, ilen);
memset(output, 0, dlen);
init_completion(&result.completion);
sg_init_one(&src, input_vec, ilen);
@@ -1525,13 +1524,12 @@ static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
int ilen = dtemplate[i].inlen;
void *input_vec;
- input_vec = kmalloc(ilen, GFP_KERNEL);
+ input_vec = kmemdup(dtemplate[i].input, ilen, GFP_KERNEL);
if (!input_vec) {
ret = -ENOMEM;
goto out;
}
- memcpy(input_vec, dtemplate[i].input, ilen);
memset(output, 0, dlen);
init_completion(&result.completion);
sg_init_one(&src, input_vec, ilen);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] virtio-crypto: support crypto engine framework
From: Herbert Xu @ 2016-12-30 12:20 UTC (permalink / raw)
To: Gonglei
Cc: linux-kernel, virtualization, linux-crypto, wu.wubin, longpeng2,
Baolin Wang, Michael S . Tsirkin
In-Reply-To: <1482821347-47664-1-git-send-email-arei.gonglei@huawei.com>
On Tue, Dec 27, 2016 at 02:49:07PM +0800, Gonglei wrote:
> crypto engine was introduced since 'commit 735d37b5424b ("crypto: engine
> - Introduce the block request crypto engine framework")' which uses work
> queue to realize the asynchronous processing for ablk_cipher and ahash.
>
> For virtio-crypto device, I register an engine for each
> data virtqueue so that we can use the capability of
> multiple data queues in future.
>
> Cc: Baolin Wang <baolin.wang@linaro.org>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH] crypto: skcipher - introduce walksize attribute for SIMD algos
From: Herbert Xu @ 2016-12-30 12:21 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1483020548-19233-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Dec 29, 2016 at 02:09:08PM +0000, Ard Biesheuvel wrote:
> In some cases, SIMD algorithms can only perform optimally when
> allowed to operate on multiple input blocks in parallel. This is
> especially true for bit slicing algorithms, which typically take
> the same amount of time processing a single block or 8 blocks in
> parallel. However, other SIMD algorithms may benefit as well from
> bigger strides.
>
> So add a walksize attribute to the skcipher algorithm definition, and
> wire it up to the skcipher walk API. To avoid confusion between the
> skcipher and AEAD attributes, rename the skcipher_walk chunksize
> attribute to 'stride', and set it from the walksize (in the skcipher
> case) or from the chunksize (in the AEAD case).
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - increase number of supported devices
From: Herbert Xu @ 2016-12-30 12:20 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu, Xin Zeng
In-Reply-To: <20161222150102.6376-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 03:01:02PM +0000, Giovanni Cabiddu wrote:
> From: Xin Zeng <xin.zeng@intel.com>
>
> The unsigned long type for init_status and start_status in
> service_hndl are not long enough to represent more than 64
> acceleration devices. Use an array instead.
>
> Signed-off-by: Xin Zeng <xin.zeng@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox