Avoid two potential divisions by zero when calculating average
values for the zip statistics.
Signed-off-by: Jan Glauber
Reviewed-by: Robert Richter
---
drivers/crypto/cavium/zip/zip_main.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
After issuing a request an endless loop was used to read the
completion state from memory which is asynchronously updated
by the ZIP coprocessor.
Add an upper bound to the retry attempts to prevent a CPU getting stuck
forever in case of an error. Additionally, add a read memory barrier
and a
2018-04-09 16:35 GMT+02:00 David Laight :
> From: Salvatore Mesoraca
>> Sent: 09 April 2018 14:55
>>
>> v2:
>> As suggested by Herbert Xu, the blocksize and alignmask checks
>> have been moved to crypto_check_alg.
>> So, now, all the other separate checks
The pending request counter was read from the wrong register. While
at it, there is no need to use an atomic for it as it is only read
localy in a loop.
Signed-off-by: Jan Glauber
Reviewed-by: Robert Richter
---
drivers/crypto/cavium/zip/zip_main.c |
Enabling virtual mapped kernel stacks breaks the thunderx_zip
driver. On compression or decompression the executing CPU hangs
in an endless loop. The reason for this is the usage of __pa
by the driver which does no longer work for an address that is
not part of the 1:1 mapping.
The zip driver
Some bug fixes for this driver after it stopped working with virtual mapped
stacks. I think the first two patches qualify for stable.
Jan Glauber (5):
crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK
crypto: thunderx_zip: Limit result reading attempts
crypto: thunderx_zip: Prevent
Switch to raw_smp_processor_id() to prevent a number of
warnings from kernel debugging. We do not care about
preemption here, as the CPU number is only used as a
poor mans load balancing or device selection. If preemption
happens during a compress/decompress operation a small performance
hit will
(added CAAM maintainers)
On Mon, Apr 09, 2018 at 03:10:11PM +0100, Martin Townsend wrote:
> Hi Mimi,
>
> On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote:
> > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote:
> >> Hi,
> >>
> >> I'm trying to get to the bottom
Hi Mike,
On Mon, Apr 9, 2018 at 5:53 PM, Mike Rapoport wrote:
> (added CAAM maintainers)
>
> On Mon, Apr 09, 2018 at 03:10:11PM +0100, Martin Townsend wrote:
>> Hi Mimi,
>>
>> On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote:
>> > On Mon,
==
ANNOUNCEMENT AND CALL FOR PARTICIPATION
LINUX SECURITY SUMMIT NORTH AMERICA 2018
27-28 August
On Mon, Apr 09, 2018 at 10:58:08AM +0200, Steffen Klassert wrote:
> On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote:
> > On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote:
> > > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote:
> > > > From: Eric Biggers
On Mon, 2018-04-09 at 15:10 +0100, Martin Townsend wrote:
> Hi Mimi,
>
> On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote:
> > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote:
> >> Hi,
> >>
> >> I'm trying to get to the bottom of an issue I'm seeing when
From: Salvatore Mesoraca
> Sent: 09 April 2018 14:55
>
> v2:
> As suggested by Herbert Xu, the blocksize and alignmask checks
> have been moved to crypto_check_alg.
> So, now, all the other separate checks are not necessary.
> Also, the defines have been moved to
On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote:
> On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote:
> > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote:
> > > From: Eric Biggers
> > >
> > > If the pcrypt template is used multiple times in
On 04/03/2018 12:19 PM, Herbert Xu wrote:
> On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote:
>> However, as it uses the exact same mechanism of the regular xts-aes-ccree
>> but takes the key from another source, I've marked it with a test of
>> alg_test_null() on the premise that
Am Montag, 9. April 2018, 09:51:13 CEST schrieb Dmitry Vyukov:
Hi Dmitry,
> You can ask syzbot to test by replying to its report email with a test
> command, see:
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication
> -with-syzbot
>
> Note that all testing of KMSAN
On Tue, Apr 3, 2018 at 1:19 PM, Herbert Xu wrote:
> On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote:
>>
>> However, as it uses the exact same mechanism of the regular xts-aes-ccree
>> but takes the key from another source, I've marked it with a test
On Sun, Apr 8, 2018 at 7:57 PM, Stephan Müller wrote:
> Hi,
>
> May I ask to check whether this patch fixes the issue? I cannot re-create
> the issue with the reproducter. Yet, as far as I understand, you try to
> induce errors which shall validate whether the error code
On Mon, Apr 9, 2018 at 7:40 AM, Stephan Mueller wrote:
> Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o:
>
> Hi Theodore,
>>
>> So the syzbot will run while the patch goes through the normal e-mail
>> review process, which is kind of neat. :-)
>
> Thank you
Hi,
I'm trying to get to the bottom of an issue I'm seeing when enabling
the CAAM in the kernel with IMA/EVM enabled. I'm using the official
NXP (imx_4.9.11_1.0.0_ga) vendor Kernel.
Here's the error message I'm getting.
caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error -
A
On Tue, Apr 3, 2018 at 3:22 PM, Milan Broz wrote:
> On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote:
> ...
>>> Are there other crypto drivers doing this?
>>
>> I thought the exact same thing until I ran into a presentation about the s390
>> secure keys implementation. I
Please ignore this thread, I sent the old patch-set again by mistake :(
I'm sorry for the noise.
Salvatore
Hi Mimi,
On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote:
> On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote:
>> Hi,
>>
>> I'm trying to get to the bottom of an issue I'm seeing when enabling
>> the CAAM in the kernel with IMA/EVM enabled. I'm using the
On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote:
> Hi,
>
> I'm trying to get to the bottom of an issue I'm seeing when enabling
> the CAAM in the kernel with IMA/EVM enabled. I'm using the official
> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel.
>
> Here's the error message I'm getting.
>
2018-04-08 11:22 GMT+02:00 Herbert Xu :
> On Sun, Apr 08, 2018 at 11:07:12AM +0200, Salvatore Mesoraca wrote:
>>
>> > This check should be done when the algorithm is registered. Perhaps
>> > crypto_check_alg.
>>
>> Please correct me if I'm wrong:
>> isn't
As suggested by Laura Abbott[2], I'm resending my patch with
MAX_BLOCKSIZE and MAX_ALIGNMASK defined in an header, so they
can be used in other places.
I take this opportuinuty to deal with some other VLAs not
handled in the old patch.
[1]
We avoid various VLAs[1] by using constant expressions for block size
and alignment mask.
[1]
http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Salvatore Mesoraca
---
crypto/cfb.c| 7 +++
crypto/cipher.c
We avoid 2 VLAs[1] by always allocating MAX_BLOCKSIZE +
MAX_ALIGNMASK bytes.
We also check the selected cipher at instance creation time, if
it doesn't comply with these limits, the creation will fail.
[1]
v2:
As suggested by Herbert Xu, the blocksize and alignmask checks
have been moved to crypto_check_alg.
So, now, all the other separate checks are not necessary.
Also, the defines have been moved to include/crypto/algapi.h.
v1:
As suggested by Laura
In preparation for the removal of VLAs[1] from crypto code.
We create 2 new compile-time constants: all ciphers implemented
in Linux have a block size less than or equal to 16 bytes and
the most demanding hw require 16 bytes alignment for the block
buffer.
We also enforce these limits in
We avoid 2 VLAs[1] by always allocating MAX_BLOCKSIZE bytes.
We also check the selected cipher at instance creation time, if
it doesn't comply with these limits, the creation will fail.
[1]
http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
We avoid 3 VLAs[1] by always allocating MAX_BLOCKSIZE bytes or,
when needed for alignement, MAX_BLOCKSIZE + MAX_ALIGNMASK bytes.
We also check the selected cipher at instance creation time, if
it doesn't comply with these limits, the creation will fail.
[1]
We avoid 2 VLAs[1] by always allocating MAX_BLOCKSIZE*2 bytes.
We also check the selected cipher at instance creation time, if
it doesn't comply with these limits, the creation will fail.
[1]
http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
We avoid a VLA[1] by always allocating MAX_BLOCKSIZE +
MAX_ALIGNMASK bytes.
We also check the selected cipher at initialization time, if
it doesn't comply with these limits, the initialization will
fail.
[1]
Creating 2 new compile-time constants for internal use,
in preparation for the removal of VLAs[1] from crypto code.
All ciphers implemented in Linux have a block size less than or
equal to 16 bytes and the most demanding hw require 16 bytes
alignment for the block buffer.
[1]
35 matches
Mail list logo