* Re: [PATCH -next] crypto: gcm - Fix error return code in crypto_gcm_create_common()
From: Herbert Xu @ 2016-10-25 3:39 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Wei Yongjun, linux-crypto
In-Reply-To: <1476717006-10086-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 17, 2016 at 03:10:06PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return error code -EINVAL from the invalid alg ivsize error
> handling case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@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: [PATCH] crypto: ccp - change bitfield type to unsigned ints
From: Herbert Xu @ 2016-10-25 3:40 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147682971521.8147.5364792807816963275.stgit@taos.amd.com>
On Tue, Oct 18, 2016 at 05:28:35PM -0500, Gary R Hook wrote:
> Bit fields are not sensitive to endianness, so use
> a transparent standard data type
>
> Signed-off-by: Gary R Hook <gary.hook@amd.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: [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Herbert Xu @ 2016-10-25 3:40 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Jason Gunthorpe, Kevin Hilman, Neil Armstrong,
PrasannaKumar Muralidharan, Carlo Caione, linux-amlogic,
Matt Mackall, linux-arm-kernel, linux-crypto
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>
On Mon, Oct 17, 2016 at 04:51:17PM -0300, 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.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
>
> After this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
> alias: of:N*T*Camlogic,meson-rngC*
> alias: of:N*T*Camlogic,meson-rng
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.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: [PATCH] crypto: ccp - remove unneeded code
From: Herbert Xu @ 2016-10-25 3:42 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147682972966.8169.12625496646634682202.stgit@taos.amd.com>
On Tue, Oct 18, 2016 at 05:28:49PM -0500, Gary R Hook wrote:
> Clean up patch for an unneeded structure member.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.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: [PATCH] crypto: ccp - Clean up the LSB slot allocation code
From: Herbert Xu @ 2016-10-25 3:43 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147683001790.8273.9550490485955104780.stgit@taos.amd.com>
On Tue, Oct 18, 2016 at 05:33:37PM -0500, Gary R Hook wrote:
> Fix a few problems revealed by testing: verify consistent
> units, especially in public slot allocation. Percolate
> some common initialization code up to a common routine.
> Add some comments.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.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: [PATCH] crypto: engine - Handle the kthread worker using the new API
From: Herbert Xu @ 2016-10-25 3:43 UTC (permalink / raw)
To: Petr Mladek; +Cc: David S. Miller, linux-crypto, Tejun Heo, linux-kernel
In-Reply-To: <1476878070-12024-1-git-send-email-pmladek@suse.com>
On Wed, Oct 19, 2016 at 01:54:30PM +0200, Petr Mladek wrote:
> Use the new API to create and destroy the crypto engine kthread
> worker. The API hides some implementation details.
>
> In particular, kthread_create_worker() allocates and initializes
> struct kthread_worker. It runs the kthread the right way
> and stores task_struct into the worker structure.
>
> kthread_destroy_worker() flushes all pending works, stops
> the kthread and frees the structure.
>
> This patch does not change the existing behavior except for
> dynamically allocating struct kthread_worker and storing
> only the pointer of this structure.
>
> It is compile tested only because I did not find an easy
> way how to run the code. Well, it should be pretty safe
> given the nature of the change.
>
> Signed-off-by: Petr Mladek <pmladek@suse.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: [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS
From: Herbert Xu @ 2016-10-25 3:43 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Kevin Hilman, Neil Armstrong,
PrasannaKumar Muralidharan, Carlo Caione, linux-amlogic,
Matt Mackall, linux-arm-kernel, linux-crypto
In-Reply-To: <1476906618-14455-1-git-send-email-javier@osg.samsung.com>
On Wed, Oct 19, 2016 at 04:50:18PM -0300, Javier Martinez Canillas wrote:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
>
> So there's no need to have a MODULE_ALIAS("platform:meson-rng") since
> the reported uevent MODALIAS to user-space will always be the OF one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.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: [PATCH][TRIVIAL] crypto: ccp - fix typo "CPP"
From: Herbert Xu @ 2016-10-25 3:46 UTC (permalink / raw)
To: Paul Bolle
Cc: trivial, thomas.lendacky, gary.hook, linux-crypto, linux-kernel
In-Reply-To: <1476991259-4061-1-git-send-email-pebolle@tiscali.nl>
Paul Bolle <pebolle@tiscali.nl> wrote:
> The abbreviation for Cryptographic Coprocessor is "CCP".
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
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 v10 0/8] crypto: asynchronous compression api
From: Herbert Xu @ 2016-10-25 3:47 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto
In-Reply-To: <1477052394-19826-1-git-send-email-giovanni.cabiddu@intel.com>
On Fri, Oct 21, 2016 at 01:19:46PM +0100, Giovanni Cabiddu wrote:
> The following patch set introduces acomp, a generic asynchronous
> (de)compression api with support for SG lists.
> We propose a new crypto type called crypto_acomp_type, a new struct acomp_alg
> and struct crypto_acomp, together with number of helper functions to register
> acomp type algorithms and allocate tfm instances.
> This interface will allow the following operations:
>
> int (*compress)(struct acomp_req *req);
> int (*decompress)(struct acomp_req *req);
>
> Together with acomp we propose a new driver-side interface, scomp, which
> handles compression implementations which use linear buffers. We converted all
> compression algorithms available in LKCF to use this interface so that those
> algorithms will be accessible through the acomp api.
>
> Changes in v10:
> - fixed build issues for configurations where CONFIG_CRYPTO_USER is defined
All applied. Thanks a lot Giovanni!
--
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] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-25 5:38 UTC (permalink / raw)
To: Maxime Ripard
Cc: srinivas.kandagatla, wens, linux-kernel, linux-arm-kernel,
linux-crypto
In-Reply-To: <20161024201020.h6akyqad2o42xkhq@lukather>
On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > Since SID's content is constant over reboot,
>
> That's not true, at least not across all the Allwinner SoCs, and
> especially not on the A10 and A20 that this driver supports.
>
On my cubieboard2 (A20)
hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
cubiedev ~ # reboot
cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
So clearly for me its constant.
> > it must not be used as source of randomness.
>
> And I don't think that's true either. A constant entropy provider will
> not add any entropy, but will not remove any, would it?
I cced linux-crypto at the begining for confirmation on that.
But the problem is increased as a part of the content is predicatable over same type of device (at least the thirst bytes and all the zeros).
^ permalink raw reply
* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Jean-Francois Moine @ 2016-10-25 7:06 UTC (permalink / raw)
To: LABBE Corentin
Cc: Maxime Ripard, wens, srinivas.kandagatla, linux-kernel,
linux-arm-kernel, linux-crypto
In-Reply-To: <20161025053855.GA901@Red>
On Tue, 25 Oct 2016 07:38:55 +0200
LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> >
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> >
>
> On my cubieboard2 (A20)
> hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
>
> So clearly for me its constant.
Even after power off/power on?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* Re: [PATCH v2] char: hw_random: atmel-rng: disable TRNG during suspend
From: Nicolas Ferre @ 2016-10-25 8:49 UTC (permalink / raw)
To: Wenyou Yang, Herbert Xu, Matt Mackall
Cc: linux-crypto, Wenyou Yang, linux-arm-kernel
In-Reply-To: <1477356993-27778-1-git-send-email-wenyou.yang@atmel.com>
Le 25/10/2016 à 02:56, Wenyou Yang a écrit :
> To fix the over consumption on the VDDCore due to the TRNG enabled,
> disable the TRNG during suspend, not only disable the user interface
> clock (which is controlled by PMC). Because the user interface clock
> is independent from any clock that may be used in the entropy source
> logic circuitry.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks
> ---
>
> Changes in v2:
> - Enable the user interface first, then enable the internal clock
> when resume.
>
> drivers/char/hw_random/atmel-rng.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
> index 0fcc9e6..ae7cae5 100644
> --- a/drivers/char/hw_random/atmel-rng.c
> +++ b/drivers/char/hw_random/atmel-rng.c
> @@ -48,6 +48,16 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
> return 0;
> }
>
> +static void atmel_trng_enable(struct atmel_trng *trng)
> +{
> + writel(TRNG_KEY | 1, trng->base + TRNG_CR);
> +}
> +
> +static void atmel_trng_disable(struct atmel_trng *trng)
> +{
> + writel(TRNG_KEY, trng->base + TRNG_CR);
> +}
> +
> static int atmel_trng_probe(struct platform_device *pdev)
> {
> struct atmel_trng *trng;
> @@ -71,7 +81,7 @@ static int atmel_trng_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - writel(TRNG_KEY | 1, trng->base + TRNG_CR);
> + atmel_trng_enable(trng);
> trng->rng.name = pdev->name;
> trng->rng.read = atmel_trng_read;
>
> @@ -94,7 +104,7 @@ static int atmel_trng_remove(struct platform_device *pdev)
>
> hwrng_unregister(&trng->rng);
>
> - writel(TRNG_KEY, trng->base + TRNG_CR);
> + atmel_trng_disable(trng);
> clk_disable_unprepare(trng->clk);
>
> return 0;
> @@ -105,6 +115,7 @@ static int atmel_trng_suspend(struct device *dev)
> {
> struct atmel_trng *trng = dev_get_drvdata(dev);
>
> + atmel_trng_disable(trng);
> clk_disable_unprepare(trng->clk);
>
> return 0;
> @@ -113,8 +124,15 @@ static int atmel_trng_suspend(struct device *dev)
> static int atmel_trng_resume(struct device *dev)
> {
> struct atmel_trng *trng = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(trng->clk);
> + if (ret)
> + return ret;
>
> - return clk_prepare_enable(trng->clk);
> + atmel_trng_enable(trng);
> +
> + return 0;
> }
>
> static const struct dev_pm_ops atmel_trng_pm_ops = {
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] crypto: sahara: fix typo "Decidated" -> "Dedicated"
From: Colin King @ 2016-10-25 11:07 UTC (permalink / raw)
To: Herbert Xu, linux-crypto; +Cc: David S . Miller, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to typo in dev_dbg message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/crypto/sahara.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 0c49956..7ba0eae 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -390,7 +390,7 @@ static void sahara_decode_status(struct sahara_dev *dev, unsigned int status)
if (status & SAHARA_STATUS_MODE_BATCH)
dev_dbg(dev->device, " - Batch Mode.\n");
else if (status & SAHARA_STATUS_MODE_DEDICATED)
- dev_dbg(dev->device, " - Decidated Mode.\n");
+ dev_dbg(dev->device, " - Dedicated Mode.\n");
else if (status & SAHARA_STATUS_MODE_DEBUG)
dev_dbg(dev->device, " - Debug Mode.\n");
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Maxime Ripard @ 2016-10-25 13:26 UTC (permalink / raw)
To: LABBE Corentin
Cc: wens, srinivas.kandagatla, linux-kernel, linux-arm-kernel,
linux-crypto
In-Reply-To: <20161025053855.GA901@Red>
[-- Attachment #1.1: Type: text/plain, Size: 1646 bytes --]
On Tue, Oct 25, 2016 at 07:38:55AM +0200, LABBE Corentin wrote:
> On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> >
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> >
>
> On my cubieboard2 (A20)
> hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
>
> So clearly for me its constant.
It's constant across reboots, but not across devices. Each device have
a different SID content, therefore it's a relevant source of entropy
in the system.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: J. Bruce Fields @ 2016-10-25 18:45 UTC (permalink / raw)
To: linux-nfs-u79uwXL29TY76Z2rM5mHXA
Cc: Rusty Russell, Christoph Hellwig,
linux-crypto-u79uwXL29TY76Z2rM5mHXA
From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
among other callers, passes it memory on the stack.
We only need a scatterlist to pass this to the crypto code, and it seems
like overkill to require kmalloc'd memory just to encrypt a few bytes,
but for now this seems the best fix.
Note many of these callers are in the NFS write paths, so we shouldn't
really be allocating GFP_KERNEL. But we already have other allocations
in these code paths. A larger redesign may be necessary to allow
allocations to be done earlier.
Cc: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
net/sunrpc/auth_gss/auth_gss.c | 13 ++++--
net/sunrpc/auth_gss/gss_krb5_crypto.c | 82 ++++++++++++++++++++---------------
net/sunrpc/auth_gss/svcauth_gss.c | 21 ++++++---
3 files changed, 71 insertions(+), 45 deletions(-)
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index d8bd97a5a7c9..6ecc30058f95 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -1616,7 +1616,7 @@ gss_validate(struct rpc_task *task, __be32 *p)
{
struct rpc_cred *cred = task->tk_rqstp->rq_cred;
struct gss_cl_ctx *ctx = gss_cred_get_ctx(cred);
- __be32 seq;
+ __be32 *seq = NULL;
struct kvec iov;
struct xdr_buf verf_buf;
struct xdr_netobj mic;
@@ -1631,9 +1631,12 @@ gss_validate(struct rpc_task *task, __be32 *p)
goto out_bad;
if (flav != RPC_AUTH_GSS)
goto out_bad;
- seq = htonl(task->tk_rqstp->rq_seqno);
- iov.iov_base = &seq;
- iov.iov_len = sizeof(seq);
+ seq = kmalloc(4, GFP_KERNEL);
+ if (!seq)
+ goto out_bad;
+ *seq = htonl(task->tk_rqstp->rq_seqno);
+ iov.iov_base = seq;
+ iov.iov_len = 4;
xdr_buf_from_iov(&iov, &verf_buf);
mic.data = (u8 *)p;
mic.len = len;
@@ -1653,11 +1656,13 @@ gss_validate(struct rpc_task *task, __be32 *p)
gss_put_ctx(ctx);
dprintk("RPC: %5u %s: gss_verify_mic succeeded.\n",
task->tk_pid, __func__);
+ kfree(seq);
return p + XDR_QUADLEN(len);
out_bad:
gss_put_ctx(ctx);
dprintk("RPC: %5u %s failed ret %ld.\n", task->tk_pid, __func__,
PTR_ERR(ret));
+ kfree(seq);
return ret;
}
diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 244245bcbbd2..8a280a810439 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -166,8 +166,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
unsigned int usage, struct xdr_netobj *cksumout)
{
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
u8 rc4salt[4];
struct crypto_ahash *md5;
struct crypto_ahash *hmac_md5;
@@ -187,23 +187,22 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+ if (!checksumdata)
+ return GSS_S_FAILURE;
+
md5 = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(md5))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
hmac_md5 = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0,
CRYPTO_ALG_ASYNC);
- if (IS_ERR(hmac_md5)) {
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (IS_ERR(hmac_md5))
+ goto out_free_md5;
req = ahash_request_alloc(md5, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(hmac_md5);
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_hmac_md5;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -232,11 +231,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
ahash_request_free(req);
req = ahash_request_alloc(hmac_md5, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(hmac_md5);
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_hmac_md5;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -258,8 +254,12 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
cksumout->len = kctx->gk5e->cksumlength;
out:
ahash_request_free(req);
- crypto_free_ahash(md5);
+out_free_hmac_md5:
crypto_free_ahash(hmac_md5);
+out_free_md5:
+ crypto_free_ahash(md5);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -276,8 +276,8 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
struct crypto_ahash *tfm;
struct ahash_request *req;
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
unsigned int checksumlen;
if (kctx->gk5e->ctype == CKSUMTYPE_HMAC_MD5_ARCFOUR)
@@ -291,15 +291,17 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+ if (checksumdata == NULL)
+ return GSS_S_FAILURE;
+
tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
req = ahash_request_alloc(tfm, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(tfm);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_ahash;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -349,7 +351,10 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
cksumout->len = kctx->gk5e->cksumlength;
out:
ahash_request_free(req);
+out_free_ahash:
crypto_free_ahash(tfm);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -368,8 +373,8 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
struct crypto_ahash *tfm;
struct ahash_request *req;
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
unsigned int checksumlen;
if (kctx->gk5e->keyed_cksum == 0) {
@@ -383,16 +388,18 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+ if (!checksumdata)
+ return GSS_S_FAILURE;
+
tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
checksumlen = crypto_ahash_digestsize(tfm);
req = ahash_request_alloc(tfm, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(tfm);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_ahash;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -433,7 +440,10 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
}
out:
ahash_request_free(req);
+out_free_ahash:
crypto_free_ahash(tfm);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -666,14 +676,17 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
u32 ret;
struct scatterlist sg[1];
SKCIPHER_REQUEST_ON_STACK(req, cipher);
- u8 data[GSS_KRB5_MAX_BLOCKSIZE * 2];
+ u8 *data;
struct page **save_pages;
u32 len = buf->len - offset;
- if (len > ARRAY_SIZE(data)) {
+ if (len > GSS_KRB5_MAX_BLOCKSIZE * 2) {
WARN_ON(0);
return -ENOMEM;
}
+ data = kmalloc(GSS_KRB5_MAX_BLOCKSIZE * 2, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
/*
* For encryption, we want to read from the cleartext
@@ -708,6 +721,7 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
ret = write_bytes_to_xdr_buf(buf, offset, data, len);
out:
+ kfree(data);
return ret;
}
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
index d67f7e1bc82d..45662d7f0943 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -718,30 +718,37 @@ gss_write_null_verf(struct svc_rqst *rqstp)
static int
gss_write_verf(struct svc_rqst *rqstp, struct gss_ctx *ctx_id, u32 seq)
{
- __be32 xdr_seq;
+ __be32 *xdr_seq;
u32 maj_stat;
struct xdr_buf verf_data;
struct xdr_netobj mic;
__be32 *p;
struct kvec iov;
+ int err = -1;
svc_putnl(rqstp->rq_res.head, RPC_AUTH_GSS);
- xdr_seq = htonl(seq);
+ xdr_seq = kmalloc(4, GFP_KERNEL);
+ if (!xdr_seq)
+ return -1;
+ *xdr_seq = htonl(seq);
- iov.iov_base = &xdr_seq;
- iov.iov_len = sizeof(xdr_seq);
+ iov.iov_base = xdr_seq;
+ iov.iov_len = 4;
xdr_buf_from_iov(&iov, &verf_data);
p = rqstp->rq_res.head->iov_base + rqstp->rq_res.head->iov_len;
mic.data = (u8 *)(p + 1);
maj_stat = gss_get_mic(ctx_id, &verf_data, &mic);
if (maj_stat != GSS_S_COMPLETE)
- return -1;
+ goto out;
*p++ = htonl(mic.len);
memset((u8 *)p + mic.len, 0, round_up_to_quad(mic.len) - mic.len);
p += XDR_QUADLEN(mic.len);
if (!xdr_ressize_check(rqstp, p))
- return -1;
- return 0;
+ goto out;
+ err = 0;
+out:
+ kfree(xdr_seq);
+ return err;
}
struct gss_domain {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Trond Myklebust @ 2016-10-25 19:34 UTC (permalink / raw)
To: Fields Bruce James
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161025184538.GA4612-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
>
> From: "J. Bruce Fields" <bfields@redhat.com>
>
> As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
> among other callers, passes it memory on the stack.
>
> We only need a scatterlist to pass this to the crypto code, and it seems
> like overkill to require kmalloc'd memory just to encrypt a few bytes,
> but for now this seems the best fix.
>
> Note many of these callers are in the NFS write paths, so we shouldn't
> really be allocating GFP_KERNEL. But we already have other allocations
> in these code paths. A larger redesign may be necessary to allow
> allocations to be done earlier.
NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
^ permalink raw reply
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Fields Bruce James @ 2016-10-25 19:59 UTC (permalink / raw)
To: Trond Myklebust
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto@vger.kernel.org
In-Reply-To: <A4086E5B-B808-4828-A25D-4AAB2504EC57@primarydata.com>
On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
>
> > On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > From: "J. Bruce Fields" <bfields@redhat.com>
> >
> > As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> > mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
> > among other callers, passes it memory on the stack.
> >
> > We only need a scatterlist to pass this to the crypto code, and it seems
> > like overkill to require kmalloc'd memory just to encrypt a few bytes,
> > but for now this seems the best fix.
> >
> > Note many of these callers are in the NFS write paths, so we shouldn't
> > really be allocating GFP_KERNEL. But we already have other allocations
> > in these code paths. A larger redesign may be necessary to allow
> > allocations to be done earlier.
>
> NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
OK. Any disadvantage to keeping this patch with just GFP_NOFS
allocations everywhere that might be in the write path?
--b.
^ permalink raw reply
* [PATCH] crypto: caam: fix type mismatch warning
From: Arnd Bergmann @ 2016-10-25 21:29 UTC (permalink / raw)
To: Herbert Xu
Cc: Arnd Bergmann, David S. Miller, Horia Geantă, Catalin Vasile,
linux-crypto, linux-kernel
Building the caam driver on arm64 produces a harmless warning:
drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct pointer types lacks a cast
We can use min_t to tell the compiler which type we want it to use
here.
Fixes: 5ecf8ef9103c ("crypto: caam - fix sg dump")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This is currently the only warning reported by kernelci.org for
linux-4.9 on arm, arm64 and x86.
---
drivers/crypto/caam/caamalg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 156aad167cd6..8de85dfb1b04 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -137,7 +137,7 @@ static void dbg_dump_sg(const char *level, const char *prefix_str,
}
buf = it_page + it->offset;
- len = min(tlen, it->length);
+ len = min_t(size_t, tlen, it->length);
print_hex_dump(level, prefix_str, prefix_type, rowsize,
groupsize, buf, len, ascii);
tlen -= len;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Trond Myklebust @ 2016-10-25 21:47 UTC (permalink / raw)
To: Fields Bruce James
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161025195930.GB5129-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> On Oct 25, 2016, at 15:59, Fields Bruce James <bfields@fieldses.org> wrote:
>
> On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
>>
>>> On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
>>>
>>> From: "J. Bruce Fields" <bfields@redhat.com>
>>>
>>> As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
>>> mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
>>> among other callers, passes it memory on the stack.
>>>
>>> We only need a scatterlist to pass this to the crypto code, and it seems
>>> like overkill to require kmalloc'd memory just to encrypt a few bytes,
>>> but for now this seems the best fix.
>>>
>>> Note many of these callers are in the NFS write paths, so we shouldn't
>>> really be allocating GFP_KERNEL. But we already have other allocations
>>> in these code paths. A larger redesign may be necessary to allow
>>> allocations to be done earlier.
>>
>> NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
>
> OK. Any disadvantage to keeping this patch with just GFP_NOFS
> allocations everywhere that might be in the write path?
It’s what we have to do everywhere else in the RPC client, so I can’t see why it should be a problem.
^ permalink raw reply
* [cryptodev:master 41/47] ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
From: kbuild test robot @ 2016-10-26 0:47 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: kbuild-all, linux-crypto, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: d7db7a882debaffc78f91aabedee973aa1f73390
commit: 1ab53a77b772bf7369464a0e4fa6fd6499acf8f1 [41/47] crypto: acomp - add driver-side scomp interface
config: x86_64-randconfig-s4-10260656 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 1ab53a77b772bf7369464a0e4fa6fd6499acf8f1
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
>> ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined!
>> ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 19304 bytes --]
^ permalink raw reply
* Re: [PATCH] crypto: caam: fix type mismatch warning
From: Horia Geanta Neag @ 2016-10-26 6:23 UTC (permalink / raw)
To: Arnd Bergmann, Herbert Xu
Cc: David S. Miller, Cata Vasile, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161025212923.2452320-1-arnd@arndb.de>
On 10/26/2016 12:29 AM, Arnd Bergmann wrote:
> Building the caam driver on arm64 produces a harmless warning:
>
> drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct pointer types lacks a cast
>
> We can use min_t to tell the compiler which type we want it to use
> here.
>
> Fixes: 5ecf8ef9103c ("crypto: caam - fix sg dump")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
Thanks,
Horia
^ permalink raw reply
* Re: ARM-CE aes encryption on uneven blocks
From: Hamid Nassiby @ 2016-10-26 7:16 UTC (permalink / raw)
To: Cata Vasile; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <HE1PR04MB13065DBD6C9844835123FAF9EEA90@HE1PR04MB1306.eurprd04.prod.outlook.com>
Hi,
Based on my old experience with "struct crypto_alg" based drivers, the
data you receive there, is padded beforehand(in the upper layers);
Therefore the plaintext contains integral multiple of AES block size
of data and based on the number of blocks, the crypto transform can be
computed.
Regards,
Hamid
On Mon, Oct 24, 2016 at 6:11 PM, Cata Vasile <cata.vasile@nxp.com> wrote:
>
> Hi,
>
> I'm trying to understand the code for AES encryption from ARM-CE.
> From the aes-glue.S calls I understand that the encryption primitives receive the number of blocks, but have no way of determining the number of bytes to encrypt, if for example the plaintext does not have a length of a multiple of AES block size.
> How does, for example, ecb_encrypt() also encrypt the last remaining bytes in the plaintext if it is not a multiple of AES block size if It can never deduce the full plaintext size?
>
> Catalin Vasile--
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [cryptodev:master 41/47] ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
From: Giovanni Cabiddu @ 2016-10-26 9:56 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, linux-crypto, Herbert Xu
In-Reply-To: <201610260803.GIBxWXo3%fengguang.wu@intel.com>
Hi,
On Wed, Oct 26, 2016 at 08:47:16AM +0800, kbuild test robot wrote:
> >> ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
> >> ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined!
> >> ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined!
Thanks for the report. There is a problem with a dependency between
acomp and scomp. This patch should fix the issue.
Giovanni
---8<---
Subject: [PATCH] crypto: acomp - fix dependency in Makefile
Fix dependency between acomp and scomp that appears when acomp is
built as module
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
---
crypto/Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/Makefile b/crypto/Makefile
index 5c83f3d..82ffeee 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -50,8 +50,9 @@ rsa_generic-y += rsa_helper.o
rsa_generic-y += rsa-pkcs1pad.o
obj-$(CONFIG_CRYPTO_RSA) += rsa_generic.o
-obj-$(CONFIG_CRYPTO_ACOMP2) += acompress.o
-obj-$(CONFIG_CRYPTO_ACOMP2) += scompress.o
+crypto_acompress-y := acompress.o
+crypto_acompress-y += scompress.o
+obj-$(CONFIG_CRYPTO_ACOMP2) += crypto_acompress.o
cryptomgr-y := algboss.o testmgr.o
--
^ permalink raw reply related
* Re: [PATCH 2/6] chcr: Remove malloc/free
From: Harsh Jain @ 2016-10-26 11:29 UTC (permalink / raw)
To: Herbert Xu
Cc: dan.carpenter, linux-crypto, jlulla, atul.gupta, yeshaswi,
hariprasad
In-Reply-To: <20161021022038.GB22485@gondor.apana.org.au>
On 21-10-2016 07:50, Herbert Xu wrote:
> On Thu, Oct 13, 2016 at 04:39:35PM +0530, Harsh Jain wrote:
>> Remove malloc/free in crypto operation and allocate memory via cra_ctxsize.
>> Added new structure chcr_wr to populate Work Request Header.
>> Fixes: 324429d74127 (chcr: Support for Chelsio's Crypto Hardware)
> Do you mean the reqsize as opposed to ctxsize since the latter is
> shared by all tfm users?
It's reqsize for hash algos (chcr_ahash_req_ctx struct ) and ctxsize for Cipher algos(ablk_ctx struct),As rrkey(reverse round key) is also same for all tfm.
>
> In any case, your patch doesn't seem to change the size setting?
Added new variables in old structure. Size setting related code is unchanged.
In v2 will break the patch to smaller one.
>
> Cheers,
^ permalink raw reply
* Re: ARM-CE aes encryption on uneven blocks
From: Cata Vasile @ 2016-10-26 7:49 UTC (permalink / raw)
To: Hamid Nassiby; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <CAFuf8QPCZPaLXh0nNY3Ktm-w6STKGwXpTEQcXGH-HCDvWD-jLQ@mail.gmail.com>
Then what is the role of the "for" structure? Why not do just a single encryption/decryption call?
Regards,
Cata
>From: Hamid Nassiby <h.nassiby@gmail.com>
>Sent: Wednesday, October 26, 2016 10:16 AM
>To: Cata Vasile
>Cc: linux-crypto@vger.kernel.org
>Subject: Re: ARM-CE aes encryption on uneven blocks
>
>Hi,>
>Based on my old experience with "struct crypto_alg" based drivers, the
>data you receive there, is padded beforehand(in the upper layers);
>Therefore the plaintext contains integral multiple of AES block size
>of data and based on the number of blocks, the crypto transform can be
>computed.>
>Regards,
>Hamid>
>On Mon, Oct 24, 2016 at 6:11 PM, Cata Vasile <cata.vasile@nxp.com> wrote:
>>
>> Hi,
>>
>> I'm trying to understand the code for AES encryption from ARM-CE.
>> From the aes-glue.S calls I understand that the encryption primitives receive the number of blocks, but have no way of determining the number of bytes to encrypt, if for example the plaintext does not have a length of a multiple of AES block size.
>> How does, for example, ecb_encrypt() also encrypt the last remaining bytes in the plaintext if it is not a multiple of AES block size if It can never deduce the full plaintext size?
>>
>> Catalin Vasile--
>> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.kernel.org%2Fmajordomo-info.html&data=01%7C01%7Ccata.vasile%40nxp.com%7C4c5ecc69183f40e96faf08d3fd701bab%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&sdata=vVYloLYwzQl3keXvz%2FMdV3d2ruHmn26F%2FfY%2FA7GG8wA%3D&reserved=0
>
^ 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