headers
Theodore Ts'o | 21 May 2013 21:01
Picon
Picon
Favicon
Gravatar

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

I continue to be suspicious about claims that userspace timing
measurements are measuring anything other than OS behaviour.  But that
doesn't mean that they shouldn't exist.  Personally, I believe you
should try to collect as much entropy as you can, from as many places
as you can.  For VM's, it means we should definitely use
paravirtualization to get randomness from the host OS.  If you don't
trust the host OS, then what on earth are you doing trying to generate
a long-term public key pair on the VM in the first place?  For that
matter, why are you willing to expose a high value private keypair on
the VM?

For devices like Linux routers, what we desperately need is hardware
assist; either a on-CPU hardware random number generator, or a
hardware RNG from a TPM module, or having an individualized secret key
generated at manufacturing time and burned onto the device.  If you
don't trust that the Intel hardware RNG honest, then by all means mix
in additional timing information either at kernel device driver level,
or from systems such as HAVEGE.

What I'm against is relying only on solutions such as HAVEGE or
replacing /dev/random with something scheme that only relies on CPU
timing and ignores interrupt timing.

Regards,

					- Ted
Permalink | Reply | 2 comments |
headers
Stephan Mueller | 21 May 2013 18:56
Picon

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

On Tue, 21 May 2013 12:09:02 -0400
Sandy Harris <sandyinchina <at> gmail.com> wrote:

Hi Sandy,

> I very much like the basic notion here. The existing random(4) driver
> may not get enough entropy in a VM or on a device like a Linux router
> and I think work such as yours or HAVEGE (
> http://www.irisa.fr/caps/projects/hipsor/) are important research. The
> paper by McGuire et al of "Analysis of inherent randomness of the
> Linux
> kernel" (http://lwn.net/images/conf/rtlws11/random-hardware.pdf)
> seems to show that this is a fine source of more entropy.
> 
> On the other hand, I am not certain you are doing it in the right
> place. My own attempt (ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/)
> put it in a demon that just feeds /dev/random, probably also not the
> right place. haveged(8) ( http://www.issihosts.com/haveged/) also
> puts it in a demon process. It may, as you suggest, belong in the
> kernel instead, but I think there are arguments both ways.

Thanks for your insights. What I propose is that it shall NOT have any
fixed place at all.

The entropy collection shall be as close to the "consumer" as
possible. There shall be NO single one entropy collector, but one for
every consumer.

That is the reason, why the code I am offering has that many links to
different crypto libs or even a stand-alone shared lib compilation.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jussi Kivilinna | 21 May 2013 16:10
Picon
Picon
Favicon

[PATCH 1/2] crypto: sha512_ssse3 - add sha384 support

Add sha384 implementation to sha512_ssse3 module.

This also fixes sha512_ssse3 module autoloading issue when 'sha384' is used
before 'sha512'. Previously in such case, just sha512_generic was loaded and
not sha512_ssse3 (since it did not provide sha384). Now if 'sha512' was used
after 'sha384' usage, sha512_ssse3 would remain unloaded. For example, this
happens with tcrypt testing module since it tests 'sha384' before 'sha512'.

Cc: Tim Chen <tim.c.chen <at> linux.intel.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna <at> iki.fi>
---
 arch/x86/crypto/sha512_ssse3_glue.c |   58 ++++++++++++++++++++++++++++++++---
 1 file changed, 53 insertions(+), 5 deletions(-)

diff --git a/arch/x86/crypto/sha512_ssse3_glue.c b/arch/x86/crypto/sha512_ssse3_glue.c
index 6cbd8df..f30cd10 100644
--- a/arch/x86/crypto/sha512_ssse3_glue.c
+++ b/arch/x86/crypto/sha512_ssse3_glue.c
 <at>  <at>  -194,7 +194,37  <at>  <at>  static int sha512_ssse3_import(struct shash_desc *desc, const void *in)
 	return 0;
 }

-static struct shash_alg alg = {
+static int sha384_ssse3_init(struct shash_desc *desc)
+{
+	struct sha512_state *sctx = shash_desc_ctx(desc);
+
+	sctx->state[0] = SHA384_H0;
+	sctx->state[1] = SHA384_H1;
+	sctx->state[2] = SHA384_H2;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jussi Kivilinna | 21 May 2013 16:10
Picon
Picon
Favicon

[PATCH] crypto: sha512_generic - set cra_driver_name

'sha512_generic' should set driver name now that there is alternative sha512
provider (sha512_ssse3).

Signed-off-by: Jussi Kivilinna <jussi.kivilinna <at> iki.fi>
---
 crypto/sha512_generic.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/sha512_generic.c b/crypto/sha512_generic.c
index 4c58620..6ed124f 100644
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
 <at>  <at>  -251,6 +251,7  <at>  <at>  static struct shash_alg sha512_algs[2] = { {
 	.descsize	=	sizeof(struct sha512_state),
 	.base		=	{
 		.cra_name	=	"sha512",
+		.cra_driver_name =	"sha512-generic",
 		.cra_flags	=	CRYPTO_ALG_TYPE_SHASH,
 		.cra_blocksize	=	SHA512_BLOCK_SIZE,
 		.cra_module	=	THIS_MODULE,
 <at>  <at>  -263,6 +264,7  <at>  <at>  static struct shash_alg sha512_algs[2] = { {
 	.descsize	=	sizeof(struct sha512_state),
 	.base		=	{
 		.cra_name	=	"sha384",
+		.cra_driver_name =	"sha384-generic",
 		.cra_flags	=	CRYPTO_ALG_TYPE_SHASH,
 		.cra_blocksize	=	SHA384_BLOCK_SIZE,
 		.cra_module	=	THIS_MODULE,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jussi Kivilinna | 21 May 2013 16:09
Picon
Picon
Favicon

[PATCH] crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations

The _XFER stack element size was set too small, 8 bytes, when it needs to be
16 bytes. As _XFER is the last stack element used by these implementations,
the 16 byte stores with 'movdqa' corrupt the stack where the value of register
%r12 is temporarily stored. As these implementations align the stack pointer
to 16 bytes, this corruption did not happen every time.

Patch corrects this issue.

Reported-by: Julian Wollrath <jwollrath <at> web.de>
Cc: Tim Chen <tim.c.chen <at> linux.intel.com>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna <at> iki.fi>
---
 arch/x86/crypto/sha256-avx-asm.S   |    2 +-
 arch/x86/crypto/sha256-ssse3-asm.S |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/crypto/sha256-avx-asm.S b/arch/x86/crypto/sha256-avx-asm.S
index 56610c4..642f156 100644
--- a/arch/x86/crypto/sha256-avx-asm.S
+++ b/arch/x86/crypto/sha256-avx-asm.S
 <at>  <at>  -118,7 +118,7  <at>  <at>  y2 = %r15d

 _INP_END_SIZE = 8
 _INP_SIZE = 8
-_XFER_SIZE = 8
+_XFER_SIZE = 16
 _XMM_SAVE_SIZE = 0

 _INP_END = 0
diff --git a/arch/x86/crypto/sha256-ssse3-asm.S b/arch/x86/crypto/sha256-ssse3-asm.S
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephan Mueller | 21 May 2013 08:44
Picon

[PATCH][RFC] CPU Jitter random number generator (resent)

Hi,

[1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2

A new version of the CPU Jitter random number generator is released at
http://www.chronox.de/ . The heart of the RNG is about 30 lines of easy
to read code. The readme in the main directory explains the different
code files. A changelog can be found on the web site.

In a previous attempt (http://lkml.org/lkml/2013/2/8/476), the first
iteration received comments for the lack of tests, documentation and
entropy assessment. All these concerns have been addressed. The
documentation of the CPU Jitter random number generator
(http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html and PDF at
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and
pictures are better in PDF) offers a full analysis of:

- the root cause of entropy

- a design of the RNG

- statistical tests and analyses

- entropy assessment and explanation of the flow of entropy

The document also explains the core concept to have a fully
decentralized entropy collector for every caller in need of entropy.

Also, this RNG is well suitable for virtualized environments.
Measurements on OpenVZ and KVM environments have been conducted as
(Continue reading)

Permalink | Reply | 1 comment |
headers
Shirish Pargaonkar | 20 May 2013 04:49
Picon

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

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.

Are their APIs in crypto kernel code to use for this purpose?

Regards,

Shirish
Permalink | Reply | 0 comments |
headers
Tobias Rauter | 19 May 2013 21:59
Picon

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

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/dts/imx28.dtsi
index 600f7cb..077d0eb 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Wollrath | 16 May 2013 15:41
Picon

Oops on 3.10-rc1 related to ssh256_ssse3

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_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod
sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169
mii usbcore usb_common thermal thermal_sys
[   12.135396] CPU: 3 PID: 276 Comm: cryptomgr_test Not tainted 3.10.0-rc1+ #2
[   12.135559] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
[   12.135720] task: ffff880037572090 ti: ffff8800b66b6000 task.ti: ffff8800b66b6000
[   12.135836] RIP: 0010:[<ffffffffa016b083>]  [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[   12.136032] RSP: 0018:ffff8800b66b7af0  EFLAGS: 00010287
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lee Jones | 15 May 2013 11:51
Favicon

[PATCH 00/39] Continuation of DMA changes in ux500 based drivers

A great deal of these patches have now been applied through various trees.
We now need to grab the attention of the outstanding DMA clients (MUSB and
Crypto) to progress.

Also, Linus could probably do with a hand from Vinod for the remaining
dmaengine patches.

Thanks in advance.

 Documentation/devicetree/bindings/dma/ste-dma40.txt |    4 ++
 Documentation/devicetree/bindings/usb/ux500-usb.txt |   50 ++++++++++++++++++
 arch/arm/mach-ux500/board-mop500-audio.c            |   12 ++---
 arch/arm/mach-ux500/board-mop500-sdi.c              |   16 +++---
 arch/arm/mach-ux500/board-mop500.c                  |   36 +++++--------
 arch/arm/mach-ux500/cpu-db8500.c                    |   34 ++++--------
 arch/arm/mach-ux500/devices-db8500.c                |   80 ----------------------------
 arch/arm/mach-ux500/usb.c                           |   37 +++----------
 drivers/crypto/ux500/cryp/cryp.h                    |    7 ++-
 drivers/crypto/ux500/cryp/cryp_core.c               |   31 ++++++++++-
 drivers/crypto/ux500/hash/hash_alg.h                |    5 +-
 drivers/crypto/ux500/hash/hash_core.c               |   24 ++++++++-
 drivers/dma/ste_dma40.c                             |  292 +++++++++++++++++++++++++++++++++++++++++++++++++----------------------------------------------------
 drivers/dma/ste_dma40_ll.c                          |  189 +++++++++++++++++++++++++++++++++--------------------------------
 drivers/dma/ste_dma40_ll.h                          |    3 +-
 drivers/usb/musb/ux500.c                            |   61 ++++++++++++++++++++-
 drivers/usb/musb/ux500_dma.c                        |   59 ++++++++++++---------
 include/linux/platform_data/dma-ste-dma40.h         |   25 ++-------
 include/linux/platform_data/usb-musb-ux500.h        |    5 +-
 sound/soc/ux500/ux500_pcm.c                         |   10 ++--
 20 files changed, 506 insertions(+), 474 deletions(-)
(Continue reading)

Permalink | Reply | 93 comments |
headers
Herbert Xu | 14 May 2013 08:56
Picon
Picon

Re: [cryptodev:master 2/13] crct10dif.c:undefined reference to `crypto_register_shash'

On Tue, May 14, 2013 at 02:18:54PM +0800, kbuild test robot wrote:
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> head:   78cdfaf27bf1a3d5c8c9907c72f1a32dafe0ec04
> commit: e3a0f01adfccf883a14df83f81a2b37d03d6926d [2/13] crypto: crct10dif - Wrap crc_t10dif
function all to use crypto transform framework
> config: i386-randconfig-x10-0513 (attached as .config)
> 
> All error/warnings:
> 
>    crypto/built-in.o: In function `crct10dif_mod_init':
> >> crct10dif.c:(.init.text+0x9): undefined reference to `crypto_register_shash'
>    crypto/built-in.o: In function `crct10dif_mod_fini':
> >> crct10dif.c:(.exit.text+0x9): undefined reference to `crypto_unregister_shash'
>    lib/built-in.o: In function `crc_t10dif':
>    (.text+0x1047a): undefined reference to `crypto_shash_update'
>    lib/built-in.o: In function `crc_t10dif_update_lib':
>    (.text+0x104b6): undefined reference to `crypto_alloc_shash'
>    lib/built-in.o: In function `crc_t10dif_update_lib':
>    (.text+0x1052e): undefined reference to `crypto_destroy_tfm'
>    lib/built-in.o: In function `crc_t10dif_update_lib':
>    (.text+0x10540): undefined reference to `crypto_destroy_tfm'
>    lib/built-in.o: In function `crc_t10dif_mod_fini':
>    crc-t10dif.c:(.exit.text+0x10): undefined reference to `crypto_destroy_tfm'

Oops, I forgot to take out the dependency.

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 68de618..d1ca631 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
(Continue reading)

Permalink | Reply | 0 comments |

Gmane