gmane.linux.kernel.cryptoapi

Re: Oops on 3.10-rc1 related to ssh256_ssse3

Jussi Kivilinna — 2013-05-20T20:15:57

Appears to be stack corruption caused by sha256_transform_ssse3. Does attached patch help?

-Jussi

Re: [PATCH 19/39] ARM: ux500: Register Cyrp and Hash platform drivers on Snowball

Linus Walleij — 2013-05-20T12:17:10


Patch applied now that the deps are in place.

Yours,
Linus Walleij

Re: [PATCH 18/39] crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog

Linus Walleij — 2013-05-20T12:15:23


Patch applied with Herbert's ACK.

Thanks,
Linus Walleij

Re: [PATCH 16/39] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()

Linus Walleij — 2013-05-20T12:12:17


Patch applied with Herbert's ACK.

Thanks,
Linus Walleij

Re: [PATCH 15/39] crypto: ux500/cryp - Prepare clock before enabling it

Linus Walleij — 2013-05-20T12:10:54


Patch applied with Herbert's ACK.

Yours,
Linus Walleij

Re: [PATCH 14/39] ARM: ux500: Stop passing Hash DMA channel config information though pdata

Linus Walleij — 2013-05-20T12:09:11


Patch applied now that the deps are in!

Yours,
Linus Walleij

Re: [PATCH 12/39] crypto: ux500/hash - Prepare clock before enabling it

Linus Walleij — 2013-05-20T12:05:11


Patch applied to my dma40 branch with Herbert's ACK.

Yours,
Linus Walleij

Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()

Linus Walleij — 2013-05-20T12:01:06

I've fixed it up!

Yours,
Linus Walleij

NIST SP800-138 availibility using kernel crypto APIs for SMB3.0 MAC generation

Shirish Pargaonkar — 2013-05-20T02:49:58

With the recent patches added to kernel crypto for improving AES
support, adding aesni etc, it seems like it is time to add AES CMAC
to the cifs kernel module (for the popular SMB3 signing and per-share
encryption) but needed for an implementation for SP800-138 in kernel
crypto codebase.
Was specifically interested using the way defined in 3.1.4.2 of
MS-SMB2 document, in particular

KDF in Counter mode (section 5.1 of NIST SP 800-108) or a way to specify a mode
PRF as HMAC-SHA256 (or a way to specify a PRF)


cifs client would use this algorithm for SMB3.0 MAC generation
(network packet signing on network file system mounts to newer
generation NAS, and Windows 2012) and also for per-share encryption
(which is also available on the most recent generation of NAS via
SMB3). Apparently with current Intel processors having hardware for
this kind of encryption offload - full packet encryption is faster
than packet signing used to be (with the older standard algorithms)
and just doing packet signing is really fast.

[PATCH v2 1/1] crypto: Added support for Freescale's DCP co-processor

Tobias Rauter — 2013-05-19T19:59:38

This patch enables the DCP crypto functionality on imx28.
Currently, only aes-128-cbc is supported.
Moreover, the dcpboot misc-device, which is used by Freescale's
SDK tools and uses a non-software-readable OTP-key, is added.

Changes of v2:
- ring buffer for hardware-descriptors
- use of ablkcipher walk
- OTP key encryption/decryption via misc-device
  (compatible to Freescale-SDK)
- overall cleanup

The DCP is also capable of sha1/sha256 but I won't be able to add 
that anytime soon.
Tested with built-in runtime-self-test, tcrypt and openssl via 
cryptodev 1.6 on imx28-evk and a custom built imx28-board.


Signed-off-by: Tobias Rauter <tobias.rauter< at >gmail.com>
---
 arch/arm/boot/dts/imx28.dtsi |   2 +-
 drivers/crypto/Kconfig       |  10 +
 drivers/crypto/Makefile      |   1 +
 drivers/crypto/dcp.c         | 925 +++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 937 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/dcp.c

diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dt

Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver

Linus Walleij — 2013-05-17T06:35:04

On Wed, May 15, 2013 at 10:14 PM, Fabio Baltieri
<fabio.baltieri< at >linaro.org> wrote:

OK so Felipe can merge these smallish patches to musb, fine...

The other (DMA) stuff needs to be merged together with the rest
of the DMA40 series, so here basically Felipe needs an indication
if he can ACK it so I merge it through ARM SoC without colissions
and it sounds like we can make the assumption that this will work.

Yours,
Linus Walleij

Re: linux-next: Tree for May 15 (crypto /crct10dif)

Xiong Zhou — 2013-05-17T03:09:54

2013/5/17 Tim Chen <tim.c.chen< at >linux.intel.com>:

cool.

Re: linux-next: Tree for May 15 (crypto /crct10dif)

Xiong Zhou — 2013-05-17T03:06:06

2013/5/16 Geert Uytterhoeven <geert< at >linux-m68k.org>:

En.. make sense, Thanks.

Xiong

Re: linux-next: Tree for May 15 (crypto /crct10dif)

Tim Chen — 2013-05-16T16:59:12

This is the fix I think that will resolve the build issues.  The generic
crc-t10dif transform depends on the library function crc_t10dif_generic
in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
needed.

Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
allocate a T10DIF transform if it is available.  If not, it will simply
use the crc_t10dif_generic function. Loading the
generic t10dif crypto transform is not mandatory for the library
function crc_t10dif. 

Thanks for catching the issues.

Tim

Signed-off-by: Tim Chen <tim.c.chen< at >linux.intel.com>
---
diff --git a/crypto/Kconfig b/crypto/Kconfig
index d1ca631..015df24 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
< at >< at > -379,6 +379,7 < at >< at > config CRYPTO_CRC32_PCLMUL
 config CRYPTO_CRCT10DIF
 tristate "CRCT10DIF algorithm"
 select CRYPTO_HASH
+depends on CRC_T10DIF
 help
   CRC T10 Data Integrity Field computation is being cast as
   a crypto transform.  This allows for faster crc t10 diff
diff --git a/lib/Kconfig

Re: linux-next: Tree for May 15 (crypto /crct10dif)

Tim Chen — 2013-05-16T16:09:54

I think "depends on" CRC_T10DIF is okay.  This generic transform is not
needed if we are not using the T10-DIF library.  It is meant for
wrapping the library call to t10-dif as a crypto transform.

Oops on 3.10-rc1 related to ssh256_ssse3

Julian Wollrath — 2013-05-16T13:41:35

Hello,

I have an encrypted disc (dm-crypt, type LUKS1, ssh256 as hash
algorithm). I have an Intel Core i5 M450 that supports ssse3. Find
below the output from netconsole with the oops. The last warning
appeared when I restart the pc using the magic sysrq key combination
REISUB. I have the same problem with a different laptop with an AMD
E-450 APU.

If you need further information, feel free to ask.


Best regards,
Julian Wollrath

[    3.647071] device-mapper: uevent: version 1.0.3
[    3.647245] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-devel< at >redhat.com
[   11.619603] sha256_ssse3: Using SSSE3 optimized SHA-256 implementation
[   12.131483] BUG: unable to handle kernel paging request at ffff8800bb593000
[   12.131848] IP: [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[   12.132032] PGD 1a32067 PUD 1a35067 PMD 1a36067 PTE 0
[   12.132427] Oops: 0000 [#1] SMP 
[   12.132670] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue

[PATCH 6/6] crypto: ux500/hash - Enable DT probing of the driver

Lee Jones — 2013-05-16T11:27:26

By providing an OF match table with a suitable compatible string, we
can ensure the ux500-hasht driver is probed by supplying an associated
DT node in a given platform's Device Tree.

Cc: Herbert Xu <herbert< at >gondor.apana.org.au>
Cc: linux-crypto< at >vger.kernel.org
Signed-off-by: Lee Jones <lee.jones< at >linaro.org>
---
 drivers/crypto/ux500/hash/hash_core.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index 9ca6fbb..f89fe8a 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
< at >< at > -1981,6 +1981,11 < at >< at > static int ux500_hash_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(ux500_hash_pm, ux500_hash_suspend, ux500_hash_resume);
 
+static const struct of_device_id ux500_hash_match[] = {
+        { .compatible = "stericsson,ux500-hash" },
+        { },
+};
+
 static struct platform_driver hash_driver = {
 .probe  = ux500_hash_probe,
 .remove = ux500_hash_remove,
< at >< at > -1988,6 +1993,7

Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value

Vinod Koul — 2013-05-16T09:41:57

Okay...

--
~Vinod

Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()

Vinod Koul — 2013-05-16T09:40:14

Certainly not in MAINTAINERS file :)

--
~Vinod

Re: [PATCH 08/39] dmaengine: ste_dma40: Remove redundant address fetching function

Vinod Koul — 2013-05-16T06:41:09

Acked-by: Vinod Koul <vinod.koul< at >intel.com>

--
~Vinod

Re: [PATCH 03/39] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate

Vinod Koul — 2013-05-16T06:36:40

Acked-by: Vinod Koul <vinod.koul< at >intel.com>

--
~Vinod