Re: [PATCH] crypto: cavium/zip - fix collision with generic cra_driver_name

2019-02-25 Thread Jan Glauber
On Sat, Feb 23, 2019 at 12:23:23AM -0800, Eric Biggers wrote: > From: Eric Biggers > > The cavium/zip implementation of the deflate compression algorithm is > incorrectly being registered under the generic driver name, which > prevents the generic implementation from being registered with the > c

Re: general protection fault in gcmaes_crypt_by_sg

2019-02-25 Thread Eric Biggers
On Wed, Feb 20, 2019 at 05:03:38PM +0100, 'Dmitry Vyukov' via syzkaller-bugs wrote: > On Mon, Oct 8, 2018 at 12:06 PM Ard Biesheuvel > wrote: > > > > (add the TLS maintainers) > > > > On 6 October 2018 at 15:04, syzbot > > wrote: > > > Hello, > > > > > > syzbot found the following crash on: > >

Re: [PATCH v5 10/10] integrity: support EC-RDSA signatures for asymmetric_verify

2019-02-25 Thread Vitaly Chikunov
Thiago, On Mon, Feb 25, 2019 at 06:20:49PM -0300, Thiago Jung Bauermann wrote: > Vitaly Chikunov writes: > > > Allow to use EC-RDSA signatures for IMA by determining signature type by > > the hash algorithm name. This works good for EC-RDSA since Streebog and > > EC-RDSA should always be used to

Re: [PATCH] crypto: ccp: introduce SEV_GET_ID2 command

2019-02-25 Thread Singh, Brijesh
On 2/21/19 10:37 PM, Herbert Xu wrote: > On Thu, Feb 14, 2019 at 07:33:29PM +, Singh, Brijesh wrote: >> >> >> On 2/14/19 10:57 AM, Nathaniel McCallum wrote: >>> I'm a little concerned that this immediately disables SEV_GET_ID. >>> IMHO, we should continue to support both for a period of time.

Re: [PATCH v5 10/10] integrity: support EC-RDSA signatures for asymmetric_verify

2019-02-25 Thread Thiago Jung Bauermann
Hello Vitaly, Vitaly Chikunov writes: > Allow to use EC-RDSA signatures for IMA by determining signature type by > the hash algorithm name. This works good for EC-RDSA since Streebog and > EC-RDSA should always be used together. > > Cc: Mimi Zohar > Cc: Dmitry Kasatkin > Cc: linux-integr...@

Re: [RFC 0/4] crypto: caam - Add i.MX8MQ support

2019-02-25 Thread Chris Spencer
On Mon, 25 Feb 2019 at 14:17, Chris Spencer wrote: > On Mon, 25 Feb 2019 at 14:03, Horia Geanta wrote: > > The code looks *very* similar to what was developed by NXP. > > Why have you stripped off the S-O-Bs? > > Hi Horia, > > Apologies, I was struggling to find any guidance about what to do with

Re: [RFC 4/4] crypto: caam - use job ring for RNG instantiation instead of DECO

2019-02-25 Thread Chris Spencer
On Mon, 25 Feb 2019 at 14:22, Horia Geanta wrote: > > On 2/22/2019 12:07 PM, spence...@gmail.com wrote: > > From: Chris Spencer > > > > This is required to support the i.MX8. > > > Why exactly is this required? > You should provide more details. I don't know. :) These changes were made in [1], a

Re: [RFC 4/4] crypto: caam - use job ring for RNG instantiation instead of DECO

2019-02-25 Thread Horia Geanta
On 2/22/2019 12:07 PM, spence...@gmail.com wrote: > From: Chris Spencer > > This is required to support the i.MX8. > Why exactly is this required? You should provide more details. Strictly related to the implementation, why is the code moved to a new file? Please do not shuffle the code without

Re: [RFC 0/4] crypto: caam - Add i.MX8MQ support

2019-02-25 Thread Chris Spencer
On Mon, 25 Feb 2019 at 14:03, Horia Geanta wrote: > The code looks *very* similar to what was developed by NXP. > Why have you stripped off the S-O-Bs? Hi Horia, Apologies, I was struggling to find any guidance about what to do with the tags when upstreaming changes. I will add them in the next

Re: [RFC 0/4] crypto: caam - Add i.MX8MQ support

2019-02-25 Thread Horia Geanta
On 2/22/2019 12:07 PM, spence...@gmail.com wrote: > From: Chris Spencer > > This patch series adds support for the i.MX8MQ to the CAAM driver. This > is mostly adapted from corresponding changes in the NXP repo. The > patches are based on v5.0-rc7. > The code looks *very* similar to what was dev

Re: [PATCH v7 07/28] x86/asm/crypto: annotate local functions

2019-02-25 Thread Borislav Petkov
On Wed, Jan 30, 2019 at 01:46:50PM +0100, Jiri Slaby wrote: > Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all > functions which do not have ".globl" annotation, but their ends are > annotated by ENDPROC. This is needed to balance ENDPROC for tools that > generate debuginfo. > >