* Re: Kernel panic - encryption/decryption failed when open file on Arm64
From: Herbert Xu @ 2016-09-13 6:43 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: liushuoran, Xiakaixu, David S. Miller, Theodore Ts'o,
Jaegeuk Kim, nhorman@tuxdriver.com, mh1@iki.fi,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Wangbintian, Huxinwei, zhangzhibin (C)
In-Reply-To: <CAKv+Gu9jaVyJ4PYsxZfiZXB3Uezr26YWhSyE-g+n6-AuWFcneQ@mail.gmail.com>
On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>
> So to me, it seems like we should be taking the blkcipher_next_slow()
> path, which does a kmalloc() and bails with -ENOMEM if that fails.
Indeed. This was broken a long time ago. It does seem to be
fixed in the new skcipher_walk code but here is a patch to fix
it for older kernels.
---8<---
Subject: crypto: skcipher - Fix blkcipher walk OOM crash
When we need to allocate a temporary blkcipher_walk_next and it
fails, the code is supposed to take the slow path of processing
the data block by block. However, due to an unrelated change
we instead end up dereferencing the NULL pointer.
This patch fixes it by moving the unrelated bsize setting out
of the way so that we enter the slow path as inteded.
Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block")
Cc: stable@vger.kernel.org
Reported-by: xiakaixu <xiakaixu@huawei.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 3699995..a832426 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -233,6 +233,8 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
return blkcipher_walk_done(desc, walk, -EINVAL);
}
+ bsize = min(walk->walk_blocksize, n);
+
walk->flags &= ~(BLKCIPHER_WALK_SLOW | BLKCIPHER_WALK_COPY |
BLKCIPHER_WALK_DIFF);
if (!scatterwalk_aligned(&walk->in, walk->alignmask) ||
@@ -245,7 +247,6 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
}
}
- bsize = min(walk->walk_blocksize, n);
n = scatterwalk_clamp(&walk->in, n);
n = scatterwalk_clamp(&walk->out, n);
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: Kernel panic - encryption/decryption failed when open file on Arm64
From: Ard Biesheuvel @ 2016-09-13 7:56 UTC (permalink / raw)
To: Herbert Xu
Cc: liushuoran, Xiakaixu, David S. Miller, Theodore Ts'o,
Jaegeuk Kim, nhorman@tuxdriver.com, mh1@iki.fi,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Wangbintian, Huxinwei, zhangzhibin (C)
In-Reply-To: <20160913064329.GA26933@gondor.apana.org.au>
On 13 September 2016 at 07:43, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Mon, Sep 12, 2016 at 06:40:15PM +0100, Ard Biesheuvel wrote:
>>
>> So to me, it seems like we should be taking the blkcipher_next_slow()
>> path, which does a kmalloc() and bails with -ENOMEM if that fails.
>
> Indeed. This was broken a long time ago. It does seem to be
> fixed in the new skcipher_walk code but here is a patch to fix
> it for older kernels.
>
> ---8<---
> Subject: crypto: skcipher - Fix blkcipher walk OOM crash
>
> When we need to allocate a temporary blkcipher_walk_next and it
> fails, the code is supposed to take the slow path of processing
> the data block by block. However, due to an unrelated change
> we instead end up dereferencing the NULL pointer.
>
> This patch fixes it by moving the unrelated bsize setting out
> of the way so that we enter the slow path as inteded.
>
inteNded ^^^
> Fixes: 7607bd8ff03b ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block")
> Cc: stable@vger.kernel.org
> Reported-by: xiakaixu <xiakaixu@huawei.com>
> Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
This fixes the issue for me
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I will follow up with fixes for the ARM and arm64 CTR code shortly.
Thanks,
Ard.
> diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
> index 3699995..a832426 100644
> --- a/crypto/blkcipher.c
> +++ b/crypto/blkcipher.c
> @@ -233,6 +233,8 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
> return blkcipher_walk_done(desc, walk, -EINVAL);
> }
>
> + bsize = min(walk->walk_blocksize, n);
> +
> walk->flags &= ~(BLKCIPHER_WALK_SLOW | BLKCIPHER_WALK_COPY |
> BLKCIPHER_WALK_DIFF);
> if (!scatterwalk_aligned(&walk->in, walk->alignmask) ||
> @@ -245,7 +247,6 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
> }
> }
>
> - bsize = min(walk->walk_blocksize, n);
> n = scatterwalk_clamp(&walk->in, n);
> n = scatterwalk_clamp(&walk->out, n);
>
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v3] crypto: only call put_page on referenced and used pages
From: Stephan Mueller @ 2016-09-13 8:18 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
In-Reply-To: <13399079.xub8KL5p6S@positron.chronox.de>
Am Montag, 12. September 2016, 14:43:45 CEST schrieb Stephan Mueller:
Hi Herbert,
> Hi Herbert,
>
> after getting the AIO code working on sendmsg, tried it with vmsplice/splice
> and I get a memory corruption. Interestingly, the stack trace is partially
> garbled too. Thus, tracking this one down may be a bit of a challenge.
The issue is a NULL pointer dereference in skcipher_free_async_sgls. The issue is that SGs may not have even a page mapped to them and thus the page entry is NULL.
The following patch fixes the issue and replaces the patch I sent earlier.
---8<---
For asynchronous operation, SGs are allocated without a page mapped to
them or with a page that is not used (ref-counted). If the SGL is freed,
the code must only call put_page for an SG if there was a page assigned
and ref-counted in the first place.
This fixes a kernel crash when using io_submit with more than one iocb
using the sendmsg and sendpage (vmsplice/splice) interface
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/algif_skcipher.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 28556fc..45af0fe 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -86,8 +86,13 @@ static void skcipher_free_async_sgls(struct skcipher_async_req *sreq)
}
sgl = sreq->tsg;
n = sg_nents(sgl);
- for_each_sg(sgl, sg, n, i)
- put_page(sg_page(sg));
+ for_each_sg(sgl, sg, n, i) {
+ struct page *page = sg_page(sg);
+
+ /* some SGs may not have a page mapped */
+ if (page && page_ref_count(page))
+ put_page(page);
+ }
kfree(sreq->tsg);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] crypto: arm/aes-ctr: fix NULL dereference in tail processing
From: Ard Biesheuvel @ 2016-09-13 8:48 UTC (permalink / raw)
To: linux-crypto, herbert, linux-arm-kernel; +Cc: xiakaixu, Ard Biesheuvel
The AES-CTR glue code avoids calling into the blkcipher API for the
tail portion of the walk, by comparing the remainder of walk.nbytes
modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
into the tail processing block if they are equal. This tail processing
block checks whether nbytes != 0, and does nothing otherwise.
However, in case of an allocation failure in the blkcipher layer, we
may enter this code with walk.nbytes == 0, while nbytes > 0. In this
case, we should not dereference the source and destination pointers,
since they may be NULL. So instead of checking for nbytes != 0, check
for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
non-error conditions.
Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
Reported-by: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/aes-ce-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index da3c0428507b..aef022a87c53 100644
--- a/arch/arm/crypto/aes-ce-glue.c
+++ b/arch/arm/crypto/aes-ce-glue.c
@@ -284,7 +284,7 @@ static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
err = blkcipher_walk_done(desc, &walk,
walk.nbytes % AES_BLOCK_SIZE);
}
- if (nbytes) {
+ if (walk.nbytes % AES_BLOCK_SIZE) {
u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
u8 __aligned(8) tail[AES_BLOCK_SIZE];
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] crypto: arm64/aes-ctr: fix NULL dereference in tail processing
From: Ard Biesheuvel @ 2016-09-13 8:48 UTC (permalink / raw)
To: linux-crypto, herbert, linux-arm-kernel; +Cc: xiakaixu, Ard Biesheuvel
In-Reply-To: <1473756533-21078-1-git-send-email-ard.biesheuvel@linaro.org>
The AES-CTR glue code avoids calling into the blkcipher API for the
tail portion of the walk, by comparing the remainder of walk.nbytes
modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
into the tail processing block if they are equal. This tail processing
block checks whether nbytes != 0, and does nothing otherwise.
However, in case of an allocation failure in the blkcipher layer, we
may enter this code with walk.nbytes == 0, while nbytes > 0. In this
case, we should not dereference the source and destination pointers,
since they may be NULL. So instead of checking for nbytes != 0, check
for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
non-error conditions.
Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Reported-by: xiakaixu <xiakaixu@huawei.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 5c888049d061..6b2aa0fd6cd0 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -216,7 +216,7 @@ static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst,
err = blkcipher_walk_done(desc, &walk,
walk.nbytes % AES_BLOCK_SIZE);
}
- if (nbytes) {
+ if (walk.nbytes % AES_BLOCK_SIZE) {
u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
u8 __aligned(8) tail[AES_BLOCK_SIZE];
--
2.7.4
^ permalink raw reply related
* Re: [PATCHv3 06/11] crypto: omap-des: Fix support for unequal lengths
From: Herbert Xu @ 2016-09-13 9:35 UTC (permalink / raw)
To: Tero Kristo
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel, Lokesh Vutla
In-Reply-To: <1470306526-27219-7-git-send-email-t-kristo@ti.com>
On Thu, Aug 04, 2016 at 01:28:41PM +0300, Tero Kristo wrote:
> From: Lokesh Vutla <a0131933@ti.com>
>
> For cases where total length of an input SGs is not same as
> length of the input data for encryption, omap-des driver
> crashes. This happens in the case when IPsec is trying to use
> omap-des driver.
>
> To avoid this, we copy all the pages from the input SG list
> into a contiguous buffer and prepare a single element SG list
> for this buffer with length as the total bytes to crypt, which is
> similar thing that is done in case of unaligned lengths.
Ugh, that means copying every single packet, right?
So if it's just the SG list that's the problem, why don't you
copy that instead? That is, allocate a new SG list and set it
up so that there is no excess data.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 3/8] hwrng: omap - Switch to non-obsolete read API implementation
From: Herbert Xu @ 2016-09-13 9:48 UTC (permalink / raw)
To: Romain Perier
Cc: dsaxena, mpm, Gregory Clement, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas, linux-crypto
In-Reply-To: <20160907155743.6403-4-romain.perier@free-electrons.com>
On Wed, Sep 07, 2016 at 05:57:38PM +0200, Romain Perier wrote:
> +
> +static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
> + bool wait)
> {
> struct omap_rng_dev *priv;
> - int data, i;
>
> priv = (struct omap_rng_dev *)rng->priv;
>
> - for (i = 0; i < 20; i++) {
> - data = priv->pdata->data_present(priv);
> - if (data || !wait)
> - break;
> - /* RNG produces data fast enough (2+ MBit/sec, even
> - * during "rngtest" loads, that these delays don't
> - * seem to trigger. We *could* use the RNG IRQ, but
> - * that'd be higher overhead ... so why bother?
> - */
> - udelay(10);
So in the wait case you're changing the driver's behaviour. Instead
of waiting for 1us you'll now wait for 1s if there is no data. Is
this what really what you want?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC PATCH v1 01/28] kvm: svm: Add support for additional SVM NPF error codes
From: Borislav Petkov @ 2016-09-13 9:56 UTC (permalink / raw)
To: Brijesh Singh
Cc: simon.guinot, linux-efi, kvm, rkrcmar, matt, linus.walleij,
linux-mm, paul.gortmaker, hpa, dan.j.williams, aarcange, sfr,
andriy.shevchenko, herbert, bhe, xemul, joro, x86, mingo, msalter,
ross.zwisler, dyoung, thomas.lendacky, jroedel, keescook,
toshi.kani, mathieu.desnoyers, devel, tglx, mchehab,
iamjoonsoo.kim, labbott, tony.luck, alexandre.bounine,
kuleshovmail, linux-kernel, mcgrof, linux-crypto
In-Reply-To: <147190822443.9523.7814744422402462127.stgit@brijesh-build-machine>
On Mon, Aug 22, 2016 at 07:23:44PM -0400, Brijesh Singh wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> AMD hardware adds two additional bits to aid in nested page fault handling.
>
> Bit 32 - NPF occurred while translating the guest's final physical address
> Bit 33 - NPF occurred while translating the guest page tables
>
> The guest page tables fault indicator can be used as an aid for nested
> virtualization. Using V0 for the host, V1 for the first level guest and
> V2 for the second level guest, when both V1 and V2 are using nested paging
> there are currently a number of unnecessary instruction emulations. When
> V2 is launched shadow paging is used in V1 for the nested tables of V2. As
> a result, KVM marks these pages as RO in the host nested page tables. When
> V2 exits and we resume V1, these pages are still marked RO.
>
> Every nested walk for a guest page table is treated as a user-level write
> access and this causes a lot of NPFs because the V1 page tables are marked
> RO in the V0 nested tables. While executing V1, when these NPFs occur KVM
> sees a write to a read-only page, emulates the V1 instruction and unprotects
> the page (marking it RW). This patch looks for cases where we get a NPF due
> to a guest page table walk where the page was marked RO. It immediately
> unprotects the page and resumes the guest, leading to far fewer instruction
> emulations when nested virtualization is used.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/include/asm/kvm_host.h | 11 ++++++++++-
> arch/x86/kvm/mmu.c | 20 ++++++++++++++++++--
> arch/x86/kvm/svm.c | 2 +-
> 3 files changed, 29 insertions(+), 4 deletions(-)
FWIW: Reviewed-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3] crypto: only call put_page on referenced and used pages
From: Herbert Xu @ 2016-09-13 10:08 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <1794862.SeMhQgguHO@positron.chronox.de>
On Tue, Sep 13, 2016 at 10:18:54AM +0200, Stephan Mueller wrote:
> Am Montag, 12. September 2016, 14:43:45 CEST schrieb Stephan Mueller:
>
> Hi Herbert,
>
> > Hi Herbert,
> >
> > after getting the AIO code working on sendmsg, tried it with vmsplice/splice
> > and I get a memory corruption. Interestingly, the stack trace is partially
> > garbled too. Thus, tracking this one down may be a bit of a challenge.
>
> The issue is a NULL pointer dereference in skcipher_free_async_sgls. The issue is that SGs may not have even a page mapped to them and thus the page entry is NULL.
>
> The following patch fixes the issue and replaces the patch I sent earlier.
This patch appears to be papering over a real bug.
The async path should be exactly the same as the sync path, except
that we don't wait for completion. So the question is why are we
getting this crash here for async but not sync?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: algif_aead: AIO broken with more than one iocb
From: Herbert Xu @ 2016-09-13 10:12 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <6245755.LbXSUvPjJL@positron.chronox.de>
On Sun, Sep 11, 2016 at 04:59:19AM +0200, Stephan Mueller wrote:
> Hi Herbert,
>
> The AIO support for algif_aead is broken when submitting more than one iocb.
> The break happens in aead_recvmsg_async at the following code:
>
> /* ensure output buffer is sufficiently large */
> if (usedpages < outlen)
> goto free;
>
> The reason is that when submitting, say, two iocb, ctx->used contains the
> buffer length for two AEAD operations (as expected). However, the recvmsg code
I don't think we should allow that. We should make it so that you
must start a recvmsg before you can send data for a new request.
Remember that the async path should be identical to the sync path,
except that you don't wait for completion.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Crypto Fixes for 4.8
From: Herbert Xu @ 2016-09-13 10:35 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160905093318.GA30895@gondor.apana.org.au>
Hi Linus:
This push fixes a bug in the cryptd code that may lead to crashes.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Ard Biesheuvel (1):
crypto: cryptd - initialize child shash_desc on import
crypto/cryptd.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] crypto: only call put_page on referenced and used pages
From: Stephan Mueller @ 2016-09-13 11:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160913100816.GA30804@gondor.apana.org.au>
Am Dienstag, 13. September 2016, 18:08:16 CEST schrieb Herbert Xu:
Hi Herbert,
> This patch appears to be papering over a real bug.
>
> The async path should be exactly the same as the sync path, except
> that we don't wait for completion. So the question is why are we
> getting this crash here for async but not sync?
At least one reason is found in skcipher_recvmsg_async with the following code
path:
if (txbufs == tx_nents) {
struct scatterlist *tmp;
int x;
/* Ran out of tx slots in async request
* need to expand */
tmp = kcalloc(tx_nents * 2, sizeof(*tmp),
GFP_KERNEL);
if (!tmp)
goto free;
sg_init_table(tmp, tx_nents * 2);
for (x = 0; x < tx_nents; x++)
sg_set_page(&tmp[x], sg_page(&sreq->tsg[x]),
sreq->tsg[x].length,
sreq->tsg[x].offset);
kfree(sreq->tsg);
sreq->tsg = tmp;
tx_nents *= 2;
mark = true;
}
==> the code allocates twice the amount of the previously existing memory,
copies the existing SGs over, but does not set the remaining SGs to anything.
If the caller provides less pages than the number of allocated SGs, some SGs
are unset. Hence, the deallocation must not do anything with the yet
uninitialized SGs.
Ciao
Stephan
^ permalink raw reply
* Re: algif_aead: AIO broken with more than one iocb
From: Stephan Mueller @ 2016-09-13 11:29 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160913101246.GA30851@gondor.apana.org.au>
Am Dienstag, 13. September 2016, 18:12:46 CEST schrieb Herbert Xu:
Hi Herbert,
> I don't think we should allow that. We should make it so that you
> must start a recvmsg before you can send data for a new request.
>
> Remember that the async path should be identical to the sync path,
> except that you don't wait for completion.
The question is, how does the algif code knows when more than one iocb was
submitted? Note, each iocb is translated into an independent call of the
recvmsg_async.
Ciao
Stephan
^ permalink raw reply
* Re: hwrng: pasemi-rng - Use linux/io.h instead of asm/io.h
From: Michael Ellerman @ 2016-09-13 12:16 UTC (permalink / raw)
To: PrasannaKumar Muralidharan, olof, linuxppc-dev, linux-crypto,
herbert, mpm
Cc: PrasannaKumar Muralidharan
In-Reply-To: <1473150519-30931-1-git-send-email-prasannatsmkumar@gmail.com>
On Tue, 2016-06-09 at 08:28:39 UTC, PrasannaKumar Muralidharan wrote:
> Checkpatch.pl warns about usage of asm/io.h. Use linux/io.h instead.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/63019f3cab99c7acd27df5a5b8
cheers
^ permalink raw reply
* Re: [PATCHv3 00/11] crypto: omap HW crypto fixes
From: Herbert Xu @ 2016-09-13 12:38 UTC (permalink / raw)
To: Tero Kristo
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
On Thu, Aug 04, 2016 at 01:28:35PM +0300, Tero Kristo wrote:
> Hi,
>
> This revision took quite a bit time to craft due to the rework needed
> for sham buffer handling and export/import. I ended up implementing
> a flush functionality for draining out the sham buffer when doing
> export/import; just shrinking the buffer to sufficiently small size
> impacted the performance with small data chunks too much so I dropped
> this approach.
>
> The series also fixes a couple of existing issues with omap2/omap3
> hardware acceleration, I ran a full boot test / crypto manager
> test suite on all boards accessible to me now.
>
> Based on top of latest mainline, which is somewhere before 4.8-rc1
> as of writing this, I am unable to rebase the series during the next
> three weeks so wanted to get this out now. Targeted for 4.9 merge
> window, some fixes could be picked up earlier though if needed.
I have applied patches 1,4-5,7-11. Some of them didn't apply
cleanly so please check the result in my tree.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: pasemi-rng - Use linux/io.h instead of asm/io.h
From: Herbert Xu @ 2016-09-13 12:39 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: olof, linuxppc-dev, linux-crypto, mpm
In-Reply-To: <1473150519-30931-1-git-send-email-prasannatsmkumar@gmail.com>
On Tue, Sep 06, 2016 at 01:58:39PM +0530, PrasannaKumar Muralidharan wrote:
> Checkpatch.pl warns about usage of asm/io.h. Use linux/io.h instead.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 2/2] crypto: qat - fix resource release omissions
From: Herbert Xu @ 2016-09-13 12:40 UTC (permalink / raw)
To: Giovanni Cabiddu
Cc: Quentin Lambert, Salvatore Benedetto, David S. Miller, qat-linux,
linux-crypto, linux-kernel, kernel-janitors, giovanni.cabiddu
In-Reply-To: <20160906101851.GA27032@sivswdev01.ir.intel.com>
On Tue, Sep 06, 2016 at 11:18:51AM +0100, Giovanni Cabiddu wrote:
>
> ---8<---
> Subject: [PATCH] crypto: qat - fix leak on error path
>
> Fix a memory leak in an error path in uc loader.
>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] hwrng: core - Allocate memory during module init
From: Herbert Xu @ 2016-09-13 12:40 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, lee.jones, jslaby, peter, linux-crypto
In-Reply-To: <1473259682-11655-1-git-send-email-prasannatsmkumar@gmail.com>
On Wed, Sep 07, 2016 at 08:18:02PM +0530, PrasannaKumar Muralidharan wrote:
> In core rng_buffer and rng_fillbuf is allocated in hwrng_register only
> once and it is freed during module exit. This patch moves allocating
> rng_buffer and rng_fillbuf from hwrng_register to rng core's init. This
> avoids checking whether rng_buffer and rng_fillbuf was allocated from
> every hwrng_register call. Also moving them to module init makes it
> explicit that it is freed in module exit.
>
> Change in v2:
> Fix memory leak when register_miscdev fails.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: amd-rng - Migrate to managed API
From: Herbert Xu @ 2016-09-13 12:41 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, clabbe.montjoie, linux-crypto
In-Reply-To: <1473407903-12470-1-git-send-email-prasannatsmkumar@gmail.com>
On Fri, Sep 09, 2016 at 01:28:23PM +0530, PrasannaKumar Muralidharan wrote:
> Managed API eliminates error handling code, thus reduces several lines
> of code.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH -next] hwrng: st - Fix missing clk_disable_unprepare() on error in st_rng_probe()
From: Herbert Xu @ 2016-09-13 12:41 UTC (permalink / raw)
To: Wei Yongjun
Cc: Patrice Chotard, Matt Mackall, Wei Yongjun, linux-arm-kernel,
kernel, linux-crypto
In-Reply-To: <1473509022-3478-1-git-send-email-weiyj.lk@gmail.com>
On Sat, Sep 10, 2016 at 12:03:42PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix the missing clk_disable_unprepare() before return
> from st_rng_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: geode-rng - Migrate to managed API
From: Herbert Xu @ 2016-09-13 12:42 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, linux-geode, linux-crypto
In-Reply-To: <1473607401-25873-1-git-send-email-prasannatsmkumar@gmail.com>
On Sun, Sep 11, 2016 at 08:53:21PM +0530, PrasannaKumar Muralidharan wrote:
> Use devm_ioremap and devm_hwrng_register instead of ioremap and
> hwrng_register. This removes error handling code. Also moved code around
> by removing goto statements. This improves code readability.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: geode-rng - Use linux/io.h instead of asm/io.h
From: Herbert Xu @ 2016-09-13 12:42 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, linux-geode, linux-crypto
In-Reply-To: <1473607466-25929-1-git-send-email-prasannatsmkumar@gmail.com>
On Sun, Sep 11, 2016 at 08:54:26PM +0530, PrasannaKumar Muralidharan wrote:
> Fix checkpatch.pl warning by changing from asm/io.h to linux/io.h. In
> the mean time arrange the includes in alphabetical order.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: squash lines for simple wrapper functions
From: Herbert Xu @ 2016-09-13 12:43 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: linux-crypto, linux-kernel, David S. Miller
In-Reply-To: <1473708474-32359-1-git-send-email-yamada.masahiro@socionext.com>
On Tue, Sep 13, 2016 at 04:27:54AM +0900, Masahiro Yamada wrote:
> Remove unneeded variables and assignments.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] crypto: arm/aes-ctr: fix NULL dereference in tail processing
From: Herbert Xu @ 2016-09-13 12:43 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel, xiakaixu
In-Reply-To: <1473756533-21078-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Sep 13, 2016 at 09:48:52AM +0100, Ard Biesheuvel wrote:
> The AES-CTR glue code avoids calling into the blkcipher API for the
> tail portion of the walk, by comparing the remainder of walk.nbytes
> modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight
> into the tail processing block if they are equal. This tail processing
> block checks whether nbytes != 0, and does nothing otherwise.
>
> However, in case of an allocation failure in the blkcipher layer, we
> may enter this code with walk.nbytes == 0, while nbytes > 0. In this
> case, we should not dereference the source and destination pointers,
> since they may be NULL. So instead of checking for nbytes != 0, check
> for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in
> non-error conditions.
>
> Fixes: 86464859cc77 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions")
> Reported-by: xiakaixu <xiakaixu@huawei.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
Both patches applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v7 0/9] crypto: asynchronous compression api
From: Giovanni Cabiddu @ 2016-09-13 12:49 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Giovanni Cabiddu
The following patch set introduces acomp, a generic asynchronous
(de)compression api with support for SG lists.
We propose a new crypto type called crypto_acomp_type, a new struct acomp_alg
and struct crypto_acomp, together with number of helper functions to register
acomp type algorithms and allocate tfm instances.
This interface will allow the following operations:
int (*compress)(struct acomp_req *req);
int (*decompress)(struct acomp_req *req);
Together with acomp we propose a new driver-side interface, scomp, which
targets legacy synchronous implementation. We converted all compression
algorithms available in LKCF to use this interface so that those algos will be
accessible through the acomp api.
Changes in v7:
- removed linearization of SG lists and per-request vmalloc allocations in
scomp layer
- modified scomp internal API to use SG lists
- introduced per-cpu cache of 128K scratch buffers allocated using vmalloc
in legacy scomp algorithms
Changes in v6:
- changed acomp_request_alloc prototype by removing gfp parameter.
acomp_request_alloc will always use GFP_KERNEL
Changes in v5:
- removed qdecompress api, no longer needed
- removed produced and consumed counters in acomp_req
- added crypto_has_acomp function
Changes in v4:
- added qdecompress api, a front-end for decompression algorithms which
do not need additional vmalloc work space
Changes in v3:
- added driver-side scomp interface
- provided support for lzo, lz4, lz4hc, 842, deflate compression algorithms
via the acomp api (through scomp)
- extended testmgr to support acomp
- removed extended acomp api for supporting deflate algorithm parameters
(will be enhanced and re-proposed in future)
Note that (2) to (7) are a rework of Joonsoo Kim's scomp patches.
Changes in v2:
- added compression and decompression request sizes in acomp_alg
in order to enable noctx support
- extended api with helpers to allocate compression and
decompression requests
Changes from initial submit:
- added consumed and produced fields to acomp_req
- extended api to support configuration of deflate compressors
---
Giovanni Cabiddu (9):
crypto: add asynchronous compression api
crypto: add driver-side scomp interface
crypto: scomp - add scratch buffers allocator and deallocator
crypto: acomp - add support for lzo via scomp
crypto: acomp - add support for lz4 via scomp
crypto: acomp - add support for lz4hc via scomp
crypto: acomp - add support for 842 via scomp
crypto: acomp - add support for deflate via scomp
crypto: acomp - update testmgr with support for acomp
crypto/842.c | 135 ++++++++++++++++++-
crypto/Kconfig | 15 ++
crypto/Makefile | 3 +
crypto/acompress.c | 163 ++++++++++++++++++++++
crypto/crypto_user.c | 19 +++
crypto/deflate.c | 166 +++++++++++++++++++++--
crypto/lz4.c | 147 +++++++++++++++++++--
crypto/lz4hc.c | 147 +++++++++++++++++++--
crypto/lzo.c | 146 ++++++++++++++++++--
crypto/scompress.c | 225 +++++++++++++++++++++++++++++++
crypto/testmgr.c | 158 ++++++++++++++++++++--
include/crypto/acompress.h | 253 +++++++++++++++++++++++++++++++++++
include/crypto/internal/acompress.h | 81 +++++++++++
include/crypto/internal/scompress.h | 139 +++++++++++++++++++
include/linux/crypto.h | 3 +
15 files changed, 1742 insertions(+), 58 deletions(-)
create mode 100644 crypto/acompress.c
create mode 100644 crypto/scompress.c
create mode 100644 include/crypto/acompress.h
create mode 100644 include/crypto/internal/acompress.h
create mode 100644 include/crypto/internal/scompress.h
--
1.7.4.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox