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 iore
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 - https://paste.fedoraproject.org/362554/23732641/
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 Protocol Primitives).
Regards,
Salvatore
Changes from v1:
* Change check in dh_c
* 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 +
crypto/ecc.c| 1038
* 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
crypto/testmgr.c
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 ses
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 -
1 file chang
> -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 Tue, May 03, 2016 at 12:44:00PM
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 is 4.6.0-rc2+ .
>> kernel 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 ba
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
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 13:32:34 +0530
> Subje
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: linux-crypto@vger.kernel
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 2
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(&primary_crng.lock, flags);
> > > + return ret;
> >
> > Where did you add the memzero_explict of tmp?
>
> Oops, sorry, someh
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
1 file changed, 20 insertio
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 4.
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 is 4.6.0-rc2+ .
>> kernel 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 Develo
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) , 4.4 (afd2ff9 , bad).
>> Go
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
---
v2: Also convert ecc_make_key to kpp API
net/bluetooth/smp.c | 184
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 b/arch/powerpc/kernel/iomap.c
index
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ă
---
drivers/crypto/caam/desc.h | 2 +-
drivers/crypto/caam/sg_sw_sec4.h | 8 -
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(-)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm6
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 insertions(+)
diff --git a/i
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 io{re
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| 43 +++
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 100644
--- a/drivers/crypto
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 Developer - glaub...@debian.o
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
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 tools/mgmt-
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 code break, already teste
On 05/04/2016 11:35 PM, H. Peter Anvin wrote:
> The disagreement here is the priority between these points.
Yes.
As usual, all the extremes are wrong.
Tradeoffs must be made.
Perspective and judgment are required.
> In my very strong opinion, "no undefined behavior" per the C standard
> is way
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 , ba
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 "unsubscribe linux-crypto" in
the bod
> 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 mess
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 Marinas
--
To unsubscribe from this list: send the
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, verify,
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 +-
include/crypto/if_alg.h |1 +
2 fil
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 u
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: Stephan Mueller
Signed-off
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 files changed, 10 insertions(+)
diff --git a/crypto/Kconfig b/crypt
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
---
include/uapi/linux/if_alg.h |3 +++
1 file changed, 3 insertions(
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 +-
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 the discussion.
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 the
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 standard-compliant
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 standard-co
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 -
>-- 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 th
50 matches
Mail list logo
