* Re: [PATCH 1/3] crypto: dcp - Use devm_ioremap_resource()
From: Herbert Xu @ 2013-09-23 20:09 UTC (permalink / raw)
To: Fabio Estevam; +Cc: tobias.rauter, linux-crypto, Fabio Estevam
In-Reply-To: <1379871747-17570-1-git-send-email-festevam@gmail.com>
On Sun, Sep 22, 2013 at 02:42:25PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
>
> Using devm_ioremap_resource() can make the code simpler and smaller.
>
> When devm_ioremap_resource() is used there is no need to explicitely check the
> error returned by platform_get_resource().
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
All 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 v3 0/2] crypto: move ablk_helper out of arch/x86
From: Herbert Xu @ 2013-09-23 20:09 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, jussi.kivilinna, arnd
In-Reply-To: <1379663741-21085-1-git-send-email-ard.biesheuvel@linaro.org>
On Fri, Sep 20, 2013 at 09:55:39AM +0200, Ard Biesheuvel wrote:
> v3:
> - added generic and x86 versions of <asm/simd.h> containing may_use_simd(), and
> use it to decide whether to take the sync or the async path
>
> v2:
> - whitespace fix
> - split into two patches so that the first one applies cleanly to the ARM/ARM64
> trees as well
> - rebased onto cryptodev/master
>
> Ard Biesheuvel (2):
> crypto: create generic version of ablk_helper
> crypto: move x86 to the generic version of ablk_helper
All 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] ansi_cprng: Fix off by one error in non-block size request
From: Herbert Xu @ 2013-09-23 20:09 UTC (permalink / raw)
To: Neil Horman; +Cc: linux-crypto, Stephan Mueller, Petr Matousek, David S. Miller
In-Reply-To: <1379421191-13740-1-git-send-email-nhorman@tuxdriver.com>
On Tue, Sep 17, 2013 at 08:33:11AM -0400, Neil Horman wrote:
> Stephan Mueller reported to me recently a error in random number generation in
> the ansi cprng. If several small requests are made that are less than the
> instances block size, the remainder for loop code doesn't increment
> rand_data_valid in the last iteration, meaning that the last bytes in the
> rand_data buffer gets reused on the subsequent smaller-than-a-block request for
> random data.
>
> The fix is pretty easy, just re-code the for loop to make sure that
> rand_data_valid gets incremented appropriately
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
> CC: Stephan Mueller <stephan.mueller@atsec.com>
> CC: Petr Matousek <pmatouse@redhat.com>
> CC: Herbert Xu <herbert@gondor.apana.org.au>
> CC: "David S. Miller" <davem@davemloft.net>
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] ARM: tegra: remove tegra_chip_uid()
From: Herbert Xu @ 2013-09-23 20:09 UTC (permalink / raw)
To: Stephen Warren
Cc: David S. Miller, linux-crypto, linux-tegra, linux-arm-kernel,
Linus Walleij, Stephen Warren
In-Reply-To: <1379345659-9528-1-git-send-email-swarren@wwwdotorg.org>
On Mon, Sep 16, 2013 at 09:34:19AM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Following commit f5b38c5 "crypto: tegra - use kernel entropy instead
> of ad-hoc", this function is no longer used. It's also only accurate
> for Tegra20 and not later SoCs. So, remove it.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.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 1/2] crypto: tegra-aes - Fix NULL pointer dereference
From: Herbert Xu @ 2013-09-23 20:09 UTC (permalink / raw)
To: Sachin Kamat
Cc: linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
swarren-3lzwWm7+Weoh9ZMKESR00Q
In-Reply-To: <1379302271-22438-1-git-send-email-sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Sep 16, 2013 at 09:01:10AM +0530, Sachin Kamat wrote:
> 'dd' is tested for NULL. However, it is derefenced in the error
> message print. Change the print to pr_err to avoid this.
>
> Signed-off-by: Sachin Kamat <sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Both patches applied.
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/3] crypto: mv_cesa - Staticize local symbols
From: Herbert Xu @ 2013-09-23 20:08 UTC (permalink / raw)
To: Sachin Kamat; +Cc: linux-crypto, Sebastian Andrzej Siewior
In-Reply-To: <1379072207-11179-1-git-send-email-sachin.kamat@linaro.org>
On Fri, Sep 13, 2013 at 05:06:45PM +0530, Sachin Kamat wrote:
> Local symbols used only in this file are made static.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
All 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] crypto: caam - map src buffer before access
From: Herbert Xu @ 2013-09-23 20:08 UTC (permalink / raw)
To: Yashpal Dutta; +Cc: linux-crypto
In-Reply-To: <1378927446-21209-1-git-send-email-yashpal.dutta@freescale.com>
On Wed, Sep 11, 2013 at 07:24:06PM +0000, Yashpal Dutta wrote:
> KMap the buffers before copying trailing bytes during hmac into a session
> temporary buffer. This is required if pinned buffer from user-space is send
> during hmac and is safe even if hmac request is generated from within kernel.
>
> Signed-off-by: Yashpal Dutta <yashpal.dutta@freescale.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 v4] crypto: caam - map src buffer before access
From: Kim Phillips @ 2013-09-23 18:51 UTC (permalink / raw)
To: yashpal.dutta; +Cc: linux-crypto, stable
In-Reply-To: <1379753795-14949-1-git-send-email-yashpal.dutta@freescale.com>
On Sat, 21 Sep 2013 14:26:35 +0530
Yashpal Dutta <yashpal.dutta@freescale.com> wrote:
> KMap the buffers before copying trailing bytes during hmac into a session
> temporary buffer. This is required if pinned buffer from user-space is send
> during hmac and is safe even if hmac request is generated from within kernel.
it may be "safe" but it adversely affects performance for AF_ALG users,
no?
why does ocf-linux need this, and not AF_ALG? Is a patch to ocf-linux
more appropriate here?
> Cc:stable@vger.kernel.org
fyi, this violates the following rule in
Documentation/stable_kernel_rules.txt:
- It or an equivalent fix must already exist in Linus' tree (upstream).
Kim
^ permalink raw reply
* Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
From: Russell King - ARM Linux @ 2013-09-23 18:42 UTC (permalink / raw)
To: Alan Stern
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Alexander Shishkin,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Kukjin Kim,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Solarflare linux maintainers, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman
In-Reply-To: <Pine.LNX.4.44L0.1309231418030.1348-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code should access this
> > member directly.
> >
> > Convert all direct write accesses to using the correct API.
> >
> > Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
>
> > diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> > index f6b790c..5b0cd2d 100644
> > --- a/drivers/usb/host/ehci-platform.c
> > +++ b/drivers/usb/host/ehci-platform.c
>
> > @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device *dev)
> > dev->dev.platform_data = &ehci_platform_defaults;
> > if (!dev->dev.dma_mask)
> > dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> > - if (!dev->dev.coherent_dma_mask)
> > - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > + err = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
> > + if (err)
> > + return err;
> >
> > pdata = dev_get_platdata(&dev->dev);
>
> ehci-platform.c is a generic file, intended for use by multiple
> platforms. Is it not possible that on some platforms, the arch or bus
> code may already have initialized the DMA masks? Isn't something like
> this (i.e., DMA bindings) planned for Device Tree?
>
> By eliminating the tests above and calling dma_set_coherent_mask or
> dma_coerce_mask_and_coherent unconditionally, this patch (and the next)
> would overwrite those initial settings.
>
> I don't know to what extent the same may be true for the other,
> platform-specific, drivers changed by this patch. But it's something
> to be aware of.
Please check the DMA API documentation:
=====
For correct operation, you must interrogate the kernel in your device
probe routine to see if the DMA controller on the machine can properly
support the DMA addressing limitation your device has. It is good
style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
The query is performed via a call to dma_set_mask():
int dma_set_mask(struct device *dev, u64 mask);
The query for consistent allocations is performed via a call to
dma_set_coherent_mask():
int dma_set_coherent_mask(struct device *dev, u64 mask);
=====
So, All drivers which use DMA are supposed to issue the appropriate
calls to check the DMA masks before they perform DMA, even if the
"default" is correct.
And yes, this is all part of sorting out the DT mess - we should
start not from the current mess (which is really totally haphazard)
but from the well established position of how the DMA API _should_
be used. What that means is that all drivers should be issuing
these calls as appropriate today.
The default mask setup when the device is created is just that -
it's a default mask, and it should not be used to decide anything
about the device. That's something which the driver should compute
on its own accord and then inform the various other layers via the
appropriate call.
Remember, on PCI, even when we have 64-bit, we do not declare PCI
devices with a 64-bit DMA mask: that's up to PCI device drivers to
_try_ to set a 64-bit DMA mask, which when successful _allows_ them
to use 64-bit DMA. If it fails, they have to only use 32-bit. If
they want a smaller mask, the _driver_ has to set the smaller mask,
not the device creating code.
The reason we're into this (particularly on ARM) is that we got lazy
because we could get by with declaring a DMA mask at device creation
time, since all devices were statically declared. Now it's time to
get rid of those old lazy ways and start doing things correctly and
to the requirements of the APIs.
^ permalink raw reply
* Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
From: Alan Stern @ 2013-09-23 18:27 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, Alexander Shishkin, linux-mmc, linux-fbdev,
linux-nvme, linux-ide, devel, linux-samsung-soc, linux-scsi,
e1000-devel, b43-dev, linux-media, devicetree, Stephen Warren,
Kukjin Kim, dri-devel, linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
Felipe Balbi, linux-crypto, Greg Kroah-Hartman
In-Reply-To: <E1VMmHX-0007jq-Cj@rmk-PC.arm.linux.org.uk>
On Thu, 19 Sep 2013, Russell King wrote:
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
> index f6b790c..5b0cd2d 100644
> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -91,8 +91,9 @@ static int ehci_platform_probe(struct platform_device *dev)
> dev->dev.platform_data = &ehci_platform_defaults;
> if (!dev->dev.dma_mask)
> dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> - if (!dev->dev.coherent_dma_mask)
> - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + err = dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
> + if (err)
> + return err;
>
> pdata = dev_get_platdata(&dev->dev);
ehci-platform.c is a generic file, intended for use by multiple
platforms. Is it not possible that on some platforms, the arch or bus
code may already have initialized the DMA masks? Isn't something like
this (i.e., DMA bindings) planned for Device Tree?
By eliminating the tests above and calling dma_set_coherent_mask or
dma_coerce_mask_and_coherent unconditionally, this patch (and the next)
would overwrite those initial settings.
I don't know to what extent the same may be true for the other,
platform-specific, drivers changed by this patch. But it's something
to be aware of.
Alan Stern
^ permalink raw reply
* Re: [PATCH V4 02/15] asymmetric keys: implement EMSA_PKCS1-v1_5-ENCODE in rsa
From: Phil Carmody @ 2013-09-23 16:49 UTC (permalink / raw)
To: Lee, Chun-Yi
Cc: linux-kernel, linux-security-module, linux-efi, linux-pm,
linux-crypto, opensuse-kernel, David Howells, Rafael J. Wysocki,
Matthew Garrett
In-Reply-To: <1379206621-18639-3-git-send-email-jlee@suse.com>
On Sun, Sep 15, 2013 at 08:56:48AM +0800, Lee, Chun-Yi wrote:
> Implement EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2] in rsa.c. It's the
> first step of signature generation operation (RSASSA-PKCS1-v1_5-SIGN).
>
> This patch is temporary set emLen to pks->k, and temporary set EM to
> pks->S for debugging. We will replace the above values to real signature
> after implement RSASP1.
>
> The naming of EMSA_PKCS1_v1_5_ENCODE and the variables used in this function
> accord PKCS#1 spec but not follow kernel naming convention, it useful when look
> at them with spec.
>
> Reference: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1v2/pkcs1ietffinal.txt
> Reference: http://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf
>
> V2:
You're now at V4.
> - Clean up naming of variable: replace _EM by EM, replace EM by EM_tmp.
> - Add comment to EMSA_PKCS1-v1_5-ENCODE function.
>
> Cc: Pavel Machek <pavel@ucw.cz>
> Reviewed-by: Jiri Kosina <jkosina@suse.cz>
> Signed-off-by: Lee, Chun-Yi <jlee@suse.com>
> ---
> crypto/asymmetric_keys/rsa.c | 163 +++++++++++++++++++++++++++++++++++++++++-
> include/crypto/public_key.h | 2 +
> 2 files changed, 164 insertions(+), 1 deletions(-)
>
> diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
> index 47f3be4..352ba45 100644
> --- a/crypto/asymmetric_keys/rsa.c
> +++ b/crypto/asymmetric_keys/rsa.c
> @@ -13,6 +13,7 @@
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/slab.h>
> +#include <crypto/hash.h>
> #include "public_key.h"
> #include "private_key.h"
>
> @@ -152,6 +153,132 @@ static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
> }
>
> /*
> + * EMSA_PKCS1-v1_5-ENCODE [RFC3447 sec 9.2]
> + * @M: message to be signed, an octet string
> + * @emLen: intended length in octets of the encoded message
> + * @hash_algo: hash function (option)
> + * @hash: true means hash M, otherwise M is already a digest
> + * @EM: encoded message, an octet string of length emLen
> + *
> + * This function is a implementation of the EMSA-PKCS1-v1_5 encoding operation
> + * in RSA PKCS#1 spec. It used by the signautre generation operation of
> + * RSASSA-PKCS1-v1_5 to encode message M to encoded message EM.
> + *
> + * The variables used in this function accord PKCS#1 spec but not follow kernel
> + * naming convention, it useful when look at them with spec.
> + */
> +static int EMSA_PKCS1_v1_5_ENCODE(const u8 *M, size_t emLen,
> + enum pkey_hash_algo hash_algo, const bool hash,
> + u8 **EM, struct public_key_signature *pks)
> +{
> + u8 *digest;
> + struct crypto_shash *tfm;
> + struct shash_desc *desc;
> + size_t digest_size, desc_size;
> + size_t tLen;
> + u8 *T, *PS, *EM_tmp;
> + int i, ret;
> +
> + pr_info("EMSA_PKCS1_v1_5_ENCODE start\n");
> +
> + if (!RSA_ASN1_templates[hash_algo].data)
> + ret = -ENOTSUPP;
...
> + else
> + pks->pkey_hash_algo = hash_algo;
> +
> + /* 1) Apply the hash function to the message M to produce a hash value H */
> + tfm = crypto_alloc_shash(pkey_hash_algo[hash_algo], 0, 0);
> + if (IS_ERR(tfm))
> + return (PTR_ERR(tfm) == -ENOENT) ? -ENOPKG : PTR_ERR(tfm);
> +
> + desc_size = crypto_shash_descsize(tfm) + sizeof(*desc);
> + digest_size = crypto_shash_digestsize(tfm);
> +
> + ret = -ENOMEM;
The earlier "ret = -ENOTSUPP;" is either unused because you return at the IS_ERR,
or unused because you overwrite it here. I'm a little disappointed that
the compiler didn't recognise that something was assigned to a value that
is never used.
Phil
> +
> + digest = kzalloc(digest_size + desc_size, GFP_KERNEL);
> + if (!digest)
> + goto error_digest;
> + pks->digest = digest;
> + pks->digest_size = digest_size;
> +
> + if (hash) {
> + desc = (void *) digest + digest_size;
> + desc->tfm = tfm;
> + desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
> +
> + ret = crypto_shash_init(desc);
> + if (ret < 0)
> + goto error_shash;
> + ret = crypto_shash_finup(desc, M, sizeof(M), pks->digest);
> + if (ret < 0)
> + goto error_shash;
> + } else {
> + memcpy(pks->digest, M, pks->digest_size);
> + pks->digest_size = digest_size;
> + }
> + crypto_free_shash(tfm);
> +
> + /* 2) Encode the algorithm ID for the hash function and the hash value into
> + * an ASN.1 value of type DigestInfo with the DER. Let T be the DER encoding of
> + * the DigestInfo value and let tLen be the length in octets of T.
> + */
> + tLen = RSA_ASN1_templates[hash_algo].size + pks->digest_size;
> + T = kmalloc(tLen, GFP_KERNEL);
> + if (!T)
> + goto error_T;
> +
> + memcpy(T, RSA_ASN1_templates[hash_algo].data, RSA_ASN1_templates[hash_algo].size);
> + memcpy(T + RSA_ASN1_templates[hash_algo].size, pks->digest, pks->digest_size);
> +
> + /* 3) check If emLen < tLen + 11, output "intended encoded message length too short" */
> + if (emLen < tLen + 11) {
> + ret = -EINVAL;
> + goto error_emLen;
> + }
> +
> + /* 4) Generate an octet string PS consisting of emLen - tLen - 3 octets with 0xff. */
> + PS = kmalloc(emLen - tLen - 3, GFP_KERNEL);
> + if (!PS)
> + goto error_P;
> +
> + for (i = 0; i < (emLen - tLen - 3); i++)
> + PS[i] = 0xff;
> +
> + /* 5) Concatenate PS, the DER encoding T, and other padding to form the encoded
> + * message EM as EM = 0x00 || 0x01 || PS || 0x00 || T
> + */
> + EM_tmp = kmalloc(3 + emLen - tLen - 3 + tLen, GFP_KERNEL);
> + if (!EM_tmp)
> + goto error_EM;
> +
> + EM_tmp[0] = 0x00;
> + EM_tmp[1] = 0x01;
> + memcpy(EM_tmp + 2, PS, emLen - tLen - 3);
> + EM_tmp[2 + emLen - tLen - 3] = 0x00;
> + memcpy(EM_tmp + 2 + emLen - tLen - 3 + 1, T, tLen);
> +
> + *EM = EM_tmp;
> +
> + kfree(PS);
> + kfree(T);
> +
> + return 0;
> +
> +error_EM:
> + kfree(PS);
> +error_P:
> +error_emLen:
> + kfree(T);
> +error_T:
> +error_shash:
> + kfree(digest);
> +error_digest:
> + crypto_free_shash(tfm);
> + return ret;
> +}
> +
> +/*
> * Perform the RSA signature verification.
> * @H: Value of hash of data and metadata
> * @EM: The computed signature value
> @@ -275,9 +402,43 @@ static struct public_key_signature *RSA_generate_signature(
> const struct private_key *key, u8 *M,
> enum pkey_hash_algo hash_algo, const bool hash)
> {
> + struct public_key_signature *pks;
> + u8 *EM = NULL;
> + size_t emLen;
> + int ret;
> +
> pr_info("RSA_generate_signature start\n");
>
> - return 0;
> + ret = -ENOMEM;
> + pks = kzalloc(sizeof(*pks), GFP_KERNEL);
> + if (!pks)
> + goto error_no_pks;
> +
> + /* 1): EMSA-PKCS1-v1_5 encoding: */
> + /* Use the private key modulus size to be EM length */
> + emLen = mpi_get_nbits(key->rsa.n);
> + emLen = (emLen + 7) / 8;
> +
> + ret = EMSA_PKCS1_v1_5_ENCODE(M, emLen, hash_algo, hash, &EM, pks);
> + if (ret < 0)
> + goto error_v1_5_encode;
> +
> + /* TODO 2): m = OS2IP (EM) */
> +
> + /* TODO 3): s = RSASP1 (K, m) */
> +
> + /* TODO 4): S = I2OSP (s, k) */
> +
> + /* TODO: signature S to a u8* S or set to sig->rsa.s? */
> + pks->S = EM; /* TODO: temporary set S to EM */
> +
> + return pks;
> +
> +error_v1_5_encode:
> + kfree(pks);
> +error_no_pks:
> + pr_info("<==%s() = %d\n", __func__, ret);
> + return ERR_PTR(ret);
> }
>
> const struct public_key_algorithm RSA_public_key_algorithm = {
> diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
> index d44b29f..1cdf457 100644
> --- a/include/crypto/public_key.h
> +++ b/include/crypto/public_key.h
> @@ -110,6 +110,8 @@ extern void public_key_destroy(void *payload);
> struct public_key_signature {
> u8 *digest;
> u8 digest_size; /* Number of bytes in digest */
> + u8 *S; /* signature S of length k octets */
> + size_t k; /* length k of signature S */
> u8 nr_mpi; /* Occupancy of mpi[] */
> enum pkey_hash_algo pkey_hash_algo : 8;
> union {
> --
> 1.6.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: Asymmetric cryptography HW offloading
From: Nikos Mavrogiannopoulos @ 2013-09-23 13:28 UTC (permalink / raw)
To: Horia Geantă; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <524034A1.70204@freescale.com>
On 09/23/2013 02:31 PM, Horia Geantă wrote:
> Hi,
>
> CAAM crypto engine (drivers/crypto/caam/*) is capable of asymmetric
> operations, like: modular exponentiation, RSA
> sign/verify/encrypt/decrypt, (EC)DSA sign etc.
> I would appreciate some design guidelines on how to harness these
> capabilities, for crypto engines in general.
>
> 1. In-kernel interface for asymmetric crypto
> Should crypto/asymmetric_keys/* be used, i.e. appended with modular
> exponentiation, other asymmetric operations?
The BSD's cryptodev supports the following operations which may help in
that aspect (no elliptic curve operations present). I don't know if all
of them worth the context switch.
#define CRK_MOD_EXP 0
#define CRK_MOD_EXP_CRT 1
#define CRK_DSA_SIGN 2
#define CRK_DSA_VERIFY 3
#define CRK_DH_COMPUTE_KEY 4
#define CRK_MOD_ADD 5
#define CRK_MOD_ADDINV 6
#define CRK_MOD_SUB 7
#define CRK_MOD_MULT 8
#define CRK_MOD_MULTINV 9
#define CRK_MOD 10
> 2. User space interface
> Should AF_ALG be expanded to provide access to this new asymmetric cypto
> API? The API would allow user space applications to offload PKC operations in
> HW.
I'd be interested into adding this support into cryptodev-linux once
present in kernel.
regards,
Nikos
^ permalink raw reply
* Re: [PATCH 37/51] DMA-API: usb: use new dma_coerce_mask_and_coherent()
From: Nicolas Ferre @ 2013-09-23 12:34 UTC (permalink / raw)
To: Russell King, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
Cc: Alexander Shishkin, Greg Kroah-Hartman, Felipe Balbi, Kukjin Kim,
Alan Stern, Tony Prisk, Stephen Warren
In-Reply-To: <E1VMmIV-0007jw-Gq-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
On 20/09/2013 00:02, Russell King :
> Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 4 +---
> drivers/usb/dwc3/dwc3-exynos.c | 4 +---
> drivers/usb/host/ehci-atmel.c | 4 +---
For Atmel driver:
Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
[..]
> diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
> index 5831a88..8e7323e 100644
> --- a/drivers/usb/host/ehci-atmel.c
> +++ b/drivers/usb/host/ehci-atmel.c
> @@ -90,9 +90,7 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
> * Since shared usb code relies on it, set it here for now.
> * Once we have dma capability bindings this can go away.
> */
> - if (!pdev->dev.dma_mask)
> - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> - retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + retval = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> if (retval)
> goto fail_create_hcd;
>
[..]
Thanks Russell,
--
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* Asymmetric cryptography HW offloading
From: Horia Geantă @ 2013-09-23 12:31 UTC (permalink / raw)
To: Herbert Xu, David Howells, James Morris -
Cc: linux-crypto@vger.kernel.org, Kim Phillips
Hi,
CAAM crypto engine (drivers/crypto/caam/*) is capable of asymmetric
operations, like: modular exponentiation, RSA
sign/verify/encrypt/decrypt, (EC)DSA sign etc.
I would appreciate some design guidelines on how to harness these
capabilities, for crypto engines in general.
1. In-kernel interface for asymmetric crypto
Should crypto/asymmetric_keys/* be used, i.e. appended with modular
exponentiation, other asymmetric operations? I am asking since this
seems to be closer to key management than to asymmetric crypto...
If so, should an algorithm priority be defined, similar to Crypto API
interface for symmetric algos (so that for e.g. a HW implementation of
RSA verify would be preferred over a SW implementation)? Currently
interface does not allow for two or more implementers of the same
algo/operation.
Currently, SW implementation of modular exponentiation - mpi_powm() - is
used by crypto/asymmetric_keys/rsa.c and lib/digsig.c. AFAICT, its users
could benefit from a HW-accelerated version.
2. User space interface
Should AF_ALG be expanded to provide access to this new asymmetric cypto
API?
The API would allow user space applications to offload PKC operations in HW.
Possible use: offloading compute-intensive parts of TLS handshake, IKE.
Thanks,
Horia
^ permalink raw reply
* Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()
From: Nicolas Ferre @ 2013-09-23 12:30 UTC (permalink / raw)
To: Russell King, alsa-devel, b43-dev, devel, devicetree, dri-devel,
e1000-devel, linux-arm-kernel, linux-crypto, linux-doc,
linux-fbdev, linux-ide, linux-media, linux-mmc, linux-nvme,
linux-omap, linuxppc-dev, linux-samsung-soc, linux-scsi,
linux-tegra, linux-usb, linux-wireless, netdev,
Solarflare linux maintainers, uclinux-dist-devel
Cc: Kukjin Kim, Stephen Warren, Alexander Shishkin,
Greg Kroah-Hartman, Felipe Balbi, Alan Stern
In-Reply-To: <E1VMmHX-0007jq-Cj@rmk-PC.arm.linux.org.uk>
On 20/09/2013 00:01, Russell King :
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write accesses to using the correct API.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 5 +++--
> drivers/usb/dwc3/dwc3-exynos.c | 5 +++--
> drivers/usb/gadget/lpc32xx_udc.c | 4 +++-
> drivers/usb/host/ehci-atmel.c | 5 +++--
For Atmel driver:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
[..]
> diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
> index 3b645ff..5831a88 100644
> --- a/drivers/usb/host/ehci-atmel.c
> +++ b/drivers/usb/host/ehci-atmel.c
> @@ -92,8 +92,9 @@ static int ehci_atmel_drv_probe(struct platform_device *pdev)
> */
> if (!pdev->dev.dma_mask)
> pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> - if (!pdev->dev.coherent_dma_mask)
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + retval = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> + if (retval)
> + goto fail_create_hcd;
>
> hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
> if (!hcd) {
[..]
Thanks,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
From: Russell King - ARM Linux @ 2013-09-23 11:37 UTC (permalink / raw)
To: Vinod Koul
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130923102533.GI17188@intel.com>
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This avoids a direct reference to the DMA
> > masks by this driver.
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: Vinod Koul <vinod.koul@intel.com>
>
> This also brings me question that should we force the driver to use the
> dma_set_mask_and_coherent() API or they have below flexiblity too?
There's two issues here:
1. dma_set_mask_and_coherent() will only work if dev->dma_mask points at
some storage for the mask. This needs to have .dma_mask in the
platform_device_info initialised.
2. Yes, this driver should also be calling the appropriate DMA mask setting
functions in addition to having the mask initialized at device creation
time.
Here's a replacement patch, though maybe it would be better to roll all
the additions of dma_set_mask_and_coherent() in drivers/dma into one
patch? In other words, combine the addition of this with these two
patches:
dma: pl330: add dma_set_mask_and_coherent() call
dma: pl08x: add dma_set_mask_and_coherent() call
8<=====
From: Russell King <rmk+kernel@arm.linux.org.uk>
Subject: [PATCH] DMA-API: dma: edma.c: no need to explicitly initialize DMA
masks
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
While here, add the dma_set_mask_and_coherent() call which the DMA API
requires DMA-using drivers to call.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/dma/edma.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..fd5e48c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -631,6 +631,10 @@ static int edma_probe(struct platform_device *pdev)
struct edma_cc *ecc;
int ret;
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+
ecc = devm_kzalloc(&pdev->dev, sizeof(*ecc), GFP_KERNEL);
if (!ecc) {
dev_err(&pdev->dev, "Can't allocate controller\n");
@@ -702,11 +706,13 @@ static struct platform_device *pdev0, *pdev1;
static const struct platform_device_info edma_dev_info0 = {
.name = "edma-dma-engine",
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
};
static const struct platform_device_info edma_dev_info1 = {
.name = "edma-dma-engine",
.id = 1,
+ .dma_mask = DMA_BIT_MASK(32),
};
static int edma_init(void)
@@ -720,8 +726,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
- pdev0->dev.dma_mask = &pdev0->dev.coherent_dma_mask;
- pdev0->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
if (EDMA_CTLRS == 2) {
@@ -731,8 +735,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
- pdev1->dev.dma_mask = &pdev1->dev.coherent_dma_mask;
- pdev1->dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
out:
--
1.7.4.4
^ permalink raw reply related
* Re: [alsa-devel] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
From: Vinod Koul @ 2013-09-23 10:43 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: alsa-devel, linux-doc, linux-wireless, linux-fbdev, dri-devel,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, linux-nvme, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-mmc,
linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <20130921200000.GS25647@n2100.arm.linux.org.uk>
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> > Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > > The DMA API requires drivers to call the appropriate dma_set_mask()
> > > functions before doing any DMA mapping. Add this required call to
> > > the AMBA PL08x driver.
> > ^--- copy and paste error - should of course be PL330
>
> Fixed, thanks.
with fixed changelog...
Acked-by: Vinod Koul <vinod.koul@intel.com>
~Vinod
--
^ permalink raw reply
* Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
From: Vinod Koul @ 2013-09-23 10:25 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, linux-media, devicetree, dri-devel, linux-tegra,
Dan Williams, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
linux-crypto, uclinux-dist-devel, linuxppc-dev
In-Reply-To: <E1VMnRj-0007sg-1Z@rmk-PC.arm.linux.org.uk>
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> register_platform_device_full() can setup the DMA mask provided the
> appropriate member is set in struct platform_device_info. So lets
> make that be the case. This avoids a direct reference to the DMA
> masks by this driver.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Vinod Koul <vinod.koul@intel.com>
This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?
~Vinod
> ---
> drivers/dma/edma.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
> index ff50ff4..7f9fe30 100644
> --- a/drivers/dma/edma.c
> +++ b/drivers/dma/edma.c
> @@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
> static const struct platform_device_info edma_dev_info0 = {
> .name = "edma-dma-engine",
> .id = 0,
> + .dma_mask = DMA_BIT_MASK(32),
> };
>
> static const struct platform_device_info edma_dev_info1 = {
> .name = "edma-dma-engine",
> .id = 1,
> + .dma_mask = DMA_BIT_MASK(32),
> };
>
> static int edma_init(void)
> @@ -720,8 +722,6 @@ static int edma_init(void)
> ret = PTR_ERR(pdev0);
> goto out;
> }
> - pdev0->dev.dma_mask = &pdev0->dev.coherent_dma_mask;
> - pdev0->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> }
>
> if (EDMA_CTLRS == 2) {
> @@ -731,8 +731,6 @@ static int edma_init(void)
> platform_device_unregister(pdev0);
> ret = PTR_ERR(pdev1);
> }
> - pdev1->dev.dma_mask = &pdev1->dev.coherent_dma_mask;
> - pdev1->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> }
>
> out:
> --
> 1.7.4.4
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
^ permalink raw reply
* Re: [alsa-devel] [PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call
From: Vinod Koul @ 2013-09-23 10:12 UTC (permalink / raw)
To: Russell King
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
b43-dev-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Solarflare linux maintainers,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b, Dan Williams
In-Reply-To: <E1VMm4v-0007hz-RC-eh5Bv4kxaXIANfyc6IWni62ZND6+EDdj@public.gmane.org>
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
>
> Signed-off-by: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Acked-by: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
~Vinod
> ---
> drivers/dma/amba-pl08x.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
> index fce46c5..e51a983 100644
> --- a/drivers/dma/amba-pl08x.c
> +++ b/drivers/dma/amba-pl08x.c
> @@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const struct amba_id *id)
> if (ret)
> return ret;
>
> + /* Ensure that we can do DMA */
> + ret = dma_set_mask_and_coherent(&adev->dev, DMA_BIT_MASK(32));
> + if (ret)
> + goto out_no_pl08x;
> +
> /* Create the driver state holder */
> pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
> if (!pl08x) {
> --
> 1.7.4.4
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* Re: [PATCH 4/4] ARM: add support for bit sliced AES using NEON instructions
From: Ard Biesheuvel @ 2013-09-23 7:08 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: linux-crypto, linux-arm-kernel@lists.infradead.org, Nicolas Pitre,
Andy Polyakov
In-Reply-To: <523ED087.7050006@iki.fi>
On 22 September 2013 13:12, Jussi Kivilinna <jussi.kivilinna@iki.fi> wrote:
[...]
> Decryption can probably be made faster by implementing InvMixColumns slightly
> differently. Instead of implementing inverse MixColumns matrix directly, use
> preprocessing step, followed by MixColumns as described in section "4.1.3
> Decryption" of "The Design of Rijndael: AES - The Advanced Encryption Standard"
> (J. Daemen, V. Rijmen / 2002).
>
> In short, the MixColumns and InvMixColumns matrixes have following relation:
> | 0e 0b 0d 09 | | 02 03 01 01 | | 05 00 04 00 |
> | 09 0e 0b 0d | = | 01 02 03 01 | x | 00 05 00 04 |
> | 0d 09 0e 0b | | 01 01 02 03 | | 04 00 05 00 |
> | 0b 0d 09 0e | | 03 01 01 02 | | 00 04 00 05 |
>
> Bit-sliced implementation of the 05-00-04-00 matrix much shorter than 0e-0b-0d-09
> matrix, so even when combined with MixColumns total instruction count for
> InvMixColumns implemented this way should be nearly half of current.
>
That is a very useful tip, thank you. I will have a go at it and
follow up later.
Regards,
Ard.
^ permalink raw reply
* [PATCH 3/3] crypto: dcp: Fix the path for releasing the resources
From: Fabio Estevam @ 2013-09-22 17:42 UTC (permalink / raw)
To: herbert; +Cc: tobias.rauter, linux-crypto, Fabio Estevam
In-Reply-To: <1379871747-17570-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
tasklet_kill() is not being called in probe and the remove function releases
the resources in the wrong order.
Fix these issues.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/crypto/dcp.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 93ab753..38d7a9f 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -842,6 +842,8 @@ err_unregister:
for (j = 0; j < i; j++)
crypto_unregister_alg(&algs[j]);
err_free_key_iv:
+ tasklet_kill(&dev->done_task);
+ tasklet_kill(&dev->queue_task);
dma_free_coherent(&pdev->dev, 2 * AES_KEYSIZE_128, dev->payload_base,
dev->payload_base_dma);
err_free_hw_packet:
@@ -857,21 +859,21 @@ static int dcp_remove(struct platform_device *pdev)
struct dcp_dev *dev;
int j;
dev = platform_get_drvdata(pdev);
+
+ misc_deregister(&dev->dcp_bootstream_misc);
- dma_free_coherent(&pdev->dev,
- DCP_MAX_PKG * sizeof(struct dcp_hw_packet),
- dev->hw_pkg[0], dev->hw_phys_pkg);
-
- dma_free_coherent(&pdev->dev, 2 * AES_KEYSIZE_128, dev->payload_base,
- dev->payload_base_dma);
+ for (j = 0; j < ARRAY_SIZE(algs); j++)
+ crypto_unregister_alg(&algs[j]);
tasklet_kill(&dev->done_task);
tasklet_kill(&dev->queue_task);
- for (j = 0; j < ARRAY_SIZE(algs); j++)
- crypto_unregister_alg(&algs[j]);
+ dma_free_coherent(&pdev->dev, 2 * AES_KEYSIZE_128, dev->payload_base,
+ dev->payload_base_dma);
- misc_deregister(&dev->dcp_bootstream_misc);
+ dma_free_coherent(&pdev->dev,
+ DCP_MAX_PKG * sizeof(struct dcp_hw_packet),
+ dev->hw_pkg[0], dev->hw_phys_pkg);
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/3] crypto: dcp: Use devm_request_irq()
From: Fabio Estevam @ 2013-09-22 17:42 UTC (permalink / raw)
To: herbert; +Cc: tobias.rauter, linux-crypto, Fabio Estevam
In-Reply-To: <1379871747-17570-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@freescale.com>
Using Use devm_request_irq() can make the code smaller and simpler, as we do
not need to call free_irq() in the probe error path and in the remove function.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/crypto/dcp.c | 22 +++++++---------------
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 90a7cb7..93ab753 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -757,7 +757,8 @@ static int dcp_probe(struct platform_device *pdev)
return -EIO;
}
dev->dcp_vmi_irq = r->start;
- ret = request_irq(dev->dcp_vmi_irq, dcp_vmi_irq, 0, "dcp", dev);
+ ret = devm_request_irq(&pdev->dev, dev->dcp_vmi_irq, dcp_vmi_irq, 0,
+ "dcp", dev);
if (ret != 0) {
dev_err(&pdev->dev, "can't request_irq (0)\n");
return -EIO;
@@ -766,15 +767,14 @@ static int dcp_probe(struct platform_device *pdev)
r = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
if (!r) {
dev_err(&pdev->dev, "can't get IRQ resource (1)\n");
- ret = -EIO;
- goto err_free_irq0;
+ return -EIO;
}
dev->dcp_irq = r->start;
- ret = request_irq(dev->dcp_irq, dcp_irq, 0, "dcp", dev);
+ ret = devm_request_irq(&pdev->dev, dev->dcp_irq, dcp_irq, 0, "dcp",
+ dev);
if (ret != 0) {
dev_err(&pdev->dev, "can't request_irq (1)\n");
- ret = -EIO;
- goto err_free_irq0;
+ return -EIO;
}
dev->hw_pkg[0] = dma_alloc_coherent(&pdev->dev,
@@ -783,8 +783,7 @@ static int dcp_probe(struct platform_device *pdev)
GFP_KERNEL);
if (!dev->hw_pkg[0]) {
dev_err(&pdev->dev, "Could not allocate hw descriptors\n");
- ret = -ENOMEM;
- goto err_free_irq1;
+ return -ENOMEM;
}
for (i = 1; i < DCP_MAX_PKG; i++) {
@@ -849,10 +848,6 @@ err_free_hw_packet:
dma_free_coherent(&pdev->dev, DCP_MAX_PKG *
sizeof(struct dcp_hw_packet), dev->hw_pkg[0],
dev->hw_phys_pkg);
-err_free_irq1:
- free_irq(dev->dcp_irq, dev);
-err_free_irq0:
- free_irq(dev->dcp_vmi_irq, dev);
return ret;
}
@@ -870,9 +865,6 @@ static int dcp_remove(struct platform_device *pdev)
dma_free_coherent(&pdev->dev, 2 * AES_KEYSIZE_128, dev->payload_base,
dev->payload_base_dma);
- free_irq(dev->dcp_irq, dev);
- free_irq(dev->dcp_vmi_irq, dev);
-
tasklet_kill(&dev->done_task);
tasklet_kill(&dev->queue_task);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/3] crypto: dcp: Use devm_ioremap_resource()
From: Fabio Estevam @ 2013-09-22 17:42 UTC (permalink / raw)
To: herbert; +Cc: tobias.rauter, linux-crypto, Fabio Estevam
From: Fabio Estevam <fabio.estevam@freescale.com>
Using devm_ioremap_resource() can make the code simpler and smaller.
When devm_ioremap_resource() is used there is no need to explicitely check the
error returned by platform_get_resource().
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
drivers/crypto/dcp.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index a8a7dd4..90a7cb7 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -733,12 +733,7 @@ static int dcp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dev);
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r) {
- dev_err(&pdev->dev, "failed to get IORESOURCE_MEM\n");
- return -ENXIO;
- }
- dev->dcp_regs_base = devm_ioremap(&pdev->dev, r->start,
- resource_size(r));
+ dev->dcp_regs_base = devm_ioremap_resource(&pdev->dev, r);
dcp_set(dev, DCP_CTRL_SFRST, DCP_REG_CTRL);
udelay(10);
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 22/51] DMA-API: amba: get rid of separate dma_mask
From: Grant Likely @ 2013-09-22 12:18 UTC (permalink / raw)
To: Russell King, alsa-devel, b43-dev, devel, devicetree, dri-devel,
e1000-devel, linux-arm-kernel, linux-crypto, linux-doc,
linux-fbdev, linux-ide, linux-media, linux-mmc, linux-nvme,
linux-omap, linuxppc-dev, linux-samsung-soc, linux-scsi,
linux-tegra, linux-usb, linux-wireless, netdev,
Solarflare linux maintainers, uclinux-dist-devel
Cc: Rob Herring
In-Reply-To: <E1VMm3x-0007hp-Lv@rmk-PC.arm.linux.org.uk>
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King <rmk+kernel@arm.linux.org.uk> wrote:
> AMBA Primecell devices always treat streaming and coherent DMA exactly
> the same, so there's no point in having the masks separated.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
for the drivers/of/platform.c portion:
Acked-by: Grant Likely <grant.likely@linaro.org>
g.
^ permalink raw reply
* Re: [PATCH 4/4] ARM: add support for bit sliced AES using NEON instructions
From: Jussi Kivilinna @ 2013-09-22 11:12 UTC (permalink / raw)
To: Ard Biesheuvel, linux-crypto, linux-arm-kernel; +Cc: nico, Andy Polyakov
In-Reply-To: <1379702811-8025-5-git-send-email-ard.biesheuvel@linaro.org>
On 20.09.2013 21:46, Ard Biesheuvel wrote:
> This implementation of the AES algorithm gives around 45% speedup on Cortex-A15
> for CTR mode and for XTS in encryption mode. Both CBC and XTS in decryption mode
> are slightly faster (5 - 10% on Cortex-A15). [As CBC in encryption mode can only
> be performed sequentially, there is no speedup in this case.]
>
> Unlike the core AES cipher (on which this module also depends), this algorithm
> uses bit slicing to process up to 8 blocks in parallel in constant time. This
> algorithm does not rely on any lookup tables so it is believed to be
> invulnerable to cache timing attacks.
>
> The core code has been adopted from the OpenSSL project (in collaboration
> with the original author, on cc). For ease of maintenance, this version is
> identical to the upstream OpenSSL code, i.e., all modifications that were
> required to make it suitable for inclusion into the kernel have already been
> merged upstream.
>
> Cc: Andy Polyakov <appro@openssl.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
[..snip..]
> + bcc .Ldec_done
> + @ multiplication by 0x0e
Decryption can probably be made faster by implementing InvMixColumns slightly
differently. Instead of implementing inverse MixColumns matrix directly, use
preprocessing step, followed by MixColumns as described in section "4.1.3
Decryption" of "The Design of Rijndael: AES - The Advanced Encryption Standard"
(J. Daemen, V. Rijmen / 2002).
In short, the MixColumns and InvMixColumns matrixes have following relation:
| 0e 0b 0d 09 | | 02 03 01 01 | | 05 00 04 00 |
| 09 0e 0b 0d | = | 01 02 03 01 | x | 00 05 00 04 |
| 0d 09 0e 0b | | 01 01 02 03 | | 04 00 05 00 |
| 0b 0d 09 0e | | 03 01 01 02 | | 00 04 00 05 |
Bit-sliced implementation of the 05-00-04-00 matrix much shorter than 0e-0b-0d-09
matrix, so even when combined with MixColumns total instruction count for
InvMixColumns implemented this way should be nearly half of current.
Check [1] for implementation of this on AVX instruction set.
-Jussi
[1] https://github.com/jkivilin/supercop-blockciphers/blob/beyond_master/crypto_stream/aes128ctr/avx/aes_asm_bitslice_avx.S#L234
^ 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