On Mon, Jul 24, 2017 at 09:07:30AM +0200, Lars Persson wrote:
> From: Rabin Vincent
>
> There are already helpers to (un)register multiple normal
> and AEAD algos. Add one for ahashes too.
>
> Signed-off-by: Lars Persson
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.
On Sun, Jul 23, 2017 at 07:49:04PM +0200, Martin Kaiser wrote:
> From: Steffen Trumtrar
>
> Add binding documentation for the Freescale RNGC found on
> some i.MX2/3 SoCs.
>
> Signed-off-by: Steffen Trumtrar
> Signed-off-by: Martin Kaiser
Patch applied. Thanks.
--
Email: Herbert Xu
Home Pag
On Mon, Jul 24, 2017 at 09:23:12AM +0800, zain wang wrote:
> These patches fix some bugs on rockchip's crypto which would cause crypto
> failed.
>
> zain wang (2):
> crypto: rockchip - move the crypto completion from interrupt context
> crypto: rockchip - return the err code when unable deque
On Tue, Jul 25, 2017 at 02:21:12PM -0500, Gary R Hook wrote:
> The following series adds support for XS-AES on version 5 CCPs, both
> 128- and 256-bit, and enhances/clarifies/simplifies some crypto layer
> code.
>
> Changes since v2:
> - Move a CCP v5 fix out of this patch series and submit indep
On Mon, Jul 24, 2017 at 09:07:31AM +0200, Lars Persson wrote:
> This is an asynchronous crypto API driver for the accelerator present
> in the ARTPEC-6 and -7 SoCs from Axis Communications AB.
>
> The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash
> standards.
>
> Signed-off-by:
On Tue, Jul 25, 2017 at 02:12:11PM -0500, Gary R Hook wrote:
> Version 5 CCPs have some new requirements for XTS-AES: the type field
> must be specified, and the key requires 512 bits, with each part
> occupying 256 bits and padded with zeroes.
>
> cc: # 4.9.x+
>
> Signed-off-by: Gary R Hook
P
On Mon, Jul 24, 2017 at 11:28:02AM +0100, Ard Biesheuvel wrote:
> This is a resend of all the patches I sent out recently that I would
> like to be considered for v4.14. Their main purpose is to prepare the
> arm64 crypto code to deal with situations where the SIMD register file
> is unavailable, w
On Mon, Jul 24, 2017 at 09:07:32AM +0200, Lars Persson wrote:
> Assign the Axis kernel team as maintainer for crypto drivers under
> drivers/crypto/axis.
>
> Signed-off-by: Lars Persson
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http:/
On Sun, Jul 23, 2017 at 07:49:06PM +0200, Martin Kaiser wrote:
> The driver is ported from Freescale's Linux git and can be
> found in the
>
> vendor/freescale/imx_2.6.35_maintain
>
> branch.
>
> The driver supports both RNG version C that's part of some Freescale
> i.MX3 SoCs and version
PrasannaKumar Muralidharan wrote:
> Modify Kconfig help text to reflect the fact that random data from hwrng
> is fed into kernel random number generator's entropy pool.
>
> Signed-off-by: PrasannaKumar Muralidharan
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.o
On Fri, Jul 21, 2017 at 04:42:35PM +0100, Ard Biesheuvel wrote:
> This is a followup to 'crypto: scompress - eliminate percpu scratch buffers',
> which attempted to replace the scompress per-CPU buffer entirely, but as
> Herbert pointed out, this is not going to fly in the targeted use cases.
>
>
On Fri, Jul 21, 2017 at 11:17:39AM +0530, Raveendra Padasalagi wrote:
> Enhance code to generically support cases where DMA rings
> are greater than or equal to number of SPU engines.
> New hardware has underlying DMA engine-FlexRM with 32 rings
> which can be used to communicate to any of the avai
On Thu, Jul 20, 2017 at 04:35:49PM +0300, Tudor Ambarus wrote:
> static checker warning:
> drivers/crypto/atmel-ecc.c:281 atmel_ecdh_done()
> warn: assigning (-22) to unsigned variable 'status'
>
> Similar warning can be raised in atmel_ecc_work_handler()
> when atmel_ecc_send_rece
On Wed, Jul 19, 2017 at 10:29:08PM -0500, Brijesh Singh wrote:
> commit 720419f01832 ("crypto: ccp - Introduce the AMD Secure Processor
> device")
> moved the module registeration from ccp-dev.c to sp-dev.c but patch missed
> removing the module version and author entry from ccp-dev.c.
>
> It cau
On Wed, Jul 19, 2017 at 07:40:32PM +0300, Horia Geantă wrote:
> Remove xts(aes) speed tests with 2 x 192-bit keys, since implementations
> adhering strictly to IEEE 1619-2007 standard cannot cope with key sizes
> other than 2 x 128, 2 x 256 bits - i.e. AES-XTS-{128,256}:
> [...]
> tcrypt: test 5 (3
On Thu, Jul 20, 2017 at 10:37:39AM +0300, Tudor Ambarus wrote:
> ecdh_ctx contained static allocated data for the shared secret
> and public key.
>
> The shared secret and the public key were doomed to concurrency
> issues because they could be shared by multiple crypto requests.
>
> The concurre
On Wed, Jul 19, 2017 at 10:24:15AM +0100, Colin King wrote:
> From: Colin Ian King
>
> Functions atmel_ecc_i2c_client_alloc and atmel_ecc_i2c_client_free are
> local to the source and no not need to be in the global scope. Make
> them static.
>
> Cleans up sparse warnings:
> symbol 'atmel_ecc_i2
Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable tdes_dd. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
>
> This issue was detected using Cocci
Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable sha_dd. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
>
> This issue was detected using Coccin
Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable hdev. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
>
> This issue was detected using Coccinel
Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variable dd. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
>
> This issue was detected using Coccinelle
On Tue, Jul 18, 2017 at 04:42:56PM -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
>
> Signed-off-by: Rob Herring
> Cc: Herbert Xu
> Cc:
On Wed, Jul 19, 2017 at 11:02:31AM +0200, Antoine Tenart wrote:
> A check is performed on the ipad/opad in the safexcel_hmac_sha1_setkey
> function, but the index used by the loop doing it is wrong. It is
> currently the size of the state array while it should be the size of a
> sha1 state. This pa
On Wed, Jul 19, 2017 at 11:02:30AM +0200, Antoine Tenart wrote:
> The safexcel_hmac_sha1_setkey function checks if an invalidation command
> should be issued, i.e. when the context ipad/opad change. This checks is
> done after filling the ipad/opad which and it can't be true. The patch
> fixes this
On Tue, Jul 18, 2017 at 06:30:47PM +0300, Horia Geantă wrote:
> Add support for using the caam/jr backend on DPAA2-based SoCs.
> These have some particularities we have to account for:
> -HW S/G format is different
> -Management Complex (MC) firmware initializes / manages (partially)
> the CAAM blo
On Fri, Jul 21, 2017 at 09:57:39PM -0700, Haren Myneni wrote:
>
> Configure CRB is moved to nx842_configure_crb() so that it can
> be used for icswx and VAS exec functions. VAS function will be
> added later with P9 support.
>
> Signed-off-by: Haren Myneni
Your patch does not apply against cryp
On Mon, Jul 17, 2017 at 11:27:36AM +0300, Cosar Dindar wrote:
> This patch adds CRC (CRC32 Crypto) support for STM32F4 series.
>
> As an hardware limitation polynomial and key setting are not supported.
> They are fixed as 0x4C11DB7 (poly) and 0x (key).
> CRC32C Castagnoli algorithm is not
On Tue, Jul 25, 2017 at 07:09:58PM -0700, Megha Dey wrote:
>
> +/* notify the caller of progress ; request still stays in queue */
> +
> +static void notify_callback(struct mcryptd_skcipher_request_ctx *rctx,
> + struct mcryptd_alg_cstate *cstate,
> +
On Wed, Aug 02, 2017 at 03:46:16PM +0100, Dave Martin wrote:
> Hi Herbert,
>
> This series from Ard is a prerequisite for an arm64 series [1] that I'd
> like to get merged this cycle (because it is in turn a prerequisite for
> another major series I want to progress).
>
> [1] without this series
On Thu, Aug 03, 2017 at 01:12:32AM +, Yu, Wenqian wrote:
> Hi, Herbert and all,
>
> For saving the offload cost of symmetric cipher to hardware accelerator, we
> have a proposal (chained-IV) to batch multiple SG with different IV into one
> skcipher request, which also benefits SW implementa
On Wed, Aug 02, 2017 at 02:03:14PM +, Horia Geantă wrote:
>
> Take CAAM's engine HWRNG: it can work both as a TRNG and as a
> TRNG-seeded DRBG (that's how it's currently configured).
> IIUC, both setups are fit as source for the entropy pool.
So which is it? If it's a DRBG then it should not b
Format it to plaintext and resend it as HTML subpart is treated as SPAM or
Outlook Virus by the system.
Thanks,
- Wenqian
From: Yu, Wenqian
Sent: Thursday, August 3, 2017 9:13 AM
To: linux-crypto@vger.kernel.org
Cc: herb...@gondor.apana.org.au; dm-de...@redhat.com; m-cr...@saout.de; Milan
Bro
On Wed, 2017-08-02 at 14:42 -0300, Thiago Jung Bauermann wrote:
> Mimi Zohar writes:
>
> > On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote:
> >> --- a/security/integrity/ima/ima_appraise.c
> >> +++ b/security/integrity/ima/ima_appraise.c
> >> @@ -200,18 +200,40 @@ int ima_read_xatt
It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
reading ahead beyond its intended data, and causing a crash if the next
block is beyond page boundary:
http://marc.info/?l=linux-crypto-vger&m=149373371023377
This patch makes sure that there is no overflow for any buffer length.
- Original Message -
> On Wed, 2017-08-02 at 10:13 -0700, Megha Dey wrote:
> > It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
> > reading ahead beyond its intended data, and causing a crash if the next
> > block is beyond page boundary:
> > http://marc.info/?l=linux-
On Wed, 2017-08-02 at 10:13 -0700, Megha Dey wrote:
> It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
> reading ahead beyond its intended data, and causing a crash if the next
> block is beyond page boundary:
> http://marc.info/?l=linux-crypto-vger&m=149373371023377
>
> This pa
Mimi Zohar writes:
> On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote:
>> --- a/security/integrity/ima/ima_appraise.c
>> +++ b/security/integrity/ima/ima_appraise.c
>> @@ -200,18 +200,40 @@ int ima_read_xattr(struct dentry *dentry,
>> */
>> int ima_appraise_measurement(enum ima_
Hello Mimi,
Thanks for your review!
The patch at the end of the email implements your suggestions, what do
you think?
Mimi Zohar writes:
> On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote:
>> A separate struct evm_hmac_xattr is introduced, with the original
>> definition of evm_i
It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
reading ahead beyond its intended data, and causing a crash if the next
block is beyond page boundary:
http://marc.info/?l=linux-crypto-vger&m=149373371023377
This patch makes sure that there is no overflow for any buffer length.
On 08/02/2017 03:39 AM, Jan Stancek wrote:
> On 08/02/2017 02:38 AM, Megha Dey wrote:
>> It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
>> reading ahead beyond its intended data, and causing a crash if the next
>> block is beyond page boundary:
>> http://marc.info/?l=linux-cryp
Hi Herbert,
This series from Ard is a prerequisite for an arm64 series [1] that I'd
like to get merged this cycle (because it is in turn a prerequisite for
another major series I want to progress).
[1] without this series will break the kernel, whereas this series
without [1] won't break the kern
On 7/20/2017 4:08 PM, Harald Freudenberger wrote:
> On 07/19/2017 08:13 PM, Oleksij Rempel wrote:
>> On Wed, Jul 19, 2017 at 04:53:21PM +, Horia Geantă wrote:
>>> On 7/19/2017 7:32 PM, Oleksij Rempel wrote:
On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote:
> On 7/19/2017 10
On Wed, Aug 2, 2017 at 10:40 AM, Herbert Xu wrote:
> On Thu, Jul 20, 2017 at 09:37:10AM +0200, Arnd Bergmann wrote:
>
> Oops, looks like I introduced the bug. Anyway, such is the danger
> of fixing compiler warnings in rarely used code.
>
> For some reason your patch is corrupted in patchwork. A
On 08/02/2017 02:38 AM, Megha Dey wrote:
> It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
> reading ahead beyond its intended data, and causing a crash if the next
> block is beyond page boundary:
> http://marc.info/?l=linux-crypto-vger&m=149373371023377
>
> This patch makes s
On 8/1/2017 4:45 PM, Fabio Estevam wrote:
> Most of the dentry members from structure caam_drv_private
> are never used at all, so it is safe to remove them.
>
> Since debugfs_remove_recursive() is called, we don't need the
> file entries.
>
> Signed-off-by: Fabio Estevam
Acked-by: Horia Geantă
On Thu, Jul 20, 2017 at 09:37:10AM +0200, Arnd Bergmann wrote:
>
> Thanks for spotting my mistake!
>
> I've looked at it again and think it's unfortunately still wrong with
> your patch,
> as there is a 'goto free_buf_src' after dma_pool_alloc(), and that now needs
> to jump to free_buf_dst instea
46 matches
Mail list logo
