Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

On 8 December 2017 at 02:51, Jason A. Donenfeld wrote: > Hi Eric, > > Nice to see more use of ChaCha20. However... > > Can we skip over the "sort of worse than XTS, but not having _real_ > authentication sucks anyway in either case, so whatever" and move > directly to, "linux

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

Hi Eric, Nice to see more use of ChaCha20. However... Can we skip over the "sort of worse than XTS, but not having _real_ authentication sucks anyway in either case, so whatever" and move directly to, "linux finally supports authenticated encryption for disk encryption!"? This would be a big

Re: [PATCH 8/8] net: tipc: remove unused hardirq.h

On 11/18/2017 07:02 AM, Yang Shi wrote: > Preempt counter APIs have been split out, currently, hardirq.h just > includes irq_enter/exit APIs which are not used by TIPC at all. > > So, remove the unused hardirq.h. > > Signed-off-by: Yang Shi > Cc: Jon Maloy

[PATCH] fscrypt: add support for ChaCha20 contents encryption

From: Eric Biggers fscrypt currently only supports AES encryption. However, many low-end mobile devices still use older CPUs such as ARMv7, which do not support the AES instructions (the ARMv8 Cryptography Extensions). This results in very poor AES performance, even if the

Re: [Part2 PATCH v9 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support

On Thu, Dec 7, 2017 at 9:21 PM, Brijesh Singh wrote: > > > On 12/06/2017 03:10 PM, Philippe Ombredanne wrote:>> diff --git > a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c >>> >>> new file mode 100644 >>> index ..b5789f878560 >>> --- /dev/null >>>

Re: [Part2 PATCH v9 12/38] crypto: ccp: Add Platform Security Processor (PSP) device support

On 12/06/2017 03:10 PM, Philippe Ombredanne wrote:>> diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c new file mode 100644 index ..b5789f878560 --- /dev/null +++ b/drivers/crypto/ccp/psp-dev.c @@ -0,0 +1,105 @@ +/* + * AMD Platform Security Processor (PSP)

Re: [PATCH 8/8] net: tipc: remove unused hardirq.h

On 12/7/17 11:20 AM, Jon Maloy wrote: -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev- ow...@vger.kernel.org] On Behalf Of Yang Shi Sent: Thursday, December 07, 2017 14:16 To: linux-ker...@vger.kernel.org Cc: linux...@kvack.org; linux-fsde...@vger.kernel.org;

RE: [PATCH 8/8] net: tipc: remove unused hardirq.h

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Yang Shi > Sent: Thursday, December 07, 2017 14:16 > To: linux-ker...@vger.kernel.org > Cc: linux...@kvack.org; linux-fsde...@vger.kernel.org; linux- > cry...@vger.kernel.org;

Re: [ovs-dev] [PATCH 7/8] net: ovs: remove unused hardirq.h

On Fri, Nov 17, 2017 at 3:02 PM, Yang Shi wrote: > Preempt counter APIs have been split out, currently, hardirq.h just > includes irq_enter/exit APIs which are not used by openvswitch at all. > > So, remove the unused hardirq.h. > > Signed-off-by: Yang Shi

Re: [PATCH 4/8] vfs: remove unused hardirq.h

On Fri, Dec 08, 2017 at 03:12:52AM +0800, Yang Shi wrote: > Hi folks, > > Any comment on this one? Applied

Re: [PATCH 8/8] net: tipc: remove unused hardirq.h

Hi folks, Any comment on this one? Thanks, Yang On 11/17/17 3:02 PM, Yang Shi wrote: Preempt counter APIs have been split out, currently, hardirq.h just includes irq_enter/exit APIs which are not used by TIPC at all. So, remove the unused hardirq.h. Signed-off-by: Yang Shi

Re: [PATCH 7/8] net: ovs: remove unused hardirq.h

Hi folks, Any comment on this one? Thanks, Yang On 11/17/17 5:48 PM, Yang Shi wrote: It looks the email address of Pravin in MAINTAINERS file is obsolete, sent to the right address. Yang On 11/17/17 3:02 PM, Yang Shi wrote: Preempt counter APIs have been split out, currently, hardirq.h

Re: [PATCH 6/8] net: caif: remove unused hardirq.h

Hi folks, Any comment on this one? Thanks, Yang On 11/17/17 3:02 PM, Yang Shi wrote: Preempt counter APIs have been split out, currently, hardirq.h just includes irq_enter/exit APIs which are not used by caif at all. So, remove the unused hardirq.h. Signed-off-by: Yang Shi

Re: [PATCH 4/8] vfs: remove unused hardirq.h

Hi folks, Any comment on this one? Thanks, Yang On 11/17/17 3:02 PM, Yang Shi wrote: Preempt counter APIs have been split out, currently, hardirq.h just includes irq_enter/exit APIs which are not used by vfs at all. So, remove the unused hardirq.h. Signed-off-by: Yang Shi

[PATCH] crypto: null - Get rid of crypto_{get,put}_default_null_skcipher2()

From: Eric Biggers Since commit 499a66e6b689 ("crypto: null - Remove default null blkcipher"), crypto_get_default_null_skcipher2() and crypto_put_default_null_skcipher2() are the same as their non-2 equivalents. So switch callers of the "2" versions over to the original

[PATCH] crypto: api - Unexport crypto_larval_lookup()

From: Eric Biggers crypto_larval_lookup() is not used outside of crypto/api.c, so unexport it and mark it 'static'. Signed-off-by: Eric Biggers --- crypto/api.c | 4 ++-- crypto/internal.h | 1 - 2 files changed, 2 insertions(+), 3 deletions(-)

Re: [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

On 7 December 2017 at 14:50, Ard Biesheuvel wrote: > On 7 December 2017 at 14:39, Dave Martin wrote: >> On Wed, Dec 06, 2017 at 07:43:37PM +, Ard Biesheuvel wrote: >>> Add support macros to conditionally yield the NEON (and thus the CPU) >>>

Re: [crypto 4/8] chtls: CPL handler definition

Hi Atul, On Thu, 7 Dec 2017 14:50:37 + Atul Gupta wrote: > -Original Message- > From: linux-crypto-ow...@vger.kernel.org > [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Stefano Brivio > Sent: Tuesday, December 5, 2017 8:54 PM > To: Atul Gupta

Re: [PATCH v9 1/8] drm/tilcdc: ensure nonatomic iowrite64 is not used

On 12/06/17 01:30, Logan Gunthorpe wrote: > Add a check to ensure iowrite64 is only used if it is atomic. > > It was decided in [1] that the tilcdc driver should not be using an > atomic operation (so it was left out of this patchset). However, it turns > out that through the drm code, a

Re: [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

On Thu, Dec 07, 2017 at 03:47:43PM +, Ard Biesheuvel wrote: > On 7 December 2017 at 14:50, Ard Biesheuvel wrote: > > On 7 December 2017 at 14:39, Dave Martin wrote: > >> On Wed, Dec 06, 2017 at 07:43:37PM +, Ard Biesheuvel wrote: [...] >

Re: [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

On Thu, Dec 07, 2017 at 02:50:11PM +, Ard Biesheuvel wrote: > On 7 December 2017 at 14:39, Dave Martin wrote: > > On Wed, Dec 06, 2017 at 07:43:37PM +, Ard Biesheuvel wrote: > >> Add support macros to conditionally yield the NEON (and thus the CPU) > >> that may be

Re: [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

On 7 December 2017 at 15:47, Ard Biesheuvel wrote: > On 7 December 2017 at 14:50, Ard Biesheuvel wrote: >> On 7 December 2017 at 14:39, Dave Martin wrote: >>> On Wed, Dec 06, 2017 at 07:43:37PM +, Ard Biesheuvel

Re: [crypto 6/8] chtls: TCB and Key program

Am Donnerstag, 7. Dezember 2017, 16:08:04 CET schrieb Atul Gupta: Hi Atul, > > As far as I see, the key is part of the skb (via kctx). This skb is > > released after being processed. The release calls kfree_skb which does > > not zeroize the key. Wouldn't it make sense to clear the memory of the

RE: [crypto 6/8] chtls: TCB and Key program

-Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Stephan Mueller Sent: Thursday, December 7, 2017 8:13 PM To: Atul Gupta Cc: herb...@gondor.apana.org.au; linux-crypto@vger.kernel.org;

Re: [PATCH v3 10/20] arm64: assembler: add utility macros to push/pop stack frames

On 7 December 2017 at 14:53, Dave Martin wrote: > On Thu, Dec 07, 2017 at 02:21:17PM +, Ard Biesheuvel wrote: >> On 7 December 2017 at 14:11, Dave Martin wrote: >> > On Wed, Dec 06, 2017 at 07:43:36PM +, Ard Biesheuvel wrote: >> >> We are going

Re: [PATCH v3 10/20] arm64: assembler: add utility macros to push/pop stack frames

On Thu, Dec 07, 2017 at 02:21:17PM +, Ard Biesheuvel wrote: > On 7 December 2017 at 14:11, Dave Martin wrote: > > On Wed, Dec 06, 2017 at 07:43:36PM +, Ard Biesheuvel wrote: > >> We are going to add code to all the NEON crypto routines that will > >> turn them into

RE: [crypto 4/8] chtls: CPL handler definition

-Original Message- From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-ow...@vger.kernel.org] On Behalf Of Stefano Brivio Sent: Tuesday, December 5, 2017 8:54 PM To: Atul Gupta Cc: herb...@gondor.apana.org.au; linux-crypto@vger.kernel.org;

Re: [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

On 7 December 2017 at 14:39, Dave Martin wrote: > On Wed, Dec 06, 2017 at 07:43:37PM +, Ard Biesheuvel wrote: >> Add support macros to conditionally yield the NEON (and thus the CPU) >> that may be called from the assembler code. >> >> In some cases, yielding the NEON

Re: [crypto 6/8] chtls: TCB and Key program

Am Donnerstag, 7. Dezember 2017, 15:21:03 CET schrieb Atul Gupta: Hi Atul, > > memzero_explicit(key)? > [Atul] may not be required as entire info of size keylen and AEAD_H_SIZE is > copied onto kctx->key. Key data is received from user, while ghash is > memset and locally generated Sure, but

Re: [PATCH v3 11/20] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

On Wed, Dec 06, 2017 at 07:43:37PM +, Ard Biesheuvel wrote: > Add support macros to conditionally yield the NEON (and thus the CPU) > that may be called from the assembler code. > > In some cases, yielding the NEON involves saving and restoring a non > trivial amount of context (especially in

RE: [crypto 6/8] chtls: TCB and Key program

-Original Message- From: Stephan Mueller [mailto:smuel...@chronox.de] Sent: Tuesday, December 5, 2017 6:37 PM To: Atul Gupta Cc: herb...@gondor.apana.org.au; linux-crypto@vger.kernel.org; net...@vger.kernel.org; da...@davemloft.net; davejwat...@fb.com; Ganesh

Re: [PATCH v3 10/20] arm64: assembler: add utility macros to push/pop stack frames

On 7 December 2017 at 14:11, Dave Martin wrote: > On Wed, Dec 06, 2017 at 07:43:36PM +, Ard Biesheuvel wrote: >> We are going to add code to all the NEON crypto routines that will >> turn them into non-leaf functions, so we need to manage the stack >> frames. To make this

Re: [PATCH v3 10/20] arm64: assembler: add utility macros to push/pop stack frames

On Wed, Dec 06, 2017 at 07:43:36PM +, Ard Biesheuvel wrote: > We are going to add code to all the NEON crypto routines that will > turn them into non-leaf functions, so we need to manage the stack > frames. To make this less tedious and error prone, add some macros > that take the number of

Re: [PATCH] Fix NULL pointer deref. on no default_rng

On Wednesday, November 29, 2017 5:34:30 PM CET you wrote: > On Sun, Nov 12, 2017 at 03:24:32PM +0100, Pierre Ducroquet wrote: > > If crypto_get_default_rng returns an error, the > > function ecc_gen_privkey should return an error. > > Instead, it currently tries to use the default_rng > >

Re: [PATCH RFC 0/4] crypto: engine - Permit to enqueue all async requests

On Wed, Dec 06, 2017 at 10:59:47AM +, Fabien DESSENNE wrote: > Hi Corentin, > > > I am fine with this proposal: it is generic enough and I have been able > to test and run the crypto engine with aead_request without changing any > single line of code. > > This is what I need to be able to

Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests

On Wed, Dec 06, 2017 at 11:02:23AM +, Fabien DESSENNE wrote: > > > On 29/11/17 09:41, Corentin Labbe wrote: > > The crypto engine could actually only enqueue hash and ablkcipher request. > > This patch permit it to enqueue any type of crypto_async_request. > > > > Signed-off-by: Corentin

Re: [PATCH 1/3] crypto: exynos - Support Exynos5250+ SoCs

It was <2017-12-06 śro 16:28>, when Krzysztof Kozlowski wrote: > On Wed, Dec 6, 2017 at 3:53 PM, Łukasz Stelmach > wrote: >> It was <2017-12-06 śro 15:05>, when Krzysztof Kozlowski wrote: >>> On Wed, Dec 6, 2017 at 2:42 PM, Łukasz Stelmach >>>

Re: [PATCH 01/10] staging: ccree: remove inline qualifiers

On Thu, Dec 07, 2017 at 09:00:11AM +0200, Gilad Ben-Yossef wrote: > On Mon, Dec 4, 2017 at 11:36 AM, Dan Carpenter > wrote: > > On Sun, Dec 03, 2017 at 01:58:12PM +, Gilad Ben-Yossef wrote: > >> The ccree drivers was marking a lot of big functions in C file as > >>