* Fwd: [linux-next:master 7274/8070] undefined reference to `crypto_alloc_shash'
From: Stephan Müller @ 2017-04-09 20:09 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, David Howells
Hi Herbert,
I got the attached error report. This is due to CRYPTO_HASH2 is selected as m
whereas security/keys/dh.c is compiled as y. Note CRYPTO_HASH is selected as
y.
dh.c requires shash.
Kconfig for dh.c contains:
config KEY_DH_OPERATIONS
bool "Diffie-Hellman operations on retained keys"
depends on KEYS
select MPILIB
select CRYPTO_HASH
Shall I select CRYPTO_HASH2 instead or in addition to CRYPTO_HASH?
Thanks.
Ciao
Stephan
---------- Weitergeleitete Nachricht ----------
Betreff: [linux-next:master 7274/8070] undefined reference to
`crypto_alloc_shash'
Datum: Donnerstag, 6. April 2017, 10:03:30 CEST
Von: kbuild test robot <fengguang.wu@intel.com>
An: Stephan Mueller <smueller@chronox.de>
Kopie: kbuild-all@01.org, David Howells <dhowells@redhat.com>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
master
head: d203084e692ac2f656cf8c50449f8f90ca7875de
commit: f1c316a3ab9d24df6022682422fe897492f2c0c8 [7274/8070] KEYS: add
SP800-56A KDF support for DH
config: x86_64-randconfig-s0-04061437 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout f1c316a3ab9d24df6022682422fe897492f2c0c8
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
security/built-in.o: In function `__keyctl_dh_compute':
>> (.text+0xa4f7): undefined reference to `crypto_alloc_shash'
security/built-in.o: In function `__keyctl_dh_compute':
>> (.text+0xa7b5): undefined reference to `crypto_shash_update'
security/built-in.o: In function `__keyctl_dh_compute':
(.text+0xa7ed): undefined reference to `crypto_shash_update'
security/built-in.o: In function `__keyctl_dh_compute':
>> (.text+0xa832): undefined reference to `crypto_shash_final'
security/built-in.o: In function `__keyctl_dh_compute':
(.text+0xa881): undefined reference to `crypto_shash_final'
security/built-in.o: In function `__keyctl_dh_compute':
>> (.text+0xa9bd): undefined reference to `crypto_destroy_tfm'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------------------------------------------------------
^ permalink raw reply
* ★雄安新区★ 城市建设及建筑产业博览会 —— 商务部、河北省政府 “5.18”经洽会 [GA3/L100-Z]
From: x9a @ 2017-04-09 23:27 UTC (permalink / raw)
2017第33届中国•廊坊国际经济贸易洽谈会 （简称“5•18”经洽会）
★ 展览时间：
2007年5月18日—21日
★ 展览地点：
廊坊国际会展中心
★ 主办单位：
中华人民共和国商务部
河北省人民政府
★ 承办单位：
商务部投资促进事务局
河北省商务厅
廊坊市人民政府
★ 咨询热线：
4000-680-860（转8144）； 0316—618-6500； 139-1031-8144
★ 在线客服：
邮箱/QQ：12809395#qq.com； 微信：yondexpo； 微博：http://weibo.com/yingdehuizhan
★ 大会简介：
1984年，河北省人民政府举办了首届“河北省利用外资引进技术暨出口商品贸易洽谈会”，该会每年举办一届，会议名称几经变革，由“河北省利用外资引进技术暨出口商品贸易洽谈会”、“河北省经济贸易洽谈会”、“东北亚暨环渤海国际商务节”到“中国•廊坊高新技术与现代服务业投资贸易洽谈会”，最终确定为“中国•廊坊国际经济贸易洽谈会”（简称“5•18”经洽会），会议时间定于每年5月18日。该会于2000年起正式落户廊坊市，2010年经中华人民共和国国务院批准，成为商务部、河北省人民政府共同主办的国家级国际性经济贸易洽谈会，今年将举办第33届。
2016中国•廊坊国际经济贸易洽谈会将贯彻落实党的十八届五中全会和省委八届十二次全会精神，紧紧抓住京津冀协同发展和“一带一路”重大战略机遇，以“创新、协调、绿色、开放、共享”发展理念为指引，以“协同发展、转型发展、创新发展”为主题，以“立足京津冀，面向海内外”为总体定位，围绕产业创新发展和改善生态环境两大合作重点，注重产业对接、项目洽谈和贸易成交，更加突出国际化、专业化和市场化，努力将“5•18”经洽会打造成具有重要影响力的区域性国际投资贸易促进平台。
今年“5•18”经洽会将重点将举办七大类22项活动：一是举办3个高端会议。分别是：京津冀产业创新协同发展高端会议、京津冀开发区创新发展高端会议、京津冀大数据产业发展高端会议。二是举办1个大型新兴产业精品展分为12个展区。分别是：印度尼西亚主宾国展区、加拿大主题展区、大数据产业创新展区、国际电子商务展区、创客和创意空间展区、绿色设计展区、空间信息技术应用成果展区、高端制造业展区、廊坊市新兴产业暨县域特色展区、节能环保产业展区、生物医药展区、健康医疗设备展区。三是举办11场产业专题对接会。分别是：“创新中国”走进廊坊创业大赛、“双创”与金融对接洽谈会、“互联网+天基信息应用”高峰对话、重点园区招商项目对接洽谈会、环保产业项目合作对接会、京津冀现代商贸物流项目对接洽谈会、海外侨商投资合作项目洽谈会、海内外知名商会进河北对接洽谈会、2016乡村旅游发展峰会、京津冀医疗信息化项目对接洽谈会、中国报业旅游联盟第二届大会暨全国百家媒体廊坊行活动。四是举办3场主宾国系列活动。分别是：印度尼西亚主宾国开馆式、中国（河北）—印尼投资商务论坛、中国（河北）—东盟国际产能合作交流会。五是举办开幕式暨欢迎晚宴。六是举办合作项目签约仪式。七是举办2个展销活动。分别是：第十五届品味车苑文化博览会、第六届中国•廊坊婚庆文化博览会。
本届经洽会紧紧抓住京津冀协同发展和“一带一路”重大战略机遇，以“创新、协调、绿色、开放、共享”发展理念为指引，以“协同发展、转型发展、创新 发展”为主题，以“立足京津冀，面向海内外”为总体定位，围绕产业创新发展和改善生态环境两大合作重点，注重产业对接、项目洽谈和贸易成交，更加突出国际 化、专业化和市场化，努力将“5•18”经洽会打造成具有重要影响力的区域性国际投资贸易促进平台。围绕发展优势产业、培育支柱企业，今年的“5•18” 经洽会将举办七大类34项活动，主要是三个高端会议、一个大型贸易展览、十一项专题对接、主宾国活动及签约仪式等系列活动。
一年一度的“5•18”经洽会已经在廊坊走过了17个年头。17年来，“5•18”经洽会因廊坊而日益壮大，规格越来越高，规模越来越大，专业化、市场化、国际化程度不断增强。今年的“5•18”经洽会又增添了许多新亮点、新内容。
★ 三个高端会议分别是：
京津冀产业创新协同发展高端会议、
京津冀开发区创新发展高端会议、
京津冀大数据产业发展高端会议。
★ 二是新兴产业精品展分为12个展区分别是：
大数据产业创新展区、
印度尼西亚主宾国展区、
加拿大主题展区、
国际电子商务展区、
创客和创意空间展区、
绿色设计展区、
空间信息技术应用成果展区、
廊坊市新兴产业暨县域特色展区、
高端制造业展区、
节能环保产业展区、
生物医药展区、
健康医疗设备展区。
★ 三是举办11场产业专题对接会包括：
“创新中国”走进廊坊创业大赛、
“双创”与金融对接洽谈会、
首届中国乡村旅游发展大会、
“互联网+天基信息应用”高峰对话、
重点园区招商项目对接洽谈会、
环保产业项目合作对接会、
京津冀现代商贸物流项目对接洽谈会、
海外侨商投资合作项目洽谈会、
海内外知名商会进河北对接洽谈会、
京津冀医疗信息化项目对接洽谈会、
中国报业旅游联盟第二届大会暨全国百名社长总编看廊坊活动。
★ 四是举办主宾国系列活动：
印度尼西亚主宾国开馆式、
中国（河北）—印尼投资商务论坛、
中国（河北）—东盟国际产能合作交流会等系列活动。
★ 五是举办：
欢迎会暨开幕式。
★ 六是举办2场签约及开工仪式：
合作项目签约仪式、
重点项目开工（奠基）仪式。
★ 七是举办2个展销活动：
第十五届品味车苑文化博览会、
第六届中国•廊坊婚庆文化博览会。
★ 联系方式：
全国统一客服热线： 4000-580-850.（分机：8144、5206或5220）
全国统一报名专线： 4000-680-860.（兼传真）
官方网站： http://www．518.gov．cn
参展顾问： 王先生、 金小姐
参展热线： 131-2662-5206、 139-1031-8144； 010— 8699- 7155、 8084- 2128.
在线客服： QQ/邮箱：12809395#qq.com； 微信/ yondexpo； 微博/ http://weibo.com/yondexpo
〔 映德会展 / 诚邀参加2017年度权威实效品牌盛会﹞
【 公 众 平 台 】
微信： 参展消息 （ID：CanZhanXiaoXi）—— 品牌扩张的平台 市场开拓的桥梁
微信： 展商之家 （ID：ZhanShangZhiJia）—— 为展商提供最佳营地 为阁下营造参展价值
-----------------------------------------------------------------------------------------------------------
百万群发系统|为您发送|如不希望再收到此行业资讯|请回复“退订+518”至邮箱1055800812@qq.com
^ permalink raw reply
* [PATCH] crypto: lz4: fixed decompress function to return error code
From: Myungho Jung @ 2017-04-10 0:34 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, Myungho Jung
Decompress function in LZ4 library is supposed to return an error code or
negative result. But, it returns -1 when any error is detected. Return
error code when the library returns negative value.
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
---
crypto/lz4.c | 2 +-
crypto/lz4hc.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/lz4.c b/crypto/lz4.c
index 71eff9b..2ce2660 100644
--- a/crypto/lz4.c
+++ b/crypto/lz4.c
@@ -97,7 +97,7 @@ static int __lz4_decompress_crypto(const u8 *src, unsigned int slen,
int out_len = LZ4_decompress_safe(src, dst, slen, *dlen);
if (out_len < 0)
- return out_len;
+ return -EINVAL;
*dlen = out_len;
return 0;
diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
index 03a34a8..2be14f0 100644
--- a/crypto/lz4hc.c
+++ b/crypto/lz4hc.c
@@ -98,7 +98,7 @@ static int __lz4hc_decompress_crypto(const u8 *src, unsigned int slen,
int out_len = LZ4_decompress_safe(src, dst, slen, *dlen);
if (out_len < 0)
- return out_len;
+ return -EINVAL;
*dlen = out_len;
return 0;
--
2.7.4
^ permalink raw reply related
* (unknown),
From: archerrp @ 2017-04-10 5:46 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: 3_linux-crypto.zip --]
[-- Type: application/zip, Size: 3600 bytes --]
^ permalink raw reply
* crypto: ahash - Fix EINPROGRESS notification callback
From: Herbert Xu @ 2017-04-10 8:44 UTC (permalink / raw)
To: Linux Crypto Mailing List, Sabrina Dubroca
The ahash API modifies the request's callback function in order
to clean up after itself in some corner cases (unaligned final
and missing finup).
When the request is complete ahash will restore the original
callback and everything is fine. However, when the request gets
an EBUSY on a full queue, an EINPROGRESS callback is made while
the request is still ongoing.
In this case the ahash API will incorrectly call its own callback.
This patch fixes the problem by creating a temporary request
object on the stack which is used to relay EINPROGRESS back to
the original completion function.
This patch also adds code to preserve the original flags value.
Cc: <vger@stable.kernel.org>
Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/ahash.c b/crypto/ahash.c
index e58c497..1810feb 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -32,6 +32,7 @@ struct ahash_request_priv {
crypto_completion_t complete;
void *data;
u8 *result;
+ u32 flags;
void *ubuf[] CRYPTO_MINALIGN_ATTR;
};
@@ -253,6 +254,8 @@ static int ahash_save_req(struct ahash_request *req, crypto_completion_t cplt)
priv->result = req->result;
priv->complete = req->base.complete;
priv->data = req->base.data;
+ priv->flags = req->base.flags;
+
/*
* WARNING: We do not backup req->priv here! The req->priv
* is for internal use of the Crypto API and the
@@ -267,38 +270,44 @@ static int ahash_save_req(struct ahash_request *req, crypto_completion_t cplt)
return 0;
}
-static void ahash_restore_req(struct ahash_request *req)
+static void ahash_restore_req(struct ahash_request *req, int err)
{
struct ahash_request_priv *priv = req->priv;
+ if (!err)
+ memcpy(priv->result, req->result,
+ crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
+
/* Restore the original crypto request. */
req->result = priv->result;
- req->base.complete = priv->complete;
- req->base.data = priv->data;
+
+ ahash_request_set_callback(req, priv->flags,
+ priv->complete, priv->data);
req->priv = NULL;
/* Free the req->priv.priv from the ADJUSTED request. */
kzfree(priv);
}
-static void ahash_op_unaligned_finish(struct ahash_request *req, int err)
+static void ahash_notify_einprogress(struct ahash_request *req)
{
struct ahash_request_priv *priv = req->priv;
+ struct crypto_async_request oreq;
- if (err == -EINPROGRESS)
- return;
+ oreq.data = priv->data;
- if (!err)
- memcpy(priv->result, req->result,
- crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
-
- ahash_restore_req(req);
+ priv->complete(&oreq, -EINPROGRESS);
}
static void ahash_op_unaligned_done(struct crypto_async_request *req, int err)
{
struct ahash_request *areq = req->data;
+ if (err == -EINPROGRESS) {
+ ahash_notify_einprogress(areq);
+ return;
+ }
+
/*
* Restore the original request, see ahash_op_unaligned() for what
* goes where.
@@ -309,7 +318,7 @@ static void ahash_op_unaligned_done(struct crypto_async_request *req, int err)
*/
/* First copy req->result into req->priv.result */
- ahash_op_unaligned_finish(areq, err);
+ ahash_restore_req(areq, err);
/* Complete the ORIGINAL request. */
areq->base.complete(&areq->base, err);
@@ -325,7 +334,12 @@ static int ahash_op_unaligned(struct ahash_request *req,
return err;
err = op(req);
- ahash_op_unaligned_finish(req, err);
+ if (err == -EINPROGRESS ||
+ (err == -EBUSY && (ahash_request_flags(req) &
+ CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ return err;
+
+ ahash_restore_req(req, err);
return err;
}
@@ -360,25 +374,14 @@ int crypto_ahash_digest(struct ahash_request *req)
}
EXPORT_SYMBOL_GPL(crypto_ahash_digest);
-static void ahash_def_finup_finish2(struct ahash_request *req, int err)
+static void ahash_def_finup_done2(struct crypto_async_request *req, int err)
{
- struct ahash_request_priv *priv = req->priv;
+ struct ahash_request *areq = req->data;
if (err == -EINPROGRESS)
return;
- if (!err)
- memcpy(priv->result, req->result,
- crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
-
- ahash_restore_req(req);
-}
-
-static void ahash_def_finup_done2(struct crypto_async_request *req, int err)
-{
- struct ahash_request *areq = req->data;
-
- ahash_def_finup_finish2(areq, err);
+ ahash_restore_req(areq, err);
areq->base.complete(&areq->base, err);
}
@@ -389,11 +392,15 @@ static int ahash_def_finup_finish1(struct ahash_request *req, int err)
goto out;
req->base.complete = ahash_def_finup_done2;
- req->base.flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
+
err = crypto_ahash_reqtfm(req)->final(req);
+ if (err == -EINPROGRESS ||
+ (err == -EBUSY && (ahash_request_flags(req) &
+ CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ return err;
out:
- ahash_def_finup_finish2(req, err);
+ ahash_restore_req(req, err);
return err;
}
@@ -401,7 +408,16 @@ static void ahash_def_finup_done1(struct crypto_async_request *req, int err)
{
struct ahash_request *areq = req->data;
+ if (err == -EINPROGRESS) {
+ ahash_notify_einprogress(areq);
+ return;
+ }
+
+ areq->base.flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
+
err = ahash_def_finup_finish1(areq, err);
+ if (areq->priv)
+ return;
areq->base.complete(&areq->base, err);
}
@@ -416,6 +432,11 @@ static int ahash_def_finup(struct ahash_request *req)
return err;
err = tfm->update(req);
+ if (err == -EINPROGRESS ||
+ (err == -EBUSY && (ahash_request_flags(req) &
+ CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ return err;
+
return ahash_def_finup_finish1(req, err);
}
--
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
* crypto: lrw - Fix use-after-free on EINPROGRESS
From: Herbert Xu @ 2017-04-10 9:15 UTC (permalink / raw)
To: Linux Crypto Mailing List
When we get an EINPROGRESS completion in lrw, we will end up marking
the request as done and freeing it. This then blows up when the
request is really completed as we've already freed the memory.
Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
Cc: <stable@vger.kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/lrw.c b/crypto/lrw.c
index 3ea095a..a8bfae4 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -345,6 +345,13 @@ static void encrypt_done(struct crypto_async_request *areq, int err)
struct rctx *rctx;
rctx = skcipher_request_ctx(req);
+
+ if (err == -EINPROGRESS) {
+ if (rctx->left != req->cryptlen)
+ return;
+ goto out;
+ }
+
subreq = &rctx->subreq;
subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;
@@ -352,6 +359,7 @@ static void encrypt_done(struct crypto_async_request *areq, int err)
if (rctx->left)
return;
+out:
skcipher_request_complete(req, err);
}
@@ -389,6 +397,13 @@ static void decrypt_done(struct crypto_async_request *areq, int err)
struct rctx *rctx;
rctx = skcipher_request_ctx(req);
+
+ if (err == -EINPROGRESS) {
+ if (rctx->left != req->cryptlen)
+ return;
+ goto out;
+ }
+
subreq = &rctx->subreq;
subreq->base.flags &= CRYPTO_TFM_REQ_MAY_BACKLOG;
@@ -396,6 +411,7 @@ static void decrypt_done(struct crypto_async_request *areq, int err)
if (rctx->left)
return;
+out:
skcipher_request_complete(req, err);
}
--
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: crypto: ahash - Fix EINPROGRESS notification callback
From: Sabrina Dubroca @ 2017-04-10 9:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linux Crypto Mailing List
In-Reply-To: <20170410084450.GA7533@gondor.apana.org.au>
2017-04-10, 16:44:50 +0800, Herbert Xu wrote:
> The ahash API modifies the request's callback function in order
> to clean up after itself in some corner cases (unaligned final
> and missing finup).
>
> When the request is complete ahash will restore the original
> callback and everything is fine. However, when the request gets
> an EBUSY on a full queue, an EINPROGRESS callback is made while
> the request is still ongoing.
>
> In this case the ahash API will incorrectly call its own callback.
>
> This patch fixes the problem by creating a temporary request
> object on the stack which is used to relay EINPROGRESS back to
> the original completion function.
>
> This patch also adds code to preserve the original flags value.
>
> Cc: <vger@stable.kernel.org>
Should that be stable@vger.kernel.org?
> Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The definition of ahash_request_flags() was missing, so I added:
static inline u32 ahash_request_flags(struct ahash_request *req)
{
return req->base.flags;
}
And with this, my tests seem fine.
Tested-by: Sabrina Dubroca <sd@queasysnail.net>
Could also you change the 'Reported-by:' to that email address?
Thanks,
--
Sabrina
^ permalink raw reply
* [PATCH v2] crypto: ahash - Fix EINPROGRESS notification callback
From: Herbert Xu @ 2017-04-10 9:27 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: Linux Crypto Mailing List
In-Reply-To: <20170410092127.GA24816@bistromath.localdomain>
On Mon, Apr 10, 2017 at 11:21:27AM +0200, Sabrina Dubroca wrote:
>
> > Cc: <vger@stable.kernel.org>
>
> Should that be stable@vger.kernel.org?
Oops :)
> > Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> The definition of ahash_request_flags() was missing, so I added:
>
> static inline u32 ahash_request_flags(struct ahash_request *req)
> {
> return req->base.flags;
> }
>
> And with this, my tests seem fine.
>
> Tested-by: Sabrina Dubroca <sd@queasysnail.net>
> Could also you change the 'Reported-by:' to that email address?
OK, here is v2.
---8<---
The ahash API modifies the request's callback function in order
to clean up after itself in some corner cases (unaligned final
and missing finup).
When the request is complete ahash will restore the original
callback and everything is fine. However, when the request gets
an EBUSY on a full queue, an EINPROGRESS callback is made while
the request is still ongoing.
In this case the ahash API will incorrectly call its own callback.
This patch fixes the problem by creating a temporary request
object on the stack which is used to relay EINPROGRESS back to
the original completion function.
This patch also adds code to preserve the original flags value.
Fixes: ab6bf4e5e5e4 ("crypto: hash - Fix the pointer voodoo in...")
Cc: <stable@vger.kernel.org>
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Tested-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/ahash.c b/crypto/ahash.c
index e58c497..1810feb 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -32,6 +32,7 @@ struct ahash_request_priv {
crypto_completion_t complete;
void *data;
u8 *result;
+ u32 flags;
void *ubuf[] CRYPTO_MINALIGN_ATTR;
};
@@ -253,6 +254,8 @@ static int ahash_save_req(struct ahash_request *req, crypto_completion_t cplt)
priv->result = req->result;
priv->complete = req->base.complete;
priv->data = req->base.data;
+ priv->flags = req->base.flags;
+
/*
* WARNING: We do not backup req->priv here! The req->priv
* is for internal use of the Crypto API and the
@@ -267,38 +270,44 @@ static int ahash_save_req(struct ahash_request *req, crypto_completion_t cplt)
return 0;
}
-static void ahash_restore_req(struct ahash_request *req)
+static void ahash_restore_req(struct ahash_request *req, int err)
{
struct ahash_request_priv *priv = req->priv;
+ if (!err)
+ memcpy(priv->result, req->result,
+ crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
+
/* Restore the original crypto request. */
req->result = priv->result;
- req->base.complete = priv->complete;
- req->base.data = priv->data;
+
+ ahash_request_set_callback(req, priv->flags,
+ priv->complete, priv->data);
req->priv = NULL;
/* Free the req->priv.priv from the ADJUSTED request. */
kzfree(priv);
}
-static void ahash_op_unaligned_finish(struct ahash_request *req, int err)
+static void ahash_notify_einprogress(struct ahash_request *req)
{
struct ahash_request_priv *priv = req->priv;
+ struct crypto_async_request oreq;
- if (err == -EINPROGRESS)
- return;
+ oreq.data = priv->data;
- if (!err)
- memcpy(priv->result, req->result,
- crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
-
- ahash_restore_req(req);
+ priv->complete(&oreq, -EINPROGRESS);
}
static void ahash_op_unaligned_done(struct crypto_async_request *req, int err)
{
struct ahash_request *areq = req->data;
+ if (err == -EINPROGRESS) {
+ ahash_notify_einprogress(areq);
+ return;
+ }
+
/*
* Restore the original request, see ahash_op_unaligned() for what
* goes where.
@@ -309,7 +318,7 @@ static void ahash_op_unaligned_done(struct crypto_async_request *req, int err)
*/
/* First copy req->result into req->priv.result */
- ahash_op_unaligned_finish(areq, err);
+ ahash_restore_req(areq, err);
/* Complete the ORIGINAL request. */
areq->base.complete(&areq->base, err);
@@ -325,7 +334,12 @@ static int ahash_op_unaligned(struct ahash_request *req,
return err;
err = op(req);
- ahash_op_unaligned_finish(req, err);
+ if (err == -EINPROGRESS ||
+ (err == -EBUSY && (ahash_request_flags(req) &
+ CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ return err;
+
+ ahash_restore_req(req, err);
return err;
}
@@ -360,25 +374,14 @@ int crypto_ahash_digest(struct ahash_request *req)
}
EXPORT_SYMBOL_GPL(crypto_ahash_digest);
-static void ahash_def_finup_finish2(struct ahash_request *req, int err)
+static void ahash_def_finup_done2(struct crypto_async_request *req, int err)
{
- struct ahash_request_priv *priv = req->priv;
+ struct ahash_request *areq = req->data;
if (err == -EINPROGRESS)
return;
- if (!err)
- memcpy(priv->result, req->result,
- crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
-
- ahash_restore_req(req);
-}
-
-static void ahash_def_finup_done2(struct crypto_async_request *req, int err)
-{
- struct ahash_request *areq = req->data;
-
- ahash_def_finup_finish2(areq, err);
+ ahash_restore_req(areq, err);
areq->base.complete(&areq->base, err);
}
@@ -389,11 +392,15 @@ static int ahash_def_finup_finish1(struct ahash_request *req, int err)
goto out;
req->base.complete = ahash_def_finup_done2;
- req->base.flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
+
err = crypto_ahash_reqtfm(req)->final(req);
+ if (err == -EINPROGRESS ||
+ (err == -EBUSY && (ahash_request_flags(req) &
+ CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ return err;
out:
- ahash_def_finup_finish2(req, err);
+ ahash_restore_req(req, err);
return err;
}
@@ -401,7 +408,16 @@ static void ahash_def_finup_done1(struct crypto_async_request *req, int err)
{
struct ahash_request *areq = req->data;
+ if (err == -EINPROGRESS) {
+ ahash_notify_einprogress(areq);
+ return;
+ }
+
+ areq->base.flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
+
err = ahash_def_finup_finish1(areq, err);
+ if (areq->priv)
+ return;
areq->base.complete(&areq->base, err);
}
@@ -416,6 +432,11 @@ static int ahash_def_finup(struct ahash_request *req)
return err;
err = tfm->update(req);
+ if (err == -EINPROGRESS ||
+ (err == -EBUSY && (ahash_request_flags(req) &
+ CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ return err;
+
return ahash_def_finup_finish1(req, err);
}
diff --git a/include/crypto/internal/hash.h b/include/crypto/internal/hash.h
index 1d4f365..f6d9af3e 100644
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -166,6 +166,16 @@ static inline struct ahash_instance *ahash_alloc_instance(
return crypto_alloc_instance2(name, alg, ahash_instance_headroom());
}
+static inline void ahash_request_complete(struct ahash_request *req, int err)
+{
+ req->base.complete(&req->base, err);
+}
+
+static inline u32 ahash_request_flags(struct ahash_request *req)
+{
+ return req->base.flags;
+}
+
static inline struct crypto_ahash *crypto_spawn_ahash(
struct crypto_ahash_spawn *spawn)
{
--
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: [PATCH v2] crypto: ahash - Fix EINPROGRESS notification callback
From: Sabrina Dubroca @ 2017-04-10 9:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: Linux Crypto Mailing List
In-Reply-To: <20170410092757.GA7750@gondor.apana.org.au>
2017-04-10, 17:27:57 +0800, Herbert Xu wrote:
> On Mon, Apr 10, 2017 at 11:21:27AM +0200, Sabrina Dubroca wrote:
> >
> > > Cc: <vger@stable.kernel.org>
> >
> > Should that be stable@vger.kernel.org?
>
> Oops :)
>
> > > Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
> > > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> >
> > The definition of ahash_request_flags() was missing, so I added:
> >
> > static inline u32 ahash_request_flags(struct ahash_request *req)
> > {
> > return req->base.flags;
> > }
> >
> > And with this, my tests seem fine.
> >
> > Tested-by: Sabrina Dubroca <sd@queasysnail.net>
> > Could also you change the 'Reported-by:' to that email address?
>
> OK, here is v2.
I did a quick rebuild+test, seems fine. Thanks!
--
Sabrina
^ permalink raw reply
* Re: [PATCH 0/7] arm64: marvell: add cryptographic engine support for 7k/8k
From: Herbert Xu @ 2017-04-10 9:39 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, jason, andrew, gregory.clement, sebastian.hesselbarth,
linux-crypto, linux-arm-kernel, thomas.petazzoni, boris.brezillon,
oferh, igall, nadavh
In-Reply-To: <20170329124432.27457-1-antoine.tenart@free-electrons.com>
On Wed, Mar 29, 2017 at 02:44:25PM +0200, Antoine Tenart wrote:
> Hi all,
>
> This series adds support for the Inside Secure SafeXcel EIP197
> cryptographic engine which can be found on Marvell Armada 7k and 8k
> boards. A new cryptographic engine driver is added, as well as the
> relevant device tree definition for the Armada 7040 DB and 8040 DB
> boards.
>
> This driver needs two firmwares to work correctly. These firmware are
> usually used for more advanced operations than the ones supported (as of
> now), but we still need them to pass the data to the internal
> cryptographic engine.
>
> This series was tested in various ways on both the Armada 7040 DB and
> the Armada 8040 DB: using the crypto framework self tests, using tcrypt
> and while performing various transfers with iperf on top of IPsec.
>
> This series is based on top of v4.11-rc1, and is available on a branch
> (which also contains the PPv2 support for 7k/8k, to ease the process of
> testing IPsec): https://github.com/atenart/linux v4.11-rc1/7k8k-crypto
> I can rebase if needed.
>
> Thanks,
> Antoine
>
>
> Antoine Tenart (7):
> Documentation/bindings: Document the SafeXel cryptographic engine
> driver
> crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
> MAINTAINERS: add a maintainer for the Inside Secure crypto driver
> arm64: marvell: dts: add crypto engine description for 7k/8k
> arm64: marvell: dts: enable the crypto engine on the Armada 7040 DB
> arm64: marvell: dts: enable the crypto engine on the Armada 8040 DB
> arm64: defconfig: enable the Safexcel crypto engine as a module
I have no problems with the crypto bits.
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
* crypto: algif_aead - Fix bogus request dereference in completion function
From: Herbert Xu @ 2017-04-10 9:59 UTC (permalink / raw)
To: Linux Crypto Mailing List
The algif_aead completion function tries to deduce the aead_request
from the crypto_async_request argument. This is broken because
the API does not guarantee that the same request will be pased to
the completion function. Only the value of req->data can be used
in the completion function.
This patch fixes it by storing a pointer to sk in areq and using
that instead of passing in sk through req->data.
Fixes: 83094e5e9e49 ("crypto: af_alg - add async support to...")
Cc: <stable@vger.kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 5a80537..ef59d99 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -40,6 +40,7 @@ struct aead_async_req {
struct aead_async_rsgl first_rsgl;
struct list_head list;
struct kiocb *iocb;
+ struct sock *sk;
unsigned int tsgls;
char iv[];
};
@@ -379,12 +380,10 @@ static ssize_t aead_sendpage(struct socket *sock, struct page *page,
static void aead_async_cb(struct crypto_async_request *_req, int err)
{
- struct sock *sk = _req->data;
- struct alg_sock *ask = alg_sk(sk);
- struct aead_ctx *ctx = ask->private;
- struct crypto_aead *tfm = crypto_aead_reqtfm(&ctx->aead_req);
- struct aead_request *req = aead_request_cast(_req);
+ struct aead_request *req = _req->data;
+ struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct aead_async_req *areq = GET_ASYM_REQ(req, tfm);
+ struct sock *sk = areq->sk;
struct scatterlist *sg = areq->tsgl;
struct aead_async_rsgl *rsgl;
struct kiocb *iocb = areq->iocb;
@@ -447,11 +446,12 @@ static int aead_recvmsg_async(struct socket *sock, struct msghdr *msg,
memset(&areq->first_rsgl, '\0', sizeof(areq->first_rsgl));
INIT_LIST_HEAD(&areq->list);
areq->iocb = msg->msg_iocb;
+ areq->sk = sk;
memcpy(areq->iv, ctx->iv, crypto_aead_ivsize(tfm));
aead_request_set_tfm(req, tfm);
aead_request_set_ad(req, ctx->aead_assoclen);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
- aead_async_cb, sk);
+ aead_async_cb, req);
used -= ctx->aead_assoclen;
/* take over all tx sgls from ctx */
--
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: [PATCH v4 2/2] crypto: hw_random - Add new Exynos RNG driver
From: Bartlomiej Zolnierkiewicz @ 2017-04-10 10:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, James Hogan, Herbert Xu, Greg Kroah-Hartman,
PrasannaKumar Muralidharan, Bernie Thompson, dri-devel,
linux-kernel, Javier Martinez Canillas, linux-metag, Kukjin Kim,
Stephan Müller, linux-crypto, linux-fbdev, Matt Mackall,
Dave Airlie, David S. Miller, linux-arm-kernel
In-Reply-To: <20170408133245.30147-3-krzk@kernel.org>
Hi,
On Saturday, April 08, 2017 03:32:45 PM Krzysztof Kozlowski wrote:
> Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
> This is a driver for pseudo random number generator block which on
> Exynos4 chipsets must be seeded with some value. On newer Exynos5420
> chipsets it might seed itself from true random number generator block
> but this is not implemented yet.
>
> New driver is a complete rework to use the crypto ALGAPI instead of
> hw_random API. Rationale for the change:
> 1. hw_random interface is for true RNG devices.
> 2. The old driver was seeding itself with jiffies which is not a
> reliable source for randomness.
> 3. Device generates five random 32-bit numbers in each pass but old
> driver was returning only one 32-bit number thus its performance was
> reduced.
>
> Compatibility with DeviceTree bindings is preserved.
>
> New driver does not use runtime power management but manually enables
> and disables the clock when needed. This is preferred approach because
> using runtime PM just to toggle clock is huge overhead.
>
> Another difference is reseeding itself with generated random data
> periodically and during resuming from system suspend (previously driver
> was re-seeding itself again with jiffies).
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reviewed-by: Stephan Müller <smueller@chronox.de>
> Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Fwd: [linux-next:master 7274/8070] undefined reference to `crypto_alloc_shash'
From: Herbert Xu @ 2017-04-10 10:22 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto, David Howells
In-Reply-To: <1827882.yksAJm9a6v@positron.chronox.de>
On Sun, Apr 09, 2017 at 10:09:54PM +0200, Stephan Müller wrote:
> Hi Herbert,
>
> I got the attached error report. This is due to CRYPTO_HASH2 is selected as m
> whereas security/keys/dh.c is compiled as y. Note CRYPTO_HASH is selected as
> y.
Hmm that's weird because CRYPTO_HASH selects CRYPTO_HASH2. Do
you have a kconfig file that reproduces this?
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: authenc: crash if key is not set
From: Herbert Xu @ 2017-04-10 10:41 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <13796038.esLDiIrSPd@positron.chronox.de>
On Fri, Feb 24, 2017 at 09:24:34PM +0100, Stephan Müller wrote:
> Hi Herbert,
>
> I am working on fuzzing the AF_ALG interface.
>
> The fuzzer reliably triggered the following type of bug when I use
> authenc(hmac(sha256),cbc(aes)) or other types of authenc() but do not call
> setkey.
>
> Note, it works with gcm or ccm.
>
> Is that bug similar in nature as the algif_skcipher and algif_hash bugs that
> were fixed with the *nokey functions?
Yes we need to add the same thing to AEAD.
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 v6 1/2] crypto: skcipher AF_ALG - overhaul memory management
From: Herbert Xu @ 2017-04-10 10:43 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <1663859.jv2e0HPzin@positron.chronox.de>
On Sat, Apr 01, 2017 at 10:52:30PM +0200, Stephan Müller wrote:
>
> lock_sock(sk);
> - while (msg_data_left(msg)) {
> - if (!ctx->used) {
> - err = skcipher_wait_for_data(sk, flags);
> - if (err)
> - goto unlock;
> + while (iov_iter_count(&msg->msg_iter)) {
Please keep it as msg_data_left.
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: Fwd: [linux-next:master 7274/8070] undefined reference to `crypto_alloc_shash'
From: Stephan Müller @ 2017-04-10 10:46 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, David Howells
In-Reply-To: <20170410102223.GA8340@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 231 bytes --]
Am Montag, 10. April 2017, 12:22:23 CEST schrieb Herbert Xu:
Hi Herbert,
> Hmm that's weird because CRYPTO_HASH selects CRYPTO_HASH2. Do
> you have a kconfig file that reproduces this?
Please see attached.
Thanks
Ciao
Stephan
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25410 bytes --]
^ permalink raw reply
* Re: authenc: crash if key is not set
From: Stephan Müller @ 2017-04-10 10:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170410104125.GA8427@gondor.apana.org.au>
Am Montag, 10. April 2017, 12:41:25 CEST schrieb Herbert Xu:
Hi Herbert,
> >
> > Is that bug similar in nature as the algif_skcipher and algif_hash bugs
> > that were fixed with the *nokey functions?
>
> Yes we need to add the same thing to AEAD.
May I ask that we agree on the memory management fix prior to handling this
issue? When consolidating the common code, I plan to have common code for the
nokey logic which then is automatically applicable to aead too.
Thanks.
Ciao
Stephan
^ permalink raw reply
* Re: authenc: crash if key is not set
From: Herbert Xu @ 2017-04-10 10:54 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <6053931.eUnbK4IiOn@tauon.chronox.de>
On Mon, Apr 10, 2017 at 12:49:16PM +0200, Stephan Müller wrote:
>
> May I ask that we agree on the memory management fix prior to handling this
> issue? When consolidating the common code, I plan to have common code for the
> nokey logic which then is automatically applicable to aead too.
I think we should fix this first. Mixing this with the other
issue is going to make backporting harder.
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 v6 1/2] crypto: skcipher AF_ALG - overhaul memory management
From: Stephan Müller @ 2017-04-10 10:54 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170410104333.GB8427@gondor.apana.org.au>
Am Montag, 10. April 2017, 12:43:33 CEST schrieb Herbert Xu:
Hi Herbert,
> On Sat, Apr 01, 2017 at 10:52:30PM +0200, Stephan Müller wrote:
> > lock_sock(sk);
> >
> > - while (msg_data_left(msg)) {
> > - if (!ctx->used) {
> > - err = skcipher_wait_for_data(sk, flags);
> > - if (err)
> > - goto unlock;
> > + while (iov_iter_count(&msg->msg_iter)) {
>
> Please keep it as msg_data_left.
Shall I apply the algif_aead patch on top of your patch just sent to stable?
Thanks.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v4 2/2] crypto: hw_random - Add new Exynos RNG driver
From: Herbert Xu @ 2017-04-10 10:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: James Hogan, Matt Mackall, Kukjin Kim, Javier Martinez Canillas,
David S. Miller, Dave Airlie, David Airlie, Bernie Thompson,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
PrasannaKumar Muralidharan, linux-kernel, linux-metag,
linux-crypto, linux-arm-kernel, linux-samsung-soc, dri-devel,
linux-fbdev, Stephan Müller
In-Reply-To: <20170408133245.30147-3-krzk@kernel.org>
On Sat, Apr 08, 2017 at 03:32:45PM +0200, Krzysztof Kozlowski wrote:
>
> +static struct rng_alg exynos_rng_alg = {
> + .generate = exynos_rng_generate,
> + .seed = exynos_rng_seed,
> + .seedsize = EXYNOS_RNG_SEED_SIZE,
> + .base = {
> + .cra_name = "exynos_rng",
Please use stdrng. Or is there a reason why this can't be used
by the crypto layer itself?
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 v6 1/2] crypto: skcipher AF_ALG - overhaul memory management
From: Herbert Xu @ 2017-04-10 10:56 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <1936619.vexBXQoksL@tauon.chronox.de>
On Mon, Apr 10, 2017 at 12:54:58PM +0200, Stephan Müller wrote:
> Am Montag, 10. April 2017, 12:43:33 CEST schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Sat, Apr 01, 2017 at 10:52:30PM +0200, Stephan Müller wrote:
> > > lock_sock(sk);
> > >
> > > - while (msg_data_left(msg)) {
> > > - if (!ctx->used) {
> > > - err = skcipher_wait_for_data(sk, flags);
> > > - if (err)
> > > - goto unlock;
> > > + while (iov_iter_count(&msg->msg_iter)) {
> >
> > Please keep it as msg_data_left.
>
> Shall I apply the algif_aead patch on top of your patch just sent to stable?
It doesn't really matter. I'll figure it out when I apply it.
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
* Crypto Fixes for 4.11
From: Herbert Xu @ 2017-04-10 11:04 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20170331102907.GA11348@gondor.apana.org.au>
Hi Linus:
This push fixes a number of bugs in the caam driver:
- Device creation fails after release.
- Error-path NULL-pointer dereference.
- Spurious hardware error in RNG deinstantiation.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Horia Geantă (3):
crypto: caam - fix JR platform device subsequent (re)creations
crypto: caam - fix invalid dereference in caam_rsa_init_tfm()
crypto: caam - fix RNG deinstantiation error checking
drivers/crypto/caam/caampkc.c | 2 +-
drivers/crypto/caam/ctrl.c | 66 +++++++++++++----------------------------
drivers/crypto/caam/intern.h | 1 -
3 files changed, 22 insertions(+), 47 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 v2 0/3] hw_random: timeriomem_rng: Migrate to new API and improve performance
From: Herbert Xu @ 2017-04-10 11:22 UTC (permalink / raw)
To: Rick Altherr; +Cc: alex, openbmc, Matt Mackall, linux-crypto, linux-kernel
In-Reply-To: <20170405232100.2023-1-raltherr@google.com>
On Wed, Apr 05, 2017 at 04:20:57PM -0700, Rick Altherr wrote:
> AST2400 can generate 32-bits of random data every 1us. Original driver
> was limited to one 32-bit read every jiffie due to deprecated API and use
> of timers. Migrating to new hwrng API and switching to hrtimers
> improves read performance of /dev/hwrng to 13Mb/s.
>
> Changes in v2:
> - Split API migration into separate patch
> - Split type and variable renames into separate patch
> - Split performance improvements into separate patch
All 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] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT
From: Herbert Xu @ 2017-04-10 11:22 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Ard Biesheuvel, Greg Hackmann, David S . Miller, Catalin Marinas,
Will Deacon, Robin Murphy, linux-kernel, linux-crypto,
linux-arm-kernel, Grant Grundler, Michael Davidson
In-Reply-To: <20170405183458.193068-1-mka@chromium.org>
On Wed, Apr 05, 2017 at 11:34:58AM -0700, Matthias Kaehlcke wrote:
> The operand is an integer constant, make the constness explicit by
> adding the modifier. This is needed for clang to generate valid code
> and also works with gcc.
>
> Also change the constraint of the operand from 'I' ("Integer constant
> that is valid as an immediate operand in an ADD instruction", AArch64)
> to 'i' ("An immediate integer operand").
>
> Based-on-patch-from: Greg Hackmann <ghackmann@google.com>
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
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: lz4: fixed decompress function to return error code
From: Herbert Xu @ 2017-04-10 11:23 UTC (permalink / raw)
To: Myungho Jung; +Cc: linux-crypto
In-Reply-To: <1491784462-31424-1-git-send-email-mhjungk@gmail.com>
On Sun, Apr 09, 2017 at 05:34:22PM -0700, Myungho Jung wrote:
> Decompress function in LZ4 library is supposed to return an error code or
> negative result. But, it returns -1 when any error is detected. Return
> error code when the library returns negative value.
>
> Signed-off-by: Myungho Jung <mhjungk@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
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