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
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
>
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
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:
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 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
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
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:
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+
>
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:
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
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 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
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
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
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:
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
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
On 7/11/2018 3:16 AM, Dan Carpenter wrote:
Hello Janakarajan Natarajan,
The patch edd303ff0e9e: "crypto: ccp - Add DOWNLOAD_FIRMWARE SEV
command" from May 25, 2018, leads to the following static checker
warning:
drivers/crypto/ccp/psp-dev.c:397 sev_get_api_version()
error:
On Mon, Jul 23, 2018 at 04:49:53PM +0100, Jonathan Cameron wrote:
> The hip06 and hip07 SoCs contain a number of these crypto units which
> accelerate AES and DES operations.
>
You forgot the 'v2' on the patches. Only matters because I sort my
reviews by version and then date. But don't tell
On Tue, Jul 31, 2018 at 09:47:28AM +0100, Will Deacon wrote:
> On Tue, Jul 31, 2018 at 09:22:52AM +0200, Ard Biesheuvel wrote:
> > (+ Catalin, Will)
> >
> > On 27 July 2018 at 14:59, Ard Biesheuvel wrote:
> > > Calling pmull_gcm_encrypt_block() requires kernel_neon_begin() and
> > >
On Tue, Jul 31, 2018 at 09:22:52AM +0200, Ard Biesheuvel wrote:
> (+ Catalin, Will)
>
> On 27 July 2018 at 14:59, Ard Biesheuvel wrote:
> > Calling pmull_gcm_encrypt_block() requires kernel_neon_begin() and
> > kernel_neon_end() to be used since the routine touches the NEON
> > register file.
(+ Catalin, Will)
On 27 July 2018 at 14:59, Ard Biesheuvel wrote:
> Calling pmull_gcm_encrypt_block() requires kernel_neon_begin() and
> kernel_neon_end() to be used since the routine touches the NEON
> register file. Add the missing calls.
>
> Also, since NEON register contents are not
On Tue, Jul 17, 2018 at 10:09:26AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Commit b73b7ac0a774 ("crypto: sha256_generic - add cra_priority") gave
> sha256-generic and sha224-generic a cra_priority of 100, to match the
> convention for generic implementations. But sha256-arm64 and
>
On Mon, Jul 16, 2018 at 11:20:21AM +0530, Vinod Koul wrote:
> This series removes the hwrng qcom driver and replaces it with crypto qcom
> driver and then adds support for Execution Environment (EE) found in v2
> version of the hardware and ACPI support for these
>
> Changes in v6:
> - Fix a
On Fri, Jul 27, 2018 at 01:49:08PM +0200, Stephan Mueller wrote:
>
> This is guaranteed by the invokers of drbg_kcapi_sym_ctr as there are two
> only:
>
> - the one in drbg_ctr_update uses the scratchpad for inbuf
>
> - the one in drbg_ctr_generate uses NULL which implies that the outscratchpad
Am Freitag, 27. Juli 2018, 12:53:35 CEST schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jul 20, 2018 at 07:42:01PM +0200, Stephan Müller wrote:
> > @@ -1747,10 +1733,18 @@ static int drbg_kcapi_sym_ctr(struct drbg_state
> > *drbg,>
> > u8 *outbuf, u32 outlen)
> >
> > {
>
On Fri, Jul 20, 2018 at 07:42:01PM +0200, Stephan Müller wrote:
>
> @@ -1747,10 +1733,18 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
> u8 *outbuf, u32 outlen)
> {
> struct scatterlist *sg_in = >sg_in, *sg_out = >sg_out;
> + u32 scratchpad_use =
On 07/26/2018 09:37 AM, 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
On 2018-07-26 09:25:40 [+0200], Ard Biesheuvel wrote:
> Thanks a lot.
>
> So 20 us ~= 20,000 cycles on my 1 GHz Cortex-A53, and if I am
> understanding you correctly, you wouldn't mind the quantum of work to
> be in the order 16,000 cycles or even substantially more?
I have currently that one
On 25 July 2018 at 18:50, bige...@linutronix.de wrote:
> On 2018-07-25 11:54:53 [+0200], Ard Biesheuvel wrote:
>> Indeed. OTOH, if the -rt people (Sebastian?) turn up and say that a
>> 1000 cycle limit to the quantum of work performed with preemption
>> disabled is unreasonably low, we can
Hi GaoKui,
On Thu, Jul 26, 2018 at 02:44:30AM +, gaokui (A) wrote:
> Hi, Eric,
> Thanks for your reply.
>
> I have run your program on an original kernel and it reproduced the
> crash. And I also run the program on a kernel with our patch, but there was
> no crash.
>
>
On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
>> shash directly and allocating the
On 2018-07-25 11:54:53 [+0200], Ard Biesheuvel wrote:
> Indeed. OTOH, if the -rt people (Sebastian?) turn up and say that a
> 1000 cycle limit to the quantum of work performed with preemption
> disabled is unreasonably low, we can increase the yield block counts
> and approach the optimal numbers
On Wed, 2018-07-25 at 15:12 +0200, Arnd Bergmann wrote:
> tools/perf/tests/.gitignore:
> LLVM byte-codes, uncompressed
> On Wed, Jul 25, 2018 at 2:55 AM, Andrew Morton
> wrote:
> > On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote:
> >
> > > On Tue, 2018-07-24 at
tools/perf/tests/.gitignore:
LLVM byte-codes, uncompressed
On Wed, Jul 25, 2018 at 2:55 AM, Andrew Morton
wrote:
> On Tue, 24 Jul 2018 17:13:20 -0700 Joe Perches wrote:
>
>> On Tue, 2018-07-24 at 14:00 -0700, Andrew Morton wrote:
>> > On Tue, 24 Jul 2018 13:13:25
On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
> shash directly and allocating the descriptor in heap memory (which should
> be fine: the tfm has
On 25 July 2018 at 11:45, Dave Martin wrote:
> On Wed, Jul 25, 2018 at 10:23:00AM +0100, Ard Biesheuvel wrote:
>> On 25 July 2018 at 11:09, Dave Martin wrote:
>> > On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
>> >> Vakul reports a considerable performance hit when running the
On 25 July 2018 at 11:48, Dave Martin wrote:
> On Wed, Jul 25, 2018 at 10:11:42AM +0100, Ard Biesheuvel wrote:
>> On 25 July 2018 at 11:05, Dave Martin wrote:
>> > On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
>> >> As reported by Vakul, checking the TIF_NEED_RESCHED flag after
On Wed, Jul 25, 2018 at 10:11:42AM +0100, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:05, Dave Martin wrote:
> > On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
> >> As reported by Vakul, checking the TIF_NEED_RESCHED flag after every
> >> iteration of the GHASH and AES-GCM core
On Wed, Jul 25, 2018 at 10:23:00AM +0100, Ard Biesheuvel wrote:
> On 25 July 2018 at 11:09, Dave Martin wrote:
> > On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
> >> Vakul reports a considerable performance hit when running the accelerated
> >> arm64 crypto routines with
On 25 July 2018 at 11:09, Dave Martin wrote:
> On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
>> Vakul reports a considerable performance hit when running the accelerated
>> arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
>> been updated to take the
On 25 July 2018 at 11:05, Dave Martin wrote:
> On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
>> As reported by Vakul, checking the TIF_NEED_RESCHED flag after every
>> iteration of the GHASH and AES-GCM core routines is having a considerable
>> performance impact on cores such
On Tue, Jul 24, 2018 at 06:12:20PM +0100, Ard Biesheuvel wrote:
> Vakul reports a considerable performance hit when running the accelerated
> arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
> been updated to take the TIF_NEED_RESCHED flag into account.
>
> The issue
On Tue, Jul 24, 2018 at 06:12:21PM +0100, Ard Biesheuvel wrote:
> As reported by Vakul, checking the TIF_NEED_RESCHED flag after every
> iteration of the GHASH and AES-GCM core routines is having a considerable
> performance impact on cores such as the Cortex-A53 with Crypto Extensions
>
>> with 4 files).
>>
>> Instead of using hardcoded 32 block/16 block limit, should it be controlled
>> using Kconfig?
>> I believe that on different cores, these values could be required to be
>> different.
>>
>
> Simply enabling CONFIG_PREEMPT al
ch series
> for adding
> preemptability check, there were lot more files changed than this series with
> 4 files).
>
> Instead of using hardcoded 32 block/16 block limit, should it be controlled
> using Kconfig?
> I believe that on different cores, these values could be required t
On Tue, 2018-07-24 at 09:49 -0700, 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 converting from ahash-wrapped-shash
> to direct shash. By removing a
On 2018-07-25 07:04:55 [+], Vakul Garg wrote:
> >
> > What about PREEMPT_NONE (server)?
>
> Why not have best of both the worlds :)
the NEON code gets interrupted because another tasks wants to schedule
and the scheduler allows. With "low latency desktop" this gets right
done away. The
> -Original Message-
> From: bige...@linutronix.de [mailto:bige...@linutronix.de]
> Sent: Wednesday, July 25, 2018 12:33 PM
> To: Vakul Garg
> Cc: Ard Biesheuvel ; linux-
> cry...@vger.kernel.org; herb...@gondor.apana.org.au;
> will.dea...@arm.com; dave.mar...@
On 2018-07-25 06:57:42 [+], Vakul Garg wrote:
> I tested this patch. It helped but didn't regain the performance to previous
> level.
> Are there more files remaining to be fixed? (In your original patch series
> for adding
> preemptability check, there were lot more files changed than this
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, July 24, 2018 10:42 PM
> To: linux-crypto@vger.kernel.org
> Cc: herb...@gondor.apana.org.au; will.dea...@arm.com;
> dave.mar...@arm.com; Vakul Garg ;
> bige...@linutronix.de; Ard Biesheuvel
On 25 July 2018 at 03:29, 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 too.
>
>
On 2018-07-24 19:12:20 [+0200], Ard Biesheuvel wrote:
> Vakul reports a considerable performance hit when running the accelerated
> arm64 crypto routines with CONFIG_PREEMPT=y configured, now that thay have
> been updated to take the TIF_NEED_RESCHED flag into account.
just in time. I will try to
On 16-07-18, 11:20, Vinod Koul wrote:
> This series removes the hwrng qcom driver and replaces it with crypto qcom
> driver and then adds support for Execution Environment (EE) found in v2
> version of the hardware and ACPI support for these
Stephan, Herbert
Any chance this could make it for
On Fri, 20 Jul 2018 20:17:22 +0200
Stephan Müller wrote:
> Am Montag, 16. Juli 2018, 12:43:41 CEST schrieb Jonathan Cameron:
>
> Hi Jonathan,
>
> > +static int sec_alg_skcipher_setkey_aes_xts(struct crypto_skcipher *tfm,
> > + const u8 *key, unsigned
Sir/Madam,
Are you in need of a loan or Investment funding? We give out all
kinds of loans with a very low interest rate of 2% reply only if you
are intrested.
Am Montag, 16. Juli 2018, 12:43:41 CEST schrieb Jonathan Cameron:
Hi Jonathan,
> +static int sec_alg_skcipher_setkey_aes_xts(struct crypto_skcipher *tfm,
> + const u8 *key, unsigned int
> keylen) +{
> + enum sec_cipher_alg alg;
> +
> + switch
Hello Dear.
My Name is Mrs. Bella Yostin Mohammad, I got your contact from a
business directory search and I decided to contact you directly. well
am originally from South Africa, but based in London, i am searching
for a reliable and honest and understanding person to go into
partnership in
On Fri, 20 Jul 2018 10:30:10 -0600
Rob Herring wrote:
> On Mon, Jul 16, 2018 at 11:43:40AM +0100, Jonathan Cameron wrote:
> > The hip06 and hip07 SoCs contain a number of these crypto units which
> > accelerate AES and DES operations.
> >
> > Signed-off-by: Jonathan Cameron
> > ---
> >
On Mon, Jul 16, 2018 at 11:43:40AM +0100, Jonathan Cameron wrote:
> The hip06 and hip07 SoCs contain a number of these crypto units which
> accelerate AES and DES operations.
>
> Signed-off-by: Jonathan Cameron
> ---
> .../bindings/crypto/hisilicon,hip07-sec.txt| 69
>
On Wed, Jul 11, 2018 at 08:35:49PM +0200, Stephan Müller wrote:
> By adding a zero byte-length for the DH parameter Q value, the public
> key verification test is disabled for the given test.
>
> Reported-by: Eric Biggers
> Signed-off-by: Stephan Mueller
Patch applied. Thanks.
--
Email:
On Sun, Jul 15, 2018 at 12:27:06AM +0200, Michael Müller wrote:
> This patch fixes two typos related to unregistering algorithms supported by
> SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered
> in case of an error. In sahara_unregister_algs the wrong array is used to
>
On Wed, Jul 11, 2018 at 08:36:23PM +0200, Stephan Müller wrote:
> Fix the b value to be compliant with FIPS 186-4 D.1.2.1. This fix is
> required to make sure the SP800-56A public key test passes for P-192.
>
> Signed-off-by: Stephan Mueller
Patch applied. Thanks.
--
Email: Herbert Xu
Home
On Fri, Jul 20, 2018 at 07:09:05AM +0200, Stephan Mueller wrote:
>
> Maybe I have a different understanding of how such interface should look like.
>
> Can you give me some more detail on how you envision such virtual address
> interface should work?
It should look like shash.
Cheers,
--
On Fri, Jul 13, 2018 at 05:43:16PM +0200, Antoine Tenart wrote:
> In the cipher safexcel_send_req function, GCC warns that
> first_rdesc may be used uninitialized. While this should never
> happen, this patch removes the warning by initializing this
> variable to NULL to make GCC happy.
>
> This
On Tue, Jul 10, 2018 at 05:56:33PM +0200, Stephan Müller wrote:
> The CTR DRBG requires two SGLs pointing to input/output buffers for the
> CTR AES operation. The used SGLs always have only one entry. Thus, the
> SGL can be initialized during allocation time, preventing a
> re-in
On Fri, Jul 20, 2018 at 08:08:22AM +0200, Stephan Mueller wrote:
>
> - should it be synchronous like blkcipher?
It should be synchronous.
> - the TFMs (cipher Impls and templates) all operate on SGLs - should a virt
> API simply convert a virt address into an SGL? If so, the problem that
>
On Fri, Jul 13, 2018 at 04:51:37PM +0200, Antoine Tenart wrote:
> Use the appropriate SPDX license identifiers and drop the license text.
> This patch is only cosmetic.
>
> Signed-off-by: Antoine Tenart
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page:
On Tue, Jul 10, 2018 at 09:22:52AM -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *base* were allocated, release them
> before return.
>
> Addresses-Coverity-ID: 1471702 ("Resource leak")
> Fixes: e3fe0ae12962 ("crypto: dh - add public key verification test")
> Signed-off-by:
>> On Fri, Jul 20, 2018 at 07:09:05AM +0200, Stephan Mueller wrote:
>>
>> Maybe I have a different understanding of how such interface should look
>> like.
>>
>> Can you give me some more detail on how you envision such virtual address
>> interface should work?
>
> It should look like
> Am 20.07.2018 um 05:54 schrieb Herbert Xu :
>
>> On Thu, Jul 19, 2018 at 10:57:16PM +0200, Stephan Müller wrote:
>>
>> Therefore, I am not sure that either having an SGL interface for the RNG API
>> or a virtual address interface for the sync skcipher would be helpful.
>
> Could you
]
发送时间: 2018年7月15日 22:05
收件人: Liuchao (H)
抄送: herb...@gondor.apana.org.au; da...@davemloft.net;
linux-crypto@vger.kernel.org; dongjinguang ;
ebigg...@google.com; 罗新强 ; gaokui (A)
主题: Re: [PATCH] crypto: Add 0 walk-offset check in scatterwalk_pagedone()
Hi Liu,
On Mon, Jul 09, 2018 at 05:
On Thu, Jul 19, 2018 at 10:57:16PM +0200, Stephan Müller wrote:
>
> Therefore, I am not sure that either having an SGL interface for the RNG API
> or a virtual address interface for the sync skcipher would be helpful.
Could you please explain again why a virtual address interface to
sync
Am Donnerstag, 19. Juli 2018, 11:34:33 CEST schrieb Herbert Xu:
Hi Herbert,
> I think this is an abuse of virt_addr_valid. It's meant to catch
> bogus uses of SG lists, it's not meant to be a guarantee that an
> address can be used on an SG list.
Thanks for your insights.
>
> A better
On Tue, Jul 10, 2018 at 05:57:00PM +0200, Stephan Müller wrote:
> The SGL can directly operate caller-provided memory with the exception
> of stack memory. The DRBG detects whether the caller provided
> non-suitable memory and uses the scratchpad only on those circumstances.
>
> This patch
On Wed, Jul 11, 2018 at 09:27:56AM -0700, Eric Biggers wrote:
>
> The callers do check for errors, but at the point of the proposed BUG_ON() a
> buffer overflow may have already occurred, so I think a BUG_ON() would be more
> appropriate than a WARN_ON(). Of course, it would be better to prevent
Hi Liu,
On Mon, Jul 09, 2018 at 05:10:19PM +0800, Liu Chao wrote:
> From: Luo Xinqiang
>
> In function scatterwalk_pagedone(), a kernel panic of invalid
> page will occur if walk->offset equals 0. This patch fixes the
> problem by setting the page addresswith sg_page(walk->sg)
> directly if
Herbert Xu wrote:
> This was detected by the self-test thanks to Ard's chunking patch.
>
> I finally got around to testing this out on my ancient Via box. It
> turns out that the workaround got the assembly wrong and we end up
> doing count + initial cycles of the loop instead of just count.
>
On Tue, Jul 03, 2018 at 12:11:22PM -0500, Tom Lendacky wrote:
> The following patches for the PSP support within the CCP driver are
> included in this driver update series:
>
> - Fix a possible race condition when checking for command completion
> - Add a message to indicate if the PSP function
On Wed, Jul 11, 2018 at 03:26:56PM +0800, Herbert Xu wrote:
> On Tue, Jul 10, 2018 at 08:59:05PM -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
Am Mittwoch, 11. Juli 2018, 06:10:59 CEST schrieb Eric Biggers:
Hi Eric,
> You forgot to update the self-tests in the kernel, so they're failing now,
> as you *did* change the interface (the "key" is encoded differently now).
I was actually looking for failing self tests. But accidentally I
Am Mittwoch, 11. Juli 2018, 05:59:05 CEST schrieb Eric Biggers:
Hi Eric,
> 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
On Tue, Jul 10, 2018 at 08:59:05PM -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().
Hi Stephan,
On Wed, Jun 27, 2018 at 08:15:31AM +0200, Stephan Müller wrote:
> Hi,
>
> Changes v2:
> * addition of a check that mpi_alloc succeeds.
>
> ---8<---
>
> According to SP800-56A section 5.6.2.1, the public key to be processed
> for the DH operation shall be checked for
On Sun, Jul 01, 2018 at 08:02:33AM +0100, Gilad Ben-Yossef wrote:
> The patch set fixes ccree IV handling, finup() operation (provided
> by Hadar Gat) and CTS-AES mode of operation along a code cleanup.
>
>
On Sat, Jun 30, 2018 at 03:16:10PM -0700, Eric Biggers wrote:
> Originally, algorithms had to declare their type in .cra_flags as a
> CRYPTO_ALG_TYPE_* value. Some types of algorithms such as "cipher"
> still have to do this. But now most algorithm types use different
> top-level C data
On Fri, Jun 29, 2018 at 02:14:35PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There is a copy-paste error where sha256_mb_mgr_get_comp_job_avx2()
> copies the SHA-256 digest state from sha256_mb_mgr::args::digest to
> job_sha256::result_digest. Consequently, the sha256_mb algorithm
>
On Fri, Jun 29, 2018 at 02:21:11PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> "arch/x86/crypto/sha*-mb" needs a trailing slash, since it refers to
> directories. Otherwise get_maintainer.pl doesn't find the entry.
>
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email:
On Fri, Jun 29, 2018 at 05:01:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> I found that not only was sha256_mb sometimes computing the wrong digest
> (fixed by a separately sent patch), but under normal workloads it's
> hundreds of times slower than sha256-avx2, due to the flush
On Thu, Jun 28, 2018 at 05:21:52PM +0200, Antoine Tenart wrote:
> Hi all,
>
> This series adds support for more algorithms in the Inside Secure
> SafeXcel cryptographic engine driver. Those new algorithms are:
> - MD5 (and its hmac).
> - DES (ECB and CBC).
> - 3DES (ECB and CBC).
>
> The last
On Mon, Jun 25, 2018 at 12:00:18PM +0200, Stephan Müller wrote:
> According to SP800-56A section 5.6.2.1, the public key to be processed
> for the ECDH operation shall be checked for appropriateness. When the
> public key is considered to be an ephemeral key, the partial validation
> test as
On 07/03/2018 12:12 PM, Tom Lendacky wrote:
In preparation for adding a new PSP device ID that uses different register
offsets, add support to the PSP version data for register offset values.
And then update the code to use these new register offset values.
Signed-off-by: Tom Lendacky
---
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
Remove some unused #defines for register offsets that are not used. This
will lessen the changes required when register offsets change between
versions of the device.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c |2 +-
On 07/03/2018 12:12 PM, Tom Lendacky wrote:
Add a new CCP/PSP PCI device ID and new PSP register offsets.
Signed-off-by: Tom Lendacky
Acked-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git
On 07/05/2018 10:43 AM, Brijesh Singh wrote:
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
The wait_event() function is used to detect command completion. The
interrupt handler will set the wait condition variable when the interrupt
is triggered. However, the variable used for wait_event() is
On 07/03/2018 12:12 PM, Tom Lendacky wrote:
In preparation for adding a new PSP device ID that uses different register
offsets, add support to the PSP version data for register offset values.
And then update the code to use these new register offset values.
Signed-off-by: Tom Lendacky
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
Remove some unused #defines for register offsets that are not used. This
will lessen the changes required when register offsets change between
versions of the device.
Signed-off-by: Tom Lendacky
Acked-by: Gary R Hook
---
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
Add a dev_notice() message to the PSP initialization to report when the
PSP initialization has succeeded and the PSP is enabled.
Signed-off-by: Tom Lendacky
Acked-by: Gary R Hook
---
drivers/crypto/ccp/psp-dev.c |2 ++
1 file changed, 2
201 - 300 of 16295 matches
Mail list logo
