Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
Signed-off-by: kbuild test robot
---
sec_algs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sec/sec_algs.c
b/drivers/crypto/hisilicon/sec/sec_algs.c
index d69d3ce..f7
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: a94bfd5f50ddf114594f5c7f99686f1cfa2b7a76
commit: 915e4e8413dacc086efcef4de04fdfdca57e8b1c [99/119] crypto: hisilicon -
SEC security accelerator driver
reproduce:
# apt-get install sparse
On Fri, Aug 3, 2018 at 11:29 PM Andy Lutomirski wrote:
> Gotcha. That was very hidden in the 24k lines. Please make this (and
> any similar goodies) be their own patches.
I know, sorry, and I certainly will have this split out. The above
code snippet was from the much much shorter WireGuard pat
On Thu, Aug 2, 2018 at 7:48 PM, Jason A. Donenfeld wrote:
> Hey Andy,
>
> Thanks too for the feedback. Responses below:
>
> On Wed, Aug 1, 2018 at 7:09 PM Andy Lutomirski wrote:
>> > I think the above changes would also naturally lead to a much saner
>> > patch series where each algorithm is adde
On Sat, Aug 04, 2018 at 12:09:08AM +0800, Ryan Chen wrote:
> On Fri, Aug 3, 2018 at 10:06 PM joeyli wrote:
> >
> > On Fri, Aug 03, 2018 at 09:14:22PM +0800, Ryan Chen wrote:
> > > On Fri, Aug 3, 2018 at 1:35 PM joeyli wrote:
> > > >
> > > > On Fri, Aug 03, 2018 at 11:37:02AM +0800, Yu Chen wrote:
On 3 August 2018 at 17:47, Herbert Xu wrote:
> On Mon, Jul 30, 2018 at 11:06:39PM +0200, Ard Biesheuvel wrote:
>> Update the combined AES-GCM AEAD implementation to process two blocks
>> at a time, allowing us to switch to a faster version of the GHASH
>> implementation.
>>
>> Note that this does
On Fri, Aug 3, 2018 at 10:06 PM joeyli wrote:
>
> On Fri, Aug 03, 2018 at 09:14:22PM +0800, Ryan Chen wrote:
> > On Fri, Aug 3, 2018 at 1:35 PM joeyli wrote:
> > >
> > > On Fri, Aug 03, 2018 at 11:37:02AM +0800, Yu Chen wrote:
> > > > Hi Joey,
> > > > On Tue, Jul 31, 2018 at 01:04:15AM +0800, joe
On Sun, Jul 29, 2018 at 04:52:30PM +0200, Ard Biesheuvel wrote:
> As it turns out, checking the TIF_NEED_RESCHED flag after each
> iteration results in a significant performance regression (~10%)
> when running fast algorithms (i.e., ones that use special instructions
> and operate in the < 4 cycle
On Mon, Jul 30, 2018 at 11:06:39PM +0200, Ard Biesheuvel wrote:
> Update the combined AES-GCM AEAD implementation to process two blocks
> at a time, allowing us to switch to a faster version of the GHASH
> implementation.
>
> Note that this does not update the core GHASH transform, only the
> comb
On Fri, Jul 27, 2018 at 03:36:10PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> It was forgotten to increase DH_KPP_SECRET_MIN_SIZE to include 'q_size',
> causing an out-of-bounds write of 4 bytes in crypto_dh_encode_key(), and
> an out-of-bounds read of 4 bytes in crypto_dh_decode_key().
Tom Lendacky wrote:
> Should the PSP initialization fail, the PSP data structure will be
> freed and the value contained in the sp_device struct set to NULL.
> At module unload, psp_dev_destroy() does not check if the pointer
> value is NULL and will end up dereferencing a NULL pointer.
>
> Add a
On Fri, Jul 27, 2018 at 03:36:11PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Make it return -EINVAL if crypto_dh_key_len() is incorrect rather than
> overflowing the buffer.
>
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.
On Fri, Aug 03, 2018 at 03:20:43PM +0100, Alan Cox wrote:
> > If we are going to have any kind of general purpose accelerator API then
> > > it has to be able to implement things like
> >
> > Why is the existing driver model not good enough ? So you want
> > a device with function X you look int
On Fri, Aug 03, 2018 at 11:47:21AM +0800, Kenneth Lee wrote:
> On Thu, Aug 02, 2018 at 10:22:43AM -0400, Jerome Glisse wrote:
> > Date: Thu, 2 Aug 2018 10:22:43 -0400
> > From: Jerome Glisse
> > To: Kenneth Lee
> > CC: "Tian, Kevin" , Hao Fang ,
> > Alex Williamson , Herbert Xu
> > , "k...@vger
> If we are going to have any kind of general purpose accelerator API then
> > it has to be able to implement things like
>
> Why is the existing driver model not good enough ? So you want
> a device with function X you look into /dev/X (for instance
> for GPU you look in /dev/dri)
Except when
On Fri, Aug 03, 2018 at 09:14:22PM +0800, Ryan Chen wrote:
> On Fri, Aug 3, 2018 at 1:35 PM joeyli wrote:
> >
> > On Fri, Aug 03, 2018 at 11:37:02AM +0800, Yu Chen wrote:
> > > Hi Joey,
> > > On Tue, Jul 31, 2018 at 01:04:15AM +0800, joeyli wrote:
> > > > Hi all,
> > > >
> > > > On Thu, Jul 26, 20
On Tue, Jul 24, 2018 at 06:29:07PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The 4-way ChaCha20 NEON code implements 16-bit rotates with vrev32.16,
> but the one-way code (used on remainder blocks) implements it with
> vshl + vsri, which is slower. Switch the one-way code to vrev32.16
On Tue, Jul 24, 2018 at 03:12:42PM +0100, Gilad Ben-Yossef wrote:
> Various code clean ups and fix ups.
>
> Gilad Ben-Yossef (4):
> crypto: ccree: drop useless type flag during reg
> crypto: ccree: remove cipher ivgen left overs
> crypto: ccree: zero all of request ctx before use
> crypto:
On Mon, Jul 23, 2018 at 10:54:55AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> This series fixes the bug reported by Liu Chao (found using syzkaller)
> where a crash occurs in scatterwalk_pagedone() on architectures such as
> arm and arm64 that implement flush_dcache_page(), due to an inv
On Mon, Jul 23, 2018 at 10:21:29AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Setting 'walk->nbytes = walk->total' in skcipher_walk_first() doesn't
> make sense because actually walk->nbytes needs to be set to the length
> of the first step in the walk, which may be less than walk->total
On Mon, Jul 23, 2018 at 10:04:28AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> scatterwalk_samebuf() is never used. Remove it.
>
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.or
On Mon, Jul 23, 2018 at 09:57:50AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The ALIGN() macro needs to be passed the alignment, not the alignmask
> (which is the alignment minus 1).
>
> Fixes: b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface")
> Cc: # v4.10+
> Signed-off
On Mon, Jul 23, 2018 at 10:01:33AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> All callers pass chain=0 to scatterwalk_crypto_chain().
>
> Remove this unneeded parameter.
>
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.
On Mon, Jul 23, 2018 at 05:18:48PM +0300, Horia Geantă wrote:
> Avoid RCU stalls in the case of non-preemptible kernel and lengthy
> speed tests by rescheduling when advancing from one block size
> to another.
>
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Pa
On Mon, Jul 23, 2018 at 04:49:52PM +0100, Jonathan Cameron wrote:
> The driver provides in kernel support for the Hisilicon SEC accelerator
> found in the hip06 and hip07 SoCs. There are 4 such units on the D05
> board for which an appropriate DT binding has been provided. ACPI also
> works with
On Mon, Jul 23, 2018 at 04:43:46PM +0800, Jia-Ju Bai wrote:
> __virtio_crypto_ablkcipher_do_req() is never called in atomic context.
>
> __virtio_crypto_ablkcipher_do_req() is only called by
> virtio_crypto_ablkcipher_crypt_req(), which is only called by
> virtcrypto_find_vqs() that is never cal
On Mon, Jul 23, 2018 at 04:27:44PM +0800, Jia-Ju Bai wrote:
> adf_dev_aer_schedule_reset() is never called in atomic context, as it
> calls wait_for_completion_timeout().
>
> adf_dev_aer_schedule_reset() calls kzalloc() with GFP_ATOMIC,
> which is not necessary.
> GFP_ATOMIC can be replaced with G
On Fri, Jul 20, 2018 at 07:42:01PM +0200, Stephan Müller wrote:
> The cipher implementations of the kernel crypto API favor in-place
> cipher operations. Thus, switch the CTR cipher operation in the DRBG to
> perform in-place operations. This is implemented by using the output
> buffer as input buf
On Mon, Jul 23, 2018 at 04:14:26PM +0800, Jia-Ju Bai wrote:
> crypto_alloc_context() is only called by nitrox_skcipher_init(), which is
> never called in atomic context.
>
> crypto_alloc_context() calls dma_pool_alloc() with GFP_ATOMIC,
> which is not necessary.
> GFP_ATOMIC can be replaced with G
On Thu, Aug 02, 2018 at 04:43:19PM -0700, Kees Cook wrote:
> On Tue, Jul 24, 2018 at 9:49 AM, Kees Cook wrote:
> > In preparing to remove all stack VLA usage from the kernel[1], this
> > removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
> > the smaller SHASH_DESC_ON_STACK by conver
On Fri, Aug 3, 2018 at 1:35 PM joeyli wrote:
>
> On Fri, Aug 03, 2018 at 11:37:02AM +0800, Yu Chen wrote:
> > Hi Joey,
> > On Tue, Jul 31, 2018 at 01:04:15AM +0800, joeyli wrote:
> > > Hi all,
> > >
> > > On Thu, Jul 26, 2018 at 04:14:04PM +0800, joeyli wrote:
> > > > On Thu, Jul 26, 2018 at 09:30
It turns out I had misunderstood how the x86_match_cpu() function works.
It evaluates a logical OR of the matching conditions, not logical AND.
This caused the CPU feature checks for AEGIS to pass even if only SSE2
(but not AES-NI) was supported (or vice versa), leading to potential
crashes if some
On Thu, Aug 2, 2018 at 11:17 AM Ondrej Mosnacek wrote:
> It turns out I had misunderstood how the x86_match_cpu() function works.
> It evaluates a logical OR of the matching conditions, not logical AND.
> This caused the CPU feature checks to pass even if only SSE2 (but not
> AES-NI) was supported
Hmmm... I'm wondering if the skcipher request should be allocated on call
initialisation and a pointer put in the rxrpc_call struct. It's only used
serially for any particular call.
For the moment, I'll pass your patch onto DaveM.
David
On 3 August 2018 at 10:17, Herbert Xu wrote:
> On Fri, Aug 03, 2018 at 09:10:08AM +0200, Ard Biesheuvel wrote:
>> But I think it's too late now to take this into v4.18. Could you
>> please queue this (and my other two pending arm64/aes-gcm patches, if
>> possible) for v4.19 instead?
>
> OK I'll do
On Fri, Aug 03, 2018 at 09:10:08AM +0200, Ard Biesheuvel wrote:
> But I think it's too late now to take this into v4.18. Could you
> please queue this (and my other two pending arm64/aes-gcm patches, if
> possible) for v4.19 instead?
OK I'll do that.
Cheers,
--
Email: Herbert Xu
Home Page: http
On 3 August 2018 at 08:14, Herbert Xu wrote:
> On Sun, Jul 29, 2018 at 04:52:30PM +0200, Ard Biesheuvel wrote:
>> As it turns out, checking the TIF_NEED_RESCHED flag after each
>> iteration results in a significant performance regression (~10%)
>> when running fast algorithms (i.e., ones that use
37 matches
Mail list logo
