is using GFP_ATOMIC allocation that can
fail anytime. This patch fixes the logic so that it won't attempt the
failing allocation if the data doesn't cross a page boundary.
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
---
arch/x86/crypto/aesni-intel_glue.c |2 +-
1 file changed, 1
UEST_ON_STACK is only meant for
> sync algorithms and this code needs to be changed to either do the
> proper request allocation or switch over to allocating sync
> algorithms.
>
> Cheers,
Hi
Here I send a patch that moves those allocations to the heap.
Mikulas
From: Mikulas Patocka
On Mon, 14 Aug 2017, Gilad Ben-Yossef wrote:
> dm-verity is starting async. crypto ops and waiting for them to complete.
> Move it over to generic code doing the same.
>
> This also fixes a possible data coruption bug created by the
> use of wait_for_completion_interruptible() without dealing
ng an algorithm.
>
> Link: http://marc.info/?l=linux-crypto-vger=148063683310477=2
> Cc: sta...@vger.kernel.org
> Reported-by: Mikulas Patocka <mpato...@redhat.com>
> Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com>
> ---
> crypto/mcryptd.c | 19
Hi
There is a bug in mcryptd initialization.
This is a test module that tries various hash algorithms. When you load
the module with "insmod test.ko 'alg=mcryptd(md5)'", the machine crashes.
Mikulas
#include
#include
#include
static char *alg = "md5";
module_param_named(alg, alg, charp,
Fix the same alignment bug as in arm64 - we need to pass residue
unprocessed bytes as the last argument to blkcipher_walk_done.
Signed-off-by: Mikulas Patocka mpato...@redhat.com
Cc: sta...@vger.kernel.org # 3.13+
Index: linux-3.16.0-0.rc6.git1.1.fc21.aarch64/arch/arm/crypto/aesbs-glue.c
On Tue, 16 Feb 2010, Herbert Xu wrote:
On Fri, Feb 12, 2010 at 09:42:28AM +0100, Sebastian Andrzej Siewior wrote:
-static void arc4_crypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+static void arc4_ivsetup(struct arc4_ctx *ctx, u8 *iv)
{
- struct arc4_ctx *ctx =
On Tue, 9 Feb 2010, Herbert Xu wrote:
Mikulas Patocka mpato...@redhat.com wrote:
You should rather add a flag CRYPTO_ALG_CHANGES_STATE to determine that a
cipher can't be used to encrypt disks.
No, please see my reply in the previous thread. What we should
do is fix arc4. I just
This patch disables the use of arc4 on block devices.
arc4 again. it is simply not a block cipher:-)
This should be solved inside cryptoAPI and not blacklist it in dm-crypt,
see that thread
http://article.gmane.org/gmane.linux.kernel.cryptoapi/3441
I some how remember Herbert
On Tue, 26 Jan 2010, Sebastian Andrzej Siewior wrote:
* Mikulas Patocka | 2010-01-26 07:27:18 [-0500]:
yes, I think it is better.
(...and I just forgot to add that test to dm-crypt after that suggestion.)
Milan
Hmm, there is salsa20 that has block size 1, larger initialization
and getting two xored plaintexts.
Signed-off-by: Mikulas Patocka mpato...@redhat.com
---
drivers/md/dm-crypt.c |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6.32-devel/drivers/md/dm-crypt.c
===
--- linux-2.6.32-devel.orig
BTW. I created a script that tests all possible ciphers, keysizes,
chaining modes and iv modes for dm-crypt. arc4 is the only one that fails.
You can add it your regression testsuite if you want.
Mikulas#!/bin/sh
dmsetup remove cr0
set -e
cipher=$@
cryptsetup -d key $cipher create cr0 /dev/ram0
On Thu, May 22, 2008 at 08:32:45AM -0400, Mikulas Patocka wrote:
There may be external modules.
Sorry but we don't support external modules. They should be merged
upstream rather than distributed in the wild.
Cheers,
If you want to negate the meaning of the flag, then you have to write
All the ciphers comply, so the bug is only a theroretical issue (but I
didn't check assembler versions --- they should be checked by the person
who wrote them, assembler is write-only language).
Since every current algorithm sets the flag could you invert
its sense? Sorry to have to do this to
On Wed, 14 May 2008, Herbert Xu wrote:
On Tue, May 13, 2008 at 04:35:03PM -0400, Mikulas Patocka wrote:
And where would you propose to place this bit?
One possibility would be struct crypto_tfm-crt_flags
Another possibility is struct crypto_alg-cra_flags
The latter definitely because
On Tue, 13 May 2008, Herbert Xu wrote:
On Mon, May 12, 2008 at 11:28:44PM -0400, Mikulas Patocka wrote:
Or do you thint it would be useless (all major disk-encryption algorithms
read input buffer more times?) or it would create too much code
complexity?
I'm open to this approach. As long
On Tue, 6 May 2008, Herbert Xu wrote:
Mikulas Patocka [EMAIL PROTECTED] wrote:
BTW: is it guaranteed for crypto functions that they read the source data
only once?
There is no such guarantee.
Cheers,
So we'll have to copy the sector to temporary space before encrypting it.
I'll look
On Mon, 7 Apr 2008, Martin K. Petersen wrote:
Malahal == malahal [EMAIL PROTECTED] writes:
[I sent this last week but it never made it to the list]
Malahal Very few drivers require it, so how about an interface to
Malahal lock the pages of an I/O available to drivers. Only needed
Malahal
18 matches
Mail list logo
