Re: UB in general ... and linux/bitops.h in particular

>-- Perhaps the compiler guys could be persuaded to support > the needed features explicitly, perhaps via a command-line > option: -std=vanilla > This should be a no-cost option as things stand today, but > it helps to prevent nasty surprises in the future. It looks LLVM has

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > > So this is why I tend to take a much more pragmatic viewpoint on > things. Sure, it makes sense to pay attention to what the C standard > writers are trying to do to us; but if we need to suppress certain > optimizations to write sane kernel code

Re: better patch for linux/bitops.h

On May 5, 2016 3:18:09 PM PDT, ty...@mit.edu wrote: >On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: > > I completely fail to see why tests or compiler versions should be > part of the discussion. The C standard says the behaviour in > certain cases is undefined, so a standard-compliant compiler > can generate more-or-less any code

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > Instead of arguing over who's "sane" or "insane", can we come up with > a agreed upon set of tests, and a set of compiler and compiler > versions ... I completely fail to see why tests or compiler versions should be part of

[PATCH RESEND v5 3/6] crypto: AF_ALG -- add asymmetric cipher interface

From: Stephan Mueller This patch adds the user space interface for asymmetric ciphers. The interface allows the use of sendmsg as well as vmsplice to provide data. This version has been rebased on top of 4.6 and a few chackpatch issues have been fixed. Signed-off-by:

[PATCH RESEND v5 4/6] crypto: algif_akcipher - enable compilation

From: Stephan Mueller Add the Makefile and Kconfig updates to allow algif_akcipher to be compiled. Signed-off-by: Stephan Mueller Signed-off-by: Tadeusz Struk --- crypto/Kconfig |9 + crypto/Makefile |1 + 2

[PATCH RESEND v5 1/6] crypto: AF_ALG -- add sign/verify API

From: Stephan Mueller Add the flags for handling signature generation and signature verification. Also, the patch adds the interface for setting a public key. Signed-off-by: Stephan Mueller Signed-off-by: Tadeusz Struk ---

[PATCH RESEND v5 5/6] crypto: algif_akcipher - add ops_nokey

Similar to algif_skcipher and algif_hash, algif_akcipher needs to prevent user space from using the interface in an improper way. This patch adds nokey ops handlers, which do just that. Signed-off-by: Tadeusz Struk --- crypto/algif_akcipher.c | 159

[PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id

This patch adds support for asymmetric key type to AF_ALG. It will work as follows: A new PF_ALG socket options are added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID for setting public and private keys respectively. When these new options will be

[PATCH RESEND v5 2/6] crypto: AF_ALG -- add setpubkey setsockopt call

From: Stephan Mueller For supporting asymmetric ciphers, user space must be able to set the public key. The patch adds a new setsockopt call for setting the public key. Signed-off-by: Stephan Mueller --- crypto/af_alg.c | 18

[PATCH RESEND v5 0/6] crypto: algif - add akcipher

First four patches are a resend of the v3 algif_akcipher from Stephan Mueller, with minor changes after rebase on top of 4.6-rc1. The next three patches add support for keys stored in system keyring subsystem. First patch adds algif_akcipher nokey hadlers. Second patch adds generic sign,

Re: [PATCH v2 3/8] arm64: add io{read,write}64be accessors

On Thu, May 05, 2016 at 06:36:04PM +0300, Horia Geantă wrote: > This will allow device drivers to consistently use io{read,write}XXbe > also for 64-bit accesses. > > Signed-off-by: Alex Porosanu > Signed-off-by: Horia Geantă Acked-by: Catalin

Re: UB in general ... and linux/bitops.h in particular

> Suggestions: > > a) Going forward, I suggest that UB should not be invoked > unless there is a good solid reason. Good luck rewriting most of the kernel source. This discussion is insane! -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a

Re: [PATCH v2 2/8] asm-generic/io.h: add io{read,write}64 accessors

On Thursday 05 May 2016 18:35:56 Horia Geantă wrote: > This will allow device drivers to consistently use io{read,write}XX > also for 64-bit accesses. > > Signed-off-by: Horia Geantă > Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line

Re: [crypto / sparc64] cryptomgr_test OOPS

On 05/05/2016 02:50 AM, Herbert Xu wrote: > On Thu, May 05, 2016 at 12:40:18PM +0300, Anatoly Pugachev wrote: >> >> sure, based on your cryptodev git, just tried 4.3 (6a13feb , good) >> kernel in attempt to find (bisect) when RSA code break, already tested >> 4.5 (44d1b6d , bad) , 4.4 (afd2ff9 ,

Re: [crypto / sparc64] cryptomgr_test OOPS

On 05/05/2016 08:31 AM, Anatoly Pugachev wrote: > On Thu, May 5, 2016 at 6:00 PM, Tadeusz Struk wrote: >> On 05/05/2016 02:40 AM, Anatoly Pugachev wrote: >>> sure, based on your cryptodev git, just tried 4.3 (6a13feb , good) >>> kernel in attempt to find (bisect) when RSA

Re: [PATCH] Bluetooth: convert smp module to crypto kpp API

Hi Salvatore, > This patch has *not* been tested as I don't have the hardware. > It's purpose is to show how to use the kpp API. > > Based on https://patchwork.kernel.org/patch/9022371/ actually you should be able to verify this without hardware. The BlueZ userspace package contains

[PATCH v2 6/8] crypto: caam - handle core endianness != caam endianness

There are SoCs like LS1043A where CAAM endianness (BE) does not match the default endianness of the core (LE). Moreover, there are requirements for the driver to handle cases like CPU_BIG_ENDIAN=y on ARM-based SoCs. This requires for a complete rewrite of the I/O accessors. PPC-specific accessors

Re: [crypto / sparc64] cryptomgr_test OOPS

On 05/05/2016 05:31 PM, Anatoly Pugachev wrote: > do you still want to test it , after I have reported that Herbert patch works? Maybe you should ack the patch with: Tested-By: Anatoly Pugachev ? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian

[PATCH v2 7/8] crypto: caam - add ARCH_LAYERSCAPE to supported architectures

This basically adds support for ls1043a platform. Signed-off-by: Horia Geantă --- drivers/crypto/caam/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig index d2c2909a4020..ff54c42e6e51

[PATCH v2 8/8] arm64: dts: ls1043a: add crypto node

LS1043A has a SEC v5.4 security engine. For now don't add rtic or sec_mon subnodes, since these features haven't been tested yet. Signed-off-by: Horia Geantă --- arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 4 +++ arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi|

[PATCH v2 0/8] crypto: caam - add support for LS1043A SoC

v2: As suggested by Arnd, patch 1 fixes io{read,write}{16,32}be accessors to prevent the case when {read,write}{w,l} are overriden by arch-specific ones having barriers, while the BE accessors previously mentioned are not (thus behaving differently, having no barriers). Hi, [Patches 2-4 add

[PATCH v2 4/8] powerpc: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Signed-off-by: Horia Geantă --- arch/powerpc/kernel/iomap.c | 24 1 file changed, 24 insertions(+) diff --git a/arch/powerpc/kernel/iomap.c

[PATCH v2 5/8] crypto: caam - fix offset field in hw sg entries

From: Cristian Stoica The offset field is 13 bits wide; make sure we don't overwrite more than that in the caam hardware scatter gather structure. Signed-off-by: Cristian Stoica Signed-off-by: Horia Geantă ---

[PATCH v2 3/8] arm64: add io{read,write}64be accessors

This will allow device drivers to consistently use io{read,write}XXbe also for 64-bit accesses. Signed-off-by: Alex Porosanu Signed-off-by: Horia Geantă --- arch/arm64/include/asm/io.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)

[PATCH v2 2/8] asm-generic/io.h: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Signed-off-by: Horia Geantă --- include/asm-generic/io.h| 63 + include/asm-generic/iomap.h | 8 ++ 2 files changed, 71

Re: [crypto / sparc64] cryptomgr_test OOPS

On Thu, May 5, 2016 at 6:00 PM, Tadeusz Struk wrote: > On 05/05/2016 02:40 AM, Anatoly Pugachev wrote: >> sure, based on your cryptodev git, just tried 4.3 (6a13feb , good) >> kernel in attempt to find (bisect) when RSA code break, already tested >> 4.5 (44d1b6d , bad) ,

Re: [crypto / sparc64] cryptomgr_test OOPS

On 05/05/2016 05:12 PM, Anatoly Pugachev wrote: > this patch, applied to your cryptodev git kernel, fixes OOPS and my > debian sparc64 installation boots successfully: Awesome to hear, thanks for investigating and fixing this :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian

Re: [crypto / sparc64] cryptomgr_test OOPS

On Thu, May 5, 2016 at 11:42 AM, Herbert Xu wrote: > On Wed, May 04, 2016 at 05:49:04PM +0300, Anatoly Pugachev wrote: >> >> just tested cryptodev ( >> http://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git >> ) kernel, same OOPS, but kernel version

Re: [crypto / sparc64] cryptomgr_test OOPS

On 05/05/2016 02:40 AM, Anatoly Pugachev wrote: > sure, based on your cryptodev git, just tried 4.3 (6a13feb , good) > kernel in attempt to find (bisect) when RSA code break, already tested > 4.5 (44d1b6d , bad) , 4.4 (afd2ff9 , bad). > Going to try your patch soon (when I'm back home). > So far

[PATCH] crypto: vmx - comply with ABIs that specify vrsave as reserved.

It gives significant improvements ( ~+15%) on some modes. These code has been adopted from OpenSSL project in collaboration with the original author (Andy Polyakov ). Signed-off-by: Paulo Flabiano Smorigo --- drivers/crypto/vmx/ppc-xlate.pl | 20

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 04, 2016 at 09:10:07PM -0400, Theodore Ts'o wrote: > On Wed, May 04, 2016 at 10:28:24PM +0200, Stephan Mueller wrote: > > > +out: > > > + spin_unlock_irqrestore(_crng.lock, flags); > > > + return ret; > > > > Where did you add the memzero_explict of tmp? > > Oops, sorry, somehow that

Re: [PATCH 1/7] asm-generic/io.h: add io{read,write}64 accessors

On Thursday 05 May 2016 04:26 PM, Arnd Bergmann wrote: > On Thursday 05 May 2016 08:16:47 Vineet Gupta wrote: >> > Thx for noticing this Arnd and the heads up. Does the patch below look ok >> > to you ? >> > >> > ---> >> > rom b7e719831c389ab4fa338b2e2e7c0d1ff90dabb0 Mon Sep 17 00:00:00

RE: [PATCH] crypto: rsa - return raw integer for the ASN.1 parser

Hi Herbert, This is related to the suggestion to move the DMA primitives in the driver. Please see inline. > -Original Message- > From: Tudor Ambarus [mailto:tudor-dan.amba...@nxp.com] > Sent: Friday, April 29, 2016 3:52 PM > To: herb...@gondor.apana.org.au > Cc:

Re: [PATCH 1/7] asm-generic/io.h: add io{read,write}64 accessors

On Thursday 05 May 2016 08:16:47 Vineet Gupta wrote: > Thx for noticing this Arnd and the heads up. Does the patch below look ok to > you ? > > ---> > rom b7e719831c389ab4fa338b2e2e7c0d1ff90dabb0 Mon Sep 17 00:00:00 2001 > From: Vineet Gupta > Date: Thu, 5 May 2016

Re: [RFC PATCH 2/5] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys

I've pushed a fix to #include in keyctl_pkey.c into the git tree. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [crypto / sparc64] cryptomgr_test OOPS

On Thu, May 05, 2016 at 12:40:18PM +0300, Anatoly Pugachev wrote: > > sure, based on your cryptodev git, just tried 4.3 (6a13feb , good) > kernel in attempt to find (bisect) when RSA code break, already tested > 4.5 (44d1b6d , bad) , 4.4 (afd2ff9 , bad). > Going to try your patch soon (when I'm

Re: [crypto / sparc64] cryptomgr_test OOPS

On Thu, May 5, 2016 at 11:42 AM, Herbert Xu wrote: > On Wed, May 04, 2016 at 05:49:04PM +0300, Anatoly Pugachev wrote: >> >> just tested cryptodev ( >> http://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git >> ) kernel, same OOPS, but kernel version

RE: [PATCH 0/3 v3] Key-agreement Protocol Primitives (KPP) API

> -Original Message- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Thursday, May 5, 2016 7:22 AM > To: Benedetto, Salvatore > Cc: linux-crypto@vger.kernel.org > Subject: Re: [PATCH 0/3 v3] Key-agreement Protocol Primitives (KPP) API > > On

[PATCH] Bluetooth: convert smp module to crypto kpp API

This patch has *not* been tested as I don't have the hardware. It's purpose is to show how to use the kpp API. Based on https://patchwork.kernel.org/patch/9022371/ Signed-off-by: Salvatore Benedetto --- net/bluetooth/smp.c | 99

[PATCH 3/3 v4] crypto: kpp - Add ECDH software support

* Implement ECDH under kpp API * Provide ECC software support for curve P-192 and P-256. * Add kpp test for ECDH with data generated by OpenSSL Signed-off-by: Salvatore Benedetto --- crypto/Kconfig |5 + crypto/Makefile |3 +

[PATCH 2/3 v4] crypto: kpp - Add DH software implementation

* Implement MPI based Diffie-Hellman under kpp API * Test provided uses data generad by OpenSSL Signed-off-by: Salvatore Benedetto --- crypto/Kconfig | 8 ++ crypto/Makefile | 2 + crypto/dh.c | 224

[PATCH 1/3 v4] crypto: Key-agreement Protocol Primitives API (KPP)

Add key-agreement protocol primitives (kpp) API which allows to implement primitives required by protocols such as DH and ECDH. The API is composed mainly by the following functions * set_params() - It allows the user to set the parameters known to both parties involved in the key-agreement

Re: [crypto / sparc64] cryptomgr_test OOPS

On Wed, May 04, 2016 at 05:49:04PM +0300, Anatoly Pugachev wrote: > > just tested cryptodev ( > http://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git > ) kernel, same OOPS, but kernel version is 4.6.0-rc2+ . > kernel OOPS message -

Re: [PATCH 1/7] asm-generic/io.h: add io{read,write}64 accessors

On Thursday 05 May 2016 04:06 AM, Arnd Bergmann wrote: > On Wednesday 04 May 2016 20:16:19 Horia Geantă wrote: >> @@ -625,6 +645,16 @@ static inline u32 ioread32be(const volatile void >> __iomem *addr) >> } >> #endif >> >> +#ifdef CONFIG_64BIT >> +#ifndef ioread64be >> +#define ioread64be

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

On Wed, May 04, 2016 at 06:38:46AM -0700, Tadeusz Struk wrote: > Hi David > On 05/04/2016 02:01 AM, David Howells wrote: > > Do you want to push this via Herbert's tree? > > > > Yes, I think Herbert has some more patches queued for rc-7. > Let me also send a proper one with the signed-off tag. >

Re: [PATCH v3] crypto: Add a flag allowing the self-tests to be disabled at runtime.

On Tue, May 03, 2016 at 10:00:17AM +0100, Richard W.M. Jones wrote: > Running self-tests for a short-lived KVM VM takes 28ms on my laptop. > This commit adds a flag 'cryptomgr.notests' which allows them to be > disabled. > > However if fips=1 as well, we ignore this flag as FIPS mode mandates >

Re: better patch for linux/bitops.h

On 05/04/16 21:03, Jeffrey Walton wrote: On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: ... But instead of arguing over what works and doesn't, let's just create the the test set and just try it on a wide range of compilers and architectures, hmmm? What are the

Re: [PATCH 0/3 v3] Key-agreement Protocol Primitives (KPP) API

On Tue, May 03, 2016 at 12:44:00PM +0100, Salvatore Benedetto wrote: > Hi Herb, > > the following patchset introduces a new API for abstracting key-agreement > protocols such as DH and ECDH. It provides the primitives required for > implementing > the protocol, thus the name KPP (Key-agreement