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 appropriateness.
On 10-07-18, 11:27, Jeffrey Hugo wrote:
> On 7/9/2018 12:19 AM, Vinod Koul wrote:
> > From: Timur Tabi
> >
> > Add support for probing on ACPI systems, with ACPI HID QCOM8160.
> >
> > On ACPI systems, clocks are always enabled, the PRNG should
> > already be enabled, and the register region is r
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(). Fix it.
Also add a BUG_ON() if crypto_dh_encode_key() doesn't exactly f
From: Andy Lutomirski
commit c592b57347069abfc0dcad3b3a302cf882602597 upstream
This removes all the obvious code paths that depend on lazy FPU mode.
It shouldn't change the generated code at all.
Signed-off-by: Andy Lutomirski
Signed-off-by: Rik van Riel
Cc: Borislav Petkov
Cc: Brian Gerst
On 7/10/18 12:27 PM, Jeffrey Hugo wrote:
Add support for probing on ACPI systems, with ACPI HID QCOM8160.
On ACPI systems, clocks are always enabled, the PRNG should
already be enabled, and the register region is read-only.
The driver only verifies that the hardware is already
enabled never tri
Top of the day to you, this is in respect of a very beneficial transaction
which you would not want to let go reply for more details,
Regards,
Lee
On 7/9/2018 12:19 AM, Vinod Koul wrote:
From: Timur Tabi
Add support for probing on ACPI systems, with ACPI HID QCOM8160.
On ACPI systems, clocks are always enabled, the PRNG should
already be enabled, and the register region is read-only.
The driver only verifies that the hardware is already
Hi Stephan,
On 07/10/2018 10:28 AM, Stephan Müller wrote:
> Am Dienstag, 10. Juli 2018, 16:22:52 CEST schrieb Gustavo A. R. Silva:
>
> Hi Gustavo,
>
>> In case memory resources for *base* were allocated, release them
>> before return.
>
> Thanks a lot.
>
Glad to help. :)
> Reviewed-by: Steph
Am Dienstag, 10. Juli 2018, 16:22:52 CEST schrieb Gustavo A. R. Silva:
Hi Gustavo,
> In case memory resources for *base* were allocated, release them
> before return.
Thanks a lot.
Reviewed-by: Stephan Müller
Ciao
Stephan
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 increases the speed of the CTR DRBG by 1 to 3 percent
depending on the buffer siz
Hi Herbert,
Please find CTR DRBG performance improvements with the patches attached.
In the following, there is an example log taken with my LRNG implementation
using the getrandom(2) system call demonstrating the difference.
Without the patch set:
16 bytes| 12.267661 MB/s|6
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-initialization of the SGLs during each call.
The performance is increased by about 1 to 3 pe
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: Gustavo A. R. Silva
---
crypto/dh.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
13 matches
Mail list logo
