On 12 May 2017 at 12:11, Mike Frysinger wrote:
> On Fri, May 12, 2017 at 2:15 AM, PrasannaKumar Muralidharan wrote:
>> On 12 May 2017 at 09:47, Mike Frysinger wrote:
>> > From: Mike Frysinger
>> >
>> > If you build in hwrng & tpm-rng, but boot on a system that doesn't
>> > have a tpm (like via K
On Fri, May 12, 2017 at 2:15 AM, PrasannaKumar Muralidharan wrote:
> On 12 May 2017 at 09:47, Mike Frysinger wrote:
> > From: Mike Frysinger
> >
> > If you build in hwrng & tpm-rng, but boot on a system that doesn't
> > have a tpm (like via KVM), hwrng will spam the logs every 10 seconds
> > with
On 12 May 2017 at 09:47, Mike Frysinger wrote:
> From: Mike Frysinger
>
> If you build in hwrng & tpm-rng, but boot on a system that doesn't
> have a tpm (like via KVM), hwrng will spam the logs every 10 seconds
> with the line:
> hwrng: no data available
>
> This isn't terribly useful, s
From: Mike Frysinger
If you build in hwrng & tpm-rng, but boot on a system that doesn't
have a tpm (like via KVM), hwrng will spam the logs every 10 seconds
with the line:
hwrng: no data available
This isn't terribly useful, so squelch the error in the ENODEV case.
For all other errors,
From: Markus Elfring
Date: Thu, 11 May 2017 17:05:17 +0200
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Link:
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Si
Hi Stephan,
On Thursday 11 May 2017 05:52 PM, Stephan Müller wrote:
> Am Donnerstag, 11. Mai 2017, 14:18:34 CEST schrieb srikanth jampala:
>
> Hi srikanth,
>
>> Hi Stephan,
>>
>> On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote:
>>> Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikant
Am Donnerstag, 11. Mai 2017, 14:18:34 CEST schrieb srikanth jampala:
Hi srikanth,
> Hi Stephan,
>
> On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote:
> > Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala:
> >
> > Hi Srikanth,
> >
> > In general: you are using the ablkcip
Hi Stephan,
On Wednesday 10 May 2017 07:26 PM, Stephan Müller wrote:
> Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala:
>
> Hi Srikanth,
>
> In general: you are using the ablkcipher API. I think it is on its way out
> and
> being replaced with skcipher.
>
> Maybe it makes se
crypto_gcm_setkey() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the data buffer that is kfree'ed in this case.
Resolve this by using wait_for_completion() i
public_key_verify_signature() was passing the CRYPTO_TFM_REQ_MAY_BACKLOG
flag to akcipher_request_set_callback() but was not handling correctly
the case where a -EBUSY error could be returned from the call to
crypto_akcipher_verify() if backlog was used, possibly casuing
data corruption due to use-
drbg_kcapi_sym_ctr() was using wait_for_completion_interruptible() to
wait for completion of async crypto op but if a signal occurs it
may return before DMA ops of HW crypto provider finish, thus
corrupting the output buffer.
Resolve this by using wait_for_completion() instead.
Reported-by: Eric
This patch set fixes various usage and documentation errors
in waiting for async crypto op to complete which can result
in data corruption.
Note: these were discovered in the process of working on a
patch set that replaces these call sites and more with a
generic implementation that will prevent t
The sample code was showing use of wait_for_completion_interruptible()
for waiting for an async. crypto op to finish. However, if a signal
arrived it would free the buffers used even while crypto HW might
still DMA from/into the buffers.
Resolve this by using wait_for_completion() instead.
Report
On Thu, May 11, 2017 at 11:09 AM, Eric Biggers wrote:
> On Thu, May 11, 2017 at 10:29:47AM +0300, Gilad Ben-Yossef wrote:
>> > With regards to the wait being uninterruptible, I agree that this should
>> > be the
>> > default behavior, because I think users waiting for specific crypto
>> > reques
On Thu, May 11, 2017 at 10:29:47AM +0300, Gilad Ben-Yossef wrote:
> > With regards to the wait being uninterruptible, I agree that this should be
> > the
> > default behavior, because I think users waiting for specific crypto
> > requests are
> > generally not prepared to handle the wait actually
Hi Eric,
On Thu, May 11, 2017 at 6:55 AM, Eric Biggers wrote:
> Hi Gilad,
>
> On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote:
>> Invoking a possibly async. crypto op and waiting for completion
>> while correctly handling backlog processing is a common task
>> in the crypto API i
16 matches
Mail list logo
