Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > Hi Rafael, > >> So the problem is that Yu would like to use this for hibernation encryption >> done entirely in the kernel. > > But why do you

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Sat, May 12, 2018 at 10:43:08AM +0200, Dmitry Vyukov wrote: > On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: > > On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote: > >> On Fri, Feb 2, 2018 at 2:48 PM, syzbot > >>

Re: PBKDF2 support in the linux kernel

On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote: > Hi all, > The request is that, we'd like to generate a symmetric key derived from > user provided passphase(not rely on any third-party library). May I know if > there is a PBKDF2(Password-Based Key Derivation Function 2) support in the >

Re: PBKDF2 support in the linux kernel

Hi Denis, On Fri, May 25, 2018 at 09:48:36AM -0500, Denis Kenzior wrote: > Hi Eric, > > > The solution to the "too many system calls" problem is trivial: just do > > SHA-512 > > in userspace. It's just math; you don't need a system call, any more than > > you > > would call sys_add(1, 1) to

Re: PBKDF2 support in the linux kernel

Hi Eric, The solution to the "too many system calls" problem is trivial: just do SHA-512 in userspace. It's just math; you don't need a system call, any more than you would call sys_add(1, 1) to compute 1 + 1. The CPU instructions that can accelerate SHA-512, such as AVX and ARM CE, are

Re: PBKDF2 support in the linux kernel

On Fri, May 25, 2018 at 12:07:06PM +0200, Tomas Mraz wrote: > > Because having millions of copies of SHA1, MD5, and SHA2 and in > millions of applications is the best thing. > > Now that's something I would call laziness - just copy the code and do > not care about doing the proper decision

Re: PBKDF2 support in the linux kernel

On Thu, 2018-05-24 at 20:42 -0400, Theodore Y. Ts'o wrote: > On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote: > > > > But seriously, how is it a fault of the 'random person on the > > mailing list' > > that AF_ALG exists and is being used for its (seemingly intended) > > purpose? >

Re: PBKDF2 support in the linux kernel

Hi Denis, On Thu, May 24, 2018 at 07:56:50PM -0500, Denis Kenzior wrote: > Hi Ted, > > > > I'm not really here to criticize or judge the past. AF_ALG exists now. It > > > is being used. Can we just make it better? Or are we going to whinge at > > > every user that tries to use (and improve)

Re: PBKDF2 support in the linux kernel

Hi Ted, I'm not really here to criticize or judge the past. AF_ALG exists now. It is being used. Can we just make it better? Or are we going to whinge at every user that tries to use (and improve) kernel features that (some) people disagree with because it can 'compromise' kernel security?

Re: PBKDF2 support in the linux kernel

One more thought about why userspace using AF_ALG is a bad idea --- there is no guarantee that all kernels will have all of the crypto algorithms you need built into the kernel. People who build custom kernels very often only include those kernel modules they need. So by default I don't normally

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote: > > But seriously, how is it a fault of the 'random person on the mailing list' > that AF_ALG exists and is being used for its (seemingly intended) purpose? > > I'm not really here to criticize or judge the past. AF_ALG exists now.

Re: PBKDF2 support in the linux kernel

Hi Ted, On 05/24/2018 06:25 PM, Theodore Y. Ts'o wrote: On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote: Actually for the use case we have, speed is something pretty low on the priority list; not having to deal with userspace crypto library dependencies was a goal in and of

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote: > Actually for the use case we have, speed is something pretty low on the > priority list; not having to deal with userspace crypto library dependencies > was a goal in and of itself. Each one has its own issues and you can never >

Re: PBKDF2 support in the linux kernel

Hi Ted, On 05/24/2018 04:05 PM, Theodore Y. Ts'o wrote: Has anyone actually done the experiment and verified that it was in fact a win to use AF_ALG on at least _some_ platform? What about the common cast for most platforms, even those that had some kind of hardware accleration that could only

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 12:11:35PM -0500, Denis Kenzior wrote: > > Well, I'm not sure where the laziness comment is coming from. We have at > least two user-space implementations that implement PBKDF on top of AF_ALG. > But a typical invocation of PBKDF runs a couple of thousand iterations. >

Re: PBKDF2 support in the linux kernel

Hi Eric, No, we don't add random code to the kernel just because people are lazy. IMO it was a mistake that AF_ALG allows access to software crypto implementations by default (as opposed to just hardware crypto devices), but it's not an excuse to I understand, but my point is, AF_ALG is out

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 09:36:15AM -0500, Denis Kenzior wrote: > Hi Stephan, > > On 05/24/2018 12:57 AM, Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: > > > > Hi Eric, > > > > > > > > "Not having to rely on any third-party library" is not an excuse

Re: PBKDF2 support in the linux kernel

Hi Stephan, On 05/24/2018 12:57 AM, Stephan Mueller wrote: Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: Hi Eric, "Not having to rely on any third-party library" is not an excuse to add random code to the kernel, which runs in a privileged context. Please do PBKDF2 in

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 24, 2018 at 3:20 PM, Gilad Ben-Yossef wrote: > On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven > wrote: >> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef >> wrote: >>> On Thu, May 17, 2018 at 1:16

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef wrote: >> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >> wrote: >>> Indeed. From a quick glance,

Re: PBKDF2 support in the linux kernel

On Thursday, May 24, 2018 11:36:04 AM CEST Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki: > > Hi Rafael, > > > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J.

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki: Hi Rafael, > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > > > Hi Rafael, > > Hi Stephan, > > > > So the problem is that Yu

Re: PBKDF2 support in the linux kernel

On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > Hi Rafael, Hi Stephan, > > So the problem is that Yu would like to use this for hibernation encryption > > done entirely in the kernel. > > But why do

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: Hi Rafael, > So the problem is that Yu would like to use this for hibernation encryption > done entirely in the kernel. But why do you need to perform PBKDF in kernel space? If you retain the password information in the

Re: PBKDF2 support in the linux kernel

On Thursday, May 24, 2018 7:57:37 AM CEST Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: > > Hi Eric, > > > > > "Not having to rely on any third-party library" is not an excuse to add > > random code to the kernel, which runs in a privileged context.

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: Hi Eric, > > "Not having to rely on any third-party library" is not an excuse to add > random code to the kernel, which runs in a privileged context. Please do > PBKDF2 in userspace instead. I second that. Besides, if you really

Re: PBKDF2 support in the linux kernel

Hi Yu, On Thu, May 24, 2018 at 10:26:12AM +0800, Yu Chen wrote: > Hi Stephan, > thanks for your reply, > On Wed, May 23, 2018 at 1:43 AM Stephan Mueller wrote: > > > Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen: > > > Hi Yu, > > > > Hi all, > > > The request

Re: PBKDF2 support in the linux kernel

Hi Stephan, thanks for your reply, On Wed, May 23, 2018 at 1:43 AM Stephan Mueller wrote: > Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen: > Hi Yu, > > Hi all, > > The request is that, we'd like to generate a symmetric key derived from > > user provided

Re: PBKDF2 support in the linux kernel

Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen: Hi Yu, > Hi all, > The request is that, we'd like to generate a symmetric key derived from > user provided passphase(not rely on any third-party library). May I know if > there is a PBKDF2(Password-Based Key Derivation Function 2) support

Re: [PATCH RESEND 1/2] Add DOWNLOAD_FIRMWARE SEV command

On 5/10/2018 12:28 PM, Borislav Petkov wrote: Use a prefix for the subject pls: Subject: [PATCH RESEND 1/2] crypto: ccp: Add DOWNLOAD_FIRMWARE SEV command or Subject: [PATCH RESEND 1/2] crypto/ccp: Add DOWNLOAD_FIRMWARE SEV command or so. Okay. On Wed, May 09, 2018 at 11:18:27AM -0500,

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven > wrote: >> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c >> does not distinguish between the absence

Re: [PATCH] crypto: Mark MORUS SIMD glue as x86-specific

2018-05-18 23:01 GMT+02:00 Ondrej Mosnáček : > From: Ondrej Mosnacek > > Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for > MORUS") accidetally consiedered the glue code to be usable by different > architectures, but it seems to be only

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven wrote: > > Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c > does not distinguish between the absence of the clock property, and an > actual error in getting the clock, and never considers any

Re: [PATCH v2] fscrypt: log the crypto algorithm implementations

On Fri, May 18, 2018 at 10:58:14AM -0700, Eric Biggers wrote: > Log the crypto algorithm driver name for each fscrypt encryption mode on > its first use, also showing a friendly name for the mode. > > This will help people determine whether the expected implementations are > being used. In some

Re: [PATCH v2] fscrypt: add Speck128/256 support

On Mon, May 07, 2018 at 05:22:08PM -0700, Eric Biggers wrote: > fscrypt currently only supports AES encryption. However, many low-end > mobile devices have older CPUs that don't have AES instructions, e.g. > the ARMv8 Cryptography Extensions. Currently, user data on such devices > is not

Re: cryptomgr_test / drbg_ctr: BUG: sleeping function called from invalid context

Am Freitag, 18. Mai 2018, 10:36:04 CEST schrieb Geert Uytterhoeven: Hi Geert, > > I tried following the code path, but couldn't find where it went wrong. > > mutex_lock(>drbg_mutex) is called from drbg_instantiate(), which is > inlined by the compiler into drbg_kcapi_seed(). > > Do you have a

Re: [PATCH 3/3] crypto: x86 - Add optimized AEGIS implementations

2018-05-20 4:41 GMT+02:00 Eric Biggers : > Hi Ondrej, > > On Fri, May 11, 2018 at 02:12:51PM +0200, Ondrej Mosnáček wrote: >> From: Ondrej Mosnacek >> >> This patch adds optimized implementations of AEGIS-128, AEGIS-128L, >> and AEGIS-256, utilizing the

Re: [PATCH 3/3] crypto: x86 - Add optimized AEGIS implementations

Hi Ondrej, On Fri, May 11, 2018 at 02:12:51PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > This patch adds optimized implementations of AEGIS-128, AEGIS-128L, > and AEGIS-256, utilizing the AES-NI and SSE2 x86 extensions. > > Signed-off-by: Ondrej Mosnacek

Re: [PATCH 0/4] Add support for MORUS AEAD algorithm

On Fri, May 11, 2018 at 02:19:08PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > This patchset adds the MORUS AEAD algorithm implementation to the Linux > Crypto API. > > MORUS [1] is a dedicated AEAD algorithm focused on SIMD instructions and > designed for

Re: [PATCH 0/3] Add support for AEGIS AEAD algorithm

On Fri, May 11, 2018 at 02:12:48PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > This patchset adds the AEGIS AEAD algorithm implementation to the Linux > Crypto API. > > AEGIS [1] is a dedicated AEAD algorithm based on the AES round function and > designed

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH] crypto: nx: fix spelling mistake: "seqeunce" -> "sequence"

On Wed, May 09, 2018 at 10:16:36AM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in CSB_ERR error message text > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

Re: [PATCH] crypto: chelsio: request to HW should wrap

On Thu, May 10, 2018 at 10:14:42AM +0530, Atul Gupta wrote: > -Tx request and data is copied to HW Q in 64B desc, check for > end of queue and adjust the current position to start from > beginning before passing the additional request info. > -key context copy should check key length only > -Few

Re: [PATCH] hwrng: n2: fix spelling mistake: "restesting" -> "retesting"

Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_err error message > > Signed-off-by: Colin Ian King Patch applied. Thanks. -- Email: Herbert Xu

Re: [RFC PATCH 5/5] KEYS: add KPP ecdh parser

Hi, Denis, On 05/14/2018 10:54 PM, Denis Kenzior wrote: Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: The ECDH private keys are expected to be encoded with the ecdh helpers from kernel. Use the ecdh helpers to check if the key is valid. If valid, allocate a tfm and set the private

Re: [RFC PATCH 1/5] KEYS: Provide key type operations for kpp ops

Hi, Denis, Thanks for the review! Please see inline. On 05/14/2018 09:48 PM, Denis Kenzior wrote: Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: Provide three new operations in the key_type struct that can be used to provide access to kpp operations. These will be implemented for the

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 04:12:23PM +0300, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 12:04 PM, Simon Horman wrote: > > On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote: > >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: > >>

Re: [PATCH 1/5] random: fix crng_ready() test

On Thu, May 17, 2018 at 08:01:04AM +0200, Christophe LEROY wrote: > > On a powerpc embedded board which has an mpc8xx processor running at 133Mhz, > I now get the startup done in more than 7 minutes instead of 30 seconds. > This is due to the webserver blocking on read on /dev/random until we get

Re: [PATCH 1/5] random: fix crng_ready() test

On Wed, May 16, 2018 at 05:07:08PM -0700, Srivatsa S. Bhat wrote: > > On a Photon OS VM running on VMware ESXi, this patch causes a boot speed > regression of 5 minutes :-( [ The VM doesn't have haveged or rng-tools > (rngd) installed. ] > > [1.420246] EXT4-fs (sda2)

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven > wrote: >> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef >> wrote: >>> On Thu, May 17, 2018 at 1:16 PM,

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: >> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >> wrote: >>> However, even with your clock

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven > wrote: >> However, even with your clock patch, the signature checking fails for me, >> on both R-Car H3 ES1.0 and ES2.0. >> Does

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 12:16 PM, Geert Uytterhoeven wrote: > On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef > wrote: >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 12:04 PM, Simon Horman wrote: > On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote: >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >> > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: >>

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef > wrote: >> On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >>> On Tue, May 15, 2018 at 04:50:44PM

Re: [PATCH 1/3] crypto: ccree: drop signature register check

Herbert, On Tue, May 15, 2018 at 3:29 PM, Gilad Ben-Yossef wrote: > We were using the content of the signature register as a sanity > check for the hardware functioning but it turns out not all > implementers use the same values so the check is giving false > negative on

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef wrote: > On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: >> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: >>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote: > On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: > > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: > >> Hi Gilad, > >> > >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef

Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

Hi Gilad, On Thu, May 17, 2018 at 10:00 AM, Gilad Ben-Yossef wrote: > On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven > wrote: >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef >> wrote: >>> This patch adds the clock used

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, May 11, 2018 at 09:04:06AM +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by:

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Wed, May 16, 2018 at 10:43 AM, Simon Horman wrote: > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: >> Hi Gilad, >> >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef >> wrote: >> > Add bindings for CryptoCell instance in the

Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

On Tue, May 15, 2018 at 5:47 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: >> This patch adds the clock used by the CryptoCell 630p instance in the SoC. >> >> Signed-off-by: Gilad Ben-Yossef

Re: [PATCH 1/5] random: fix crng_ready() test

:17 EDT 2018 [1.282220] random: fast init done [3.987092] random: crng init done [4.376787] EXT4-fs (sda1): re-mounted. Opts: (null) There are some desktops where the "crng_init done" report doesn't happen until 45-90 seconds into the boot. I don't think I've seen reports whe

Re: [PATCH 1/5] random: fix crng_ready() test

(gcc version 7.3.0 (Debian 7.3.0-15)) #16 SMP Thu Apr 12 16:57:17 EDT 2018 > [1.282220] random: fast init done > [3.987092] random: crng init done > [4.376787] EXT4-fs (sda1): re-mounted. Opts: (null) > > There are some desktops where the "crng_init done" report d

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote: > Hi Gilad, > > On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: > > Add bindings for CryptoCell instance in the SoC. > > > > Signed-off-by: Gilad Ben-Yossef > > Thanks for

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: > Add bindings for CryptoCell instance in the SoC. > > Signed-off-by: Gilad Ben-Yossef Thanks for your patch! > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi > +++

Re: [PATCH 2/3] clk: renesas: r8a7795: Add ccree clock

Hi Gilad, On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef wrote: > This patch adds the clock used by the CryptoCell 630p instance in the SoC. > > Signed-off-by: Gilad Ben-Yossef Thanks for your patch! > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c >

Re: [PATCH] crypto: reorder paes test lexicographically

On Fri, 2018-05-11 at 09:04 +0100, Gilad Ben-Yossef wrote: > Due to a snafu "paes" testmgr tests were not ordered > lexicographically, which led to boot time warnings. > Reorder the tests as needed. > > Fixes: a794d8d ("crypto: ccree - enable support for hardware keys") > Reported-by: Abdul

Re: [RFC PATCH 5/5] KEYS: add KPP ecdh parser

Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: The ECDH private keys are expected to be encoded with the ecdh helpers from kernel. Use the ecdh helpers to check if the key is valid. If valid, allocate a tfm and set the private key. There is a one-to-one binding between the private key

Re: [RFC PATCH 1/5] KEYS: Provide key type operations for kpp ops

Hi Tudor, On 02/28/2018 10:52 AM, Tudor Ambarus wrote: Provide three new operations in the key_type struct that can be used to provide access to kpp operations. These will be implemented for the asymmetric key type in a later patch and may refer to a key retained in RAM by the kernel or a key

Re: [PATCH 2/5] crypto: chtls: wait for memory sendmsg, sendpage

Hi Atul, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on cryptodev/master] [also build test WARNING on v4.17-rc5 next-20180514] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Sat, May 12, 2018 at 12:11:17PM +0200, Ard Biesheuvel wrote: > On 12 May 2018 at 11:50, Dmitry Vyukov wrote: > > On Sat, May 12, 2018 at 11:09 AM, Ard Biesheuvel > > wrote: > >> (+ Arnd) > >> > >> On 12 May 2018 at 10:43, Dmitry Vyukov

Re: [PATCH 2/5] crypto: chtls: wait for memory sendmsg, sendpage

On Mon, May 14, 2018 at 04:30:56PM +0530, Atul Gupta wrote: > Reported-by: Gustavo A. R. Silva > Signed-off-by: Atul Gupta There isn't a commit message for this. It should say what the user visible effects of this bug are. I haven't seen

Re: [PATCH 1/2] crypto: vmx - Remove overly verbose printk from AES init routines

Herbert Xu writes: > On Thu, May 03, 2018 at 10:29:29PM +1000, Michael Ellerman wrote: >> In the vmx AES init routines we do a printk(KERN_INFO ...) to report >> the fallback implementation we're using. >> >> However with a slow console this can significantly affect

Re: [RFC PATCH 0/5] KEYS: add kpp keyctl operations

ping again. On 04/11/2018 02:08 PM, Tudor Ambarus wrote: Hi, There was a long discussion about which interface to chose to export akcipher and kpp to user-space. This series came as an alternative to what Stephan proposed for af_alg[1]. I would like some feedback before diving into tpm. Best,

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On 12 May 2018 at 11:50, Dmitry Vyukov wrote: > On Sat, May 12, 2018 at 11:09 AM, Ard Biesheuvel > wrote: >> (+ Arnd) >> >> On 12 May 2018 at 10:43, Dmitry Vyukov wrote: >>> On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Sat, May 12, 2018 at 11:09 AM, Ard Biesheuvel wrote: > (+ Arnd) > > On 12 May 2018 at 10:43, Dmitry Vyukov wrote: >> On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: >>> On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry

Re: WARNING: kernel stack regs has bad 'bp' value (3)

(+ Arnd) On 12 May 2018 at 10:43, Dmitry Vyukov wrote: > On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: >> On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote: >>> On Fri, Feb 2, 2018 at 2:48 PM, syzbot >>>

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: > On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote: >> On Fri, Feb 2, 2018 at 2:48 PM, syzbot >> wrote: >> > Hello, >> > >> > syzbot hit the following

RE: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

>-Original Message- >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] >Sent: Thursday, May 10, 2018 9:46 PM >To: Dey, Megha <megha@intel.com> >Cc: linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org; >da...@davemloft.net >Subject: Re: [PATCH V

RE: [PATCH v2 1/7] crypto: chtls: wait for memory sendmsg, sendpage

To: Atul Gupta <atul.gu...@chelsio.com> Cc: linux-crypto@vger.kernel.org; gust...@embeddedor.com Subject: Re: [PATCH v2 1/7] crypto: chtls: wait for memory sendmsg, sendpage On Wed, May 02, 2018 at 12:25:33AM +0530, Atul Gupta wrote: > Reported-by: Gustavo A. R. Silva <gust...@em

Re: [PATCH 1/2] crypto: vmx - Remove overly verbose printk from AES init routines

On Thu, May 03, 2018 at 10:29:29PM +1000, Michael Ellerman wrote: > In the vmx AES init routines we do a printk(KERN_INFO ...) to report > the fallback implementation we're using. > > However with a slow console this can significantly affect the speed of > crypto operations. Using 'cryptsetup

Re: [PATCH resend 00/10] crypto: arm64 - play nice with CONFIG_PREEMPT

On Mon, Apr 30, 2018 at 06:18:20PM +0200, Ard Biesheuvel wrote: > Hello Herbert, > > These are the patches that depend on the arm64/assembler.h patches that > inadvertently got pulled into the cryptodev tree and reverted shortly > after. Those have now been merged into Linus's tree, and so the >

Re: [PATCH v2 1/7] crypto: chtls: wait for memory sendmsg, sendpage

On Wed, May 02, 2018 at 12:25:33AM +0530, Atul Gupta wrote: > Reported-by: Gustavo A. R. Silva > Signed-off-by: Atul Gupta These patches really should be sent to netdev as well and I'd like to see some acks from there. Also please add a cover

Re: [next-20180509][bisected a794d8d] ppc boot warnings at crypto/testmgr.c:3720

On Fri, May 11, 2018 at 9:59 AM, Abdul Haleem wrote: > Greeting's > > Today's next kernel on powerpc machine has boot warnings with commit > > a794d8d : crypto: ccree - enable support for hardware keys Adding the crypto list and maintainer as it came in via the

Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

On Fri, May 11, 2018 at 01:24:42AM +, Dey, Megha wrote: > > Are you suggesting that the SIMD wrapper, will do what is currently being > done by the ' mcryptd_queue_worker ' function (assuming FPU is not disabled) > i.e dispatching the job to the inner algorithm? > > I have got rid of the

RE: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

>-Original Message- >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] >Sent: Monday, May 7, 2018 2:35 AM >To: Dey, Megha <megha@intel.com> >Cc: linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org; >da...@davemloft.net >Subject: Re: [PATCH V

Re: [PATCH v2] async_pq: Remove VLA usage

On Sat, May 5, 2018 at 12:58 AM, Kyle Spiers wrote: > In the quest to remove VLAs from the kernel[1], this moves the > allocation of coefs and blocks from the stack to being kmalloc()ed. > > [1] https://lkml.org/lkml/2018/3/7/621 > > Signed-off-by: Kyle Spiers

Re: DMA map buffer allocated in ahash_request_ctx

On Wed, May 9, 2018 at 8:37 PM, Herbert Xu wrote: > On Wed, May 09, 2018 at 04:13:12PM +0300, Gilad Ben-Yossef wrote: >> On Wed, May 9, 2018 at 3:12 PM, Harsh Jain wrote: >> > Hi Herbert, >> > >> > Can we use buffer defined in ahash request

Re: DMA map buffer allocated in ahash_request_ctx

On Wed, May 09, 2018 at 04:13:12PM +0300, Gilad Ben-Yossef wrote: > On Wed, May 9, 2018 at 3:12 PM, Harsh Jain wrote: > > Hi Herbert, > > > > Can we use buffer defined in ahash request context(private space for > > each request) to DMA map it to H/W.? > > Not Herbert

Re: DMA map buffer allocated in ahash_request_ctx

On Wed, May 9, 2018 at 3:12 PM, Harsh Jain wrote: > Hi Herbert, > > Can we use buffer defined in ahash request context(private space for > each request) to DMA map it to H/W.? Not Herbert but... the ccree driver is doing just and Herbert specifically indicated ahash

Re: [PATCH v15 net-next 00/12] Chelsio Inline TLS

hen there is a routing change that redirects traffic to a > different netdev? Is there a software fallback? The case we think is handling the next hop change, is there any other case? > > 5. The TLS socket option is set in the middle of a TCP connection. What > happens to the existing TCP c

Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx

On Tue, May 08, 2018 at 10:13:42AM -0600, Jonathan Corbet wrote: > On Mon, 7 May 2018 06:35:36 -0300 > Mauro Carvalho Chehab wrote: > > > I decided to give a try with Sphinx last stable version > > (1.17.4), and noticed several issues. The worse one was > > with the

Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx

On Mon, 7 May 2018 06:35:36 -0300 Mauro Carvalho Chehab wrote: > I decided to give a try with Sphinx last stable version > (1.17.4), and noticed several issues. The worse one was > with the networking book: a non-standard footnote there > with [*] instead of a number

Re: [PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst

On Mon, 7 May 2018 06:35:39 -0300 Mauro Carvalho Chehab wrote: > A number of new docs were added, but they're currently not on > the index.rst from the session they're supposed to be, causing > Sphinx warnings. > > Add them. > > Signed-off-by: Mauro Carvalho Chehab

Re: [PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst

On Mon, May 07, 2018 at 06:35:39AM -0300, Mauro Carvalho Chehab wrote: > A number of new docs were added, but they're currently not on > the index.rst from the session they're supposed to be, causing > Sphinx warnings. > > Add them. > > Signed-off-by: Mauro Carvalho Chehab

Re: [PATCH v2 0/5] crypto: Speck support

Hi Samuel, On Thu, Apr 26, 2018 at 03:05:44AM +0100, Samuel Neves wrote: > On Wed, Apr 25, 2018 at 8:49 PM, Eric Biggers wrote: > > I agree that my explanation should have been better, and should have > > considered > > more crypto algorithms. The main difficulty is that

Re: IV generation

On Mon, May 7, 2018 at 2:29 PM, Stephan Mueller wrote: > Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> ah... so if I have hardware that can implement say, seqiv, I can >> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are >>

Re: IV generation

Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > ah... so if I have hardware that can implement say, seqiv, I can > register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are > right, it will be used? That is the question I cannot fully answer. Seqiv is a

Re: IV generation

On Mon, May 7, 2018 at 2:02 PM, Stephan Mueller wrote: > Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef: > > Hi Gilad, > >> Hi, >> >> A quick question: am I correct in my understanding that there is now >> no automatic IV generation support for either skcipher

<    1   2   3   4   5   6   7   8   9   10   >