* [PATCH v2 3/5] ARM: dts: stm32: Add CRC support to stm32f746
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
Add CRC (CRC32 crypto) support to stm32f746.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
arch/arm/boot/dts/stm32f746.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index f321ffe..755fb92 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -289,6 +289,13 @@
};
};
+ crc: crc@40023000 {
+ compatible = "st,stm32f7-crc";
+ reg = <0x40023000 0x400>;
+ clocks = <&rcc 0 12>;
+ status = "disabled";
+ };
+
rcc: rcc@40023800 {
#clock-cells = <2>;
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/5] ARM: dts: stm32: enable CRC on stm32746g-eval board
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
Enable the CRC (CRC32 crypto) on stm32746g-eval board
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
arch/arm/boot/dts/stm32746g-eval.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32746g-eval.dts b/arch/arm/boot/dts/stm32746g-eval.dts
index aa03fac..0dc18a0 100644
--- a/arch/arm/boot/dts/stm32746g-eval.dts
+++ b/arch/arm/boot/dts/stm32746g-eval.dts
@@ -89,6 +89,10 @@
clock-frequency = <25000000>;
};
+&crc {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/5] ARM: configs: stm32: Add crypto support
From: Fabien Dessenne @ 2017-03-21 15:13 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Maxime Coquelin, Alexandre Torgue, Russell King, linux-crypto,
devicetree, linux-arm-kernel
Cc: Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
Add STM32 crypto support in stm32_defconfig file.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
arch/arm/configs/stm32_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index a9d8e3c..03437f8 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -75,5 +75,7 @@ CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_FTRACE is not set
+CONFIG_CRYPTO=y
+CONFIG_CRYPTO_DEV_STM32=y
CONFIG_CRC_ITU_T=y
CONFIG_CRC7=y
--
2.7.4
^ permalink raw reply related
* [PATCH 1/1] crypto: If two strings are exact match, they must have same length.
From: Ming Ma @ 2017-03-21 21:40 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, linux-kernel, Ming Ma
When both "crct10dif-pclmul" algorithm and "crct10dif-generic" algorithm
exist in crypto_alg_list, "crct10dif-pclmul" should be selected, since it
has higher priority than "crct10dif-generic". However, both algorithms
have the same cra_name "crct10dif". If we use "crct10dif" to find a
matched algorithm in crypto_alg_list, it's possible "crct10dif-generic" is
selected, because the code calls strcmp to decide if two string are exact
match, but doesn't check if two strings have the same length.
exact = !strcmp(q->cra_driver_name, name);
So ,if "crct10dif-generic" is in front of "crct10dif-pclmul" in
crypto_alg_list, it will be picked as the matched algorithm, even if it has
lower priority than "crct10dif-pclmul".
Signed-off-by: Ming Ma <mingma@micron.com>
---
crypto/api.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/api.c b/crypto/api.c
index b16ce16..5b3d45a 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -76,7 +76,8 @@ static struct crypto_alg *__crypto_alg_lookup(const char *name, u32 type,
((struct crypto_larval *)q)->mask != mask)
continue;
- exact = !strcmp(q->cra_driver_name, name);
+ exact = (strlen(name) == strlen(q->cra_driver_name)) &&
+ !strcmp(q->cra_driver_name, name);
fuzzy = !strcmp(q->cra_name, name);
if (!exact && !(fuzzy && q->cra_priority > best))
continue;
--
2.4.11
^ permalink raw reply related
* Re: [PATCH 1/1] crypto: If two strings are exact match, they must have same length.
From: Herbert Xu @ 2017-03-22 3:00 UTC (permalink / raw)
To: Ming Ma; +Cc: davem, linux-crypto, linux-kernel
In-Reply-To: <1490132440-112761-1-git-send-email-mingma@micron.com>
On Tue, Mar 21, 2017 at 04:40:40PM -0500, Ming Ma wrote:
> When both "crct10dif-pclmul" algorithm and "crct10dif-generic" algorithm
> exist in crypto_alg_list, "crct10dif-pclmul" should be selected, since it
> has higher priority than "crct10dif-generic". However, both algorithms
> have the same cra_name "crct10dif". If we use "crct10dif" to find a
> matched algorithm in crypto_alg_list, it's possible "crct10dif-generic" is
> selected, because the code calls strcmp to decide if two string are exact
> match, but doesn't check if two strings have the same length.
>
> exact = !strcmp(q->cra_driver_name, name);
>
> So ,if "crct10dif-generic" is in front of "crct10dif-pclmul" in
> crypto_alg_list, it will be picked as the matched algorithm, even if it has
> lower priority than "crct10dif-pclmul".
> Signed-off-by: Ming Ma <mingma@micron.com>
> ---
> crypto/api.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/api.c b/crypto/api.c
> index b16ce16..5b3d45a 100644
> --- a/crypto/api.c
> +++ b/crypto/api.c
> @@ -76,7 +76,8 @@ static struct crypto_alg *__crypto_alg_lookup(const char *name, u32 type,
> ((struct crypto_larval *)q)->mask != mask)
> continue;
>
> - exact = !strcmp(q->cra_driver_name, name);
> + exact = (strlen(name) == strlen(q->cra_driver_name)) &&
> + !strcmp(q->cra_driver_name, name);
> fuzzy = !strcmp(q->cra_name, name);
> if (!exact && !(fuzzy && q->cra_priority > best))
> continue;
This is bogus. Please describe how you reproduced the problem.
The priority matching should work.
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: BUG: Seems un-initialed dst pointer received from algif_aead when outlen is zero
From: Herbert Xu @ 2017-03-22 2:57 UTC (permalink / raw)
To: Stephan Müller; +Cc: Harsh Jain, linux-crypto
In-Reply-To: <1593289.epxWzXFfWH@positron.chronox.de>
On Tue, Mar 21, 2017 at 04:00:04PM +0100, Stephan Müller wrote:
> Am Dienstag, 21. März 2017, 14:23:31 CET schrieb Harsh Jain:
>
> Hi Harsh,
>
> > Yes, Driver can figure out when to discard dst SGL but for that Driver
> > has to put checks before accessing dst SGL. Isn't better if AF_ALG
> > sends NULL for dst SGL.
>
> With the code in [1], the first longer patch is planned to be merged after the
> memory management changes are agreed upon. That patch contains:
>
> + /* chain the areq TX SGL holding the tag with RX SGL */
> + if (!last_rsgl) {
> + /* no RX SGL present (e.g. only authentication) */
> + sg_init_table(areq->first_rsgl.sgl.sg, 2);
> + sg_chain(areq->first_rsgl.sgl.sg, 2, areq->tsgl);
> + } else {
> + /* RX SGL present */
> + struct af_alg_sgl *sgl_prev = &last_rsgl->sgl;
> +
> + sg_unmark_end(sgl_prev->sg + sgl_prev->npages - 1);
> + sg_chain(sgl_prev->sg, sgl_prev->npages + 1, areq-
> >tsgl);
> + }
>
>
> This code snipped would exactly do what you want: the SGL is always
> initialized. Besides, the code will do an in-place cipher operation.
>
> https://www.spinics.net/lists/linux-crypto/msg24343.html
Even if we fix this one user of the crypto API, new users could
still feed you bogus SG lists. The API does not require the user
to specify a NULL SG list so please fix this in the driver.
We should also strength testmgr so that it provides something
bogus to catch buggy drivers.
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] arm64: dts: ls1012a: add crypto node
From: Horia Geantă @ 2017-03-22 12:29 UTC (permalink / raw)
To: Shawn Guo, Rob Herring, Mark Rutland
Cc: devicetree, Herbert Xu, Harninder Rai, Catalin Marinas,
Bhaskar Upadhaya, Will Deacon, Dan Douglass, linux-crypto,
David S. Miller, linux-arm-kernel
LS1012A has a SEC v5.4 security engine.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 9 +++
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 9 +++
arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 9 +++
arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 91 +++++++++++++++++++++-
4 files changed, 117 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
index a619f6496a4c..bab9e68947e4 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
@@ -49,6 +49,15 @@
model = "LS1012A Freedom Board";
compatible = "fsl,ls1012a-frdm", "fsl,ls1012a";
+ aliases {
+ crypto = &crypto;
+ rtic_a = &rtic_a;
+ rtic_b = &rtic_b;
+ rtic_c = &rtic_c;
+ rtic_d = &rtic_d;
+ sec_mon = &sec_mon;
+ };
+
sys_mclk: clock-mclk {
compatible = "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
index 14a67f1709e7..5c4e84c7f20d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
@@ -49,6 +49,15 @@
model = "LS1012A QDS Board";
compatible = "fsl,ls1012a-qds", "fsl,ls1012a";
+ aliases {
+ crypto = &crypto;
+ rtic_a = &rtic_a;
+ rtic_b = &rtic_b;
+ rtic_c = &rtic_c;
+ rtic_d = &rtic_d;
+ sec_mon = &sec_mon;
+ };
+
sys_mclk: clock-mclk {
compatible = "fixed-clock";
#clock-cells = <0>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
index 62c5c7123a15..ff9dd16aa65a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
@@ -48,6 +48,15 @@
/ {
model = "LS1012A RDB Board";
compatible = "fsl,ls1012a-rdb", "fsl,ls1012a";
+
+ aliases {
+ crypto = &crypto;
+ rtic_a = &rtic_a;
+ rtic_b = &rtic_b;
+ rtic_c = &rtic_c;
+ rtic_d = &rtic_d;
+ sec_mon = &sec_mon;
+ };
};
&duart0 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
index cffebb4b3df1..68f3012ae07e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
@@ -42,7 +42,7 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
/ {
compatible = "fsl,ls1012a";
@@ -113,6 +113,95 @@
big-endian;
};
+ crypto: crypto@1700000 {
+ compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
+ "fsl,sec-v4.0";
+ fsl,sec-era = <8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x1700000 0x100000>;
+ reg = <0x00 0x1700000 0x0 0x100000>;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+
+ sec_jr0: jr@10000 {
+ compatible = "fsl,sec-v5.4-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x10000 0x10000>;
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr@20000 {
+ compatible = "fsl,sec-v5.4-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x20000 0x10000>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr2: jr@30000 {
+ compatible = "fsl,sec-v5.4-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x30000 0x10000>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr3: jr@40000 {
+ compatible = "fsl,sec-v5.4-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x40000 0x10000>;
+ interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ rtic@60000 {
+ compatible = "fsl,sec-v5.4-rtic",
+ "fsl,sec-v5.0-rtic",
+ "fsl,sec-v4.0-rtic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x60000 0x100 0x60e00 0x18>;
+ ranges = <0x0 0x60100 0x500>;
+
+ rtic_a: rtic-a@0 {
+ compatible = "fsl,sec-v5.4-rtic-memory",
+ "fsl,sec-v5.0-rtic-memory",
+ "fsl,sec-v4.0-rtic-memory";
+ reg = <0x00 0x20 0x100 0x100>;
+ };
+
+ rtic_b: rtic-b@20 {
+ compatible = "fsl,sec-v5.4-rtic-memory",
+ "fsl,sec-v5.0-rtic-memory",
+ "fsl,sec-v4.0-rtic-memory";
+ reg = <0x20 0x20 0x200 0x100>;
+ };
+
+ rtic_c: rtic-c@40 {
+ compatible = "fsl,sec-v5.4-rtic-memory",
+ "fsl,sec-v5.0-rtic-memory",
+ "fsl,sec-v4.0-rtic-memory";
+ reg = <0x40 0x20 0x300 0x100>;
+ };
+
+ rtic_d: rtic-d@60 {
+ compatible = "fsl,sec-v5.4-rtic-memory",
+ "fsl,sec-v5.0-rtic-memory",
+ "fsl,sec-v4.0-rtic-memory";
+ reg = <0x60 0x20 0x400 0x100>;
+ };
+ };
+ };
+
+ sec_mon: sec_mon@1e90000 {
+ compatible = "fsl,sec-v5.4-mon", "fsl,sec-v5.0-mon",
+ "fsl,sec-v4.0-mon";
+ reg = <0x0 0x1e90000 0x0 0x10000>;
+ interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1012a-dcfg",
"syscon";
--
2.12.0.264.gd6db3f216544
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] crypto: DRBG - initialize SGL only once
From: Stephan Müller @ 2017-03-22 14:26 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
An SGL to be initialized only once even when its buffers are written
to several times.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/drbg.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 8a4d98b..fa749f4 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1749,17 +1749,16 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
u8 *inbuf, u32 inlen,
u8 *outbuf, u32 outlen)
{
- struct scatterlist sg_in;
+ struct scatterlist sg_in, sg_out;
int ret;
sg_init_one(&sg_in, inbuf, inlen);
+ sg_init_one(&sg_out, drbg->outscratchpad, DRBG_OUTSCRATCHLEN);
while (outlen) {
u32 cryptlen = min3(inlen, outlen, (u32)DRBG_OUTSCRATCHLEN);
- struct scatterlist sg_out;
/* Output buffer may not be valid for SGL, use scratchpad */
- sg_init_one(&sg_out, drbg->outscratchpad, cryptlen);
skcipher_request_set_crypt(drbg->ctr_req, &sg_in, &sg_out,
cryptlen, drbg->V);
ret = crypto_skcipher_encrypt(drbg->ctr_req);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0
From: Kevin Hilman @ 2017-03-22 15:24 UTC (permalink / raw)
To: Herbert Xu
Cc: Heiner Kallweit, Jerome Brunet, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
Michael Turquette, linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170317083032.GA18512-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> writes:
> On Thu, Mar 16, 2017 at 11:24:31AM -0700, Kevin Hilman wrote:
>> Hi Herbert,
>>
>> Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> writes:
>>
>> > On Wed, Feb 22, 2017 at 07:55:24AM +0100, Heiner Kallweit wrote:
>> >> Expose clock CLKID_RNG0 which is needed for the HW random number generator.
>> >>
>> >> Signed-off-by: Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >
>> > All patches applied. Thanks.
>>
>> Actually, can you just apply [PATCH 4/4] to your tree?
>>
>> The clock and DT patches need to go through their respective trees or
>> will otherwise have conflicts with other things going in via those
>> trees.
>
> It's too late now. Please speak up sooner next time. These
> patches were posted a month ago.
Because this will be causing conflicts with both the platform (amlogic)
tree and the clk tree, could provide an immutable branch where these are
applied to help us handle these conflicts?
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* race condition in kernel/padata.c
From: Jason A. Donenfeld @ 2017-03-22 23:03 UTC (permalink / raw)
To: Steffen Klassert, Linux Crypto Mailing List, LKML, Netdev
Cc: WireGuard mailing list
Hey Steffen,
WireGuard makes really heavy use of padata, feeding it units of work
from different cores in different contexts all at the same time. For
the most part, everything has been fine, but one particular user has
consistently run into mysterious bugs. He's using a rather old dual
core CPU, which have a tendency to bring out race conditions
sometimes. After struggling with getting a good backtrace, we finally
managed to extract this from list debugging:
[87487.298728] WARNING: CPU: 1 PID: 882 at lib/list_debug.c:33
__list_add+0xae/0x130
[87487.301868] list_add corruption. prev->next should be next
(ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00).
[87487.339011] [<ffffffff9a53d075>] dump_stack+0x68/0xa3
[87487.342198] [<ffffffff99e119a1>] ? console_unlock+0x281/0x6d0
[87487.345364] [<ffffffff99d6b91f>] __warn+0xff/0x140
[87487.348513] [<ffffffff99d6b9aa>] warn_slowpath_fmt+0x4a/0x50
[87487.351659] [<ffffffff9a58b5de>] __list_add+0xae/0x130
[87487.354772] [<ffffffff9add5094>] ? _raw_spin_lock+0x64/0x70
[87487.357915] [<ffffffff99eefd66>] padata_reorder+0x1e6/0x420
[87487.361084] [<ffffffff99ef0055>] padata_do_serial+0xa5/0x120
padata_reorder calls list_add_tail with the list to which its adding
locked, which seems correct:
spin_lock(&squeue->serial.lock);
list_add_tail(&padata->list, &squeue->serial.list);
spin_unlock(&squeue->serial.lock);
This therefore leaves only place where such inconsistency could occur:
if padata->list is added at the same time on two different threads.
This pdata pointer comes from the function call to
padata_get_next(pd), which has in it the following block:
next_queue = per_cpu_ptr(pd->pqueue, cpu);
padata = NULL;
reorder = &next_queue->reorder;
if (!list_empty(&reorder->list)) {
padata = list_entry(reorder->list.next,
struct padata_priv, list);
spin_lock(&reorder->lock);
list_del_init(&padata->list);
atomic_dec(&pd->reorder_objects);
spin_unlock(&reorder->lock);
pd->processed++;
goto out;
}
out:
return padata;
I strongly suspect that the problem here is that two threads can race
on reorder list. Even though the deletion is locked, call to
list_entry is not locked, which means it's feasible that two threads
pick up the same padata object and subsequently call list_add_tail on
them at the same time. The fix would thus be to hoist that lock
outside of that block.
This theory is unconfirmed at the moment, but I'll be playing with
some patches to see if this fixes the issue and then I'll get back to
you. In the meantime, if you have any insight before I potentially
waste some time, I'm all ears.
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0
From: Michael Turquette @ 2017-03-23 1:43 UTC (permalink / raw)
To: Kevin Hilman, Herbert Xu
Cc: Heiner Kallweit, Jerome Brunet, Neil Armstrong, linux-amlogic,
linux-crypto, Stephen Boyd, linux-clk, devicetree
In-Reply-To: <m2lgrxnxlz.fsf@baylibre.com>
Quoting Kevin Hilman (2017-03-22 08:24:08)
> Herbert Xu <herbert@gondor.apana.org.au> writes:
>
> > On Thu, Mar 16, 2017 at 11:24:31AM -0700, Kevin Hilman wrote:
> >> Hi Herbert,
> >>
> >> Herbert Xu <herbert@gondor.apana.org.au> writes:
> >>
> >> > On Wed, Feb 22, 2017 at 07:55:24AM +0100, Heiner Kallweit wrote:
> >> >> Expose clock CLKID_RNG0 which is needed for the HW random number generator.
> >> >>
> >> >> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> >> >
> >> > All patches applied. Thanks.
> >>
> >> Actually, can you just apply [PATCH 4/4] to your tree?
> >>
> >> The clock and DT patches need to go through their respective trees or
> >> will otherwise have conflicts with other things going in via those
> >> trees.
> >
> > It's too late now. Please speak up sooner next time. These
> > patches were posted a month ago.
>
> Because this will be causing conflicts with both the platform (amlogic)
> tree and the clk tree, could provide an immutable branch where these are
> applied to help us handle these conflicts?
+1
The DT header changes will cause conflicts in the clk tree. Much better
to either arrange for the patches to be applied by the correct
maintainers or to provide a stable, immutable branch.
Best regards,
Mike
>
> Thanks,
>
> Kevin
^ permalink raw reply
* Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0
From: Herbert Xu @ 2017-03-23 7:56 UTC (permalink / raw)
To: Kevin Hilman
Cc: Heiner Kallweit, Jerome Brunet, Neil Armstrong, linux-amlogic,
linux-crypto, Stephen Boyd, Michael Turquette, linux-clk,
devicetree
In-Reply-To: <m2lgrxnxlz.fsf@baylibre.com>
On Wed, Mar 22, 2017 at 08:24:08AM -0700, Kevin Hilman wrote:
>
> Because this will be causing conflicts with both the platform (amlogic)
> tree and the clk tree, could provide an immutable branch where these are
> applied to help us handle these conflicts?
If you apply the same patches to your tree there should be no
conflicts at all. git is able to resolve this automatically.
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: Question - seeding the hw pseudo random number generator
From: Harald Freudenberger @ 2017-03-23 8:03 UTC (permalink / raw)
To: Stephan Müller, Herbert Xu
Cc: PrasannaKumar Muralidharan, Krzysztof Kozlowski, Matt Mackall,
linux-crypto, linux-arm-kernel, Jan Glauber, Harald Freudenberger
In-Reply-To: <1509135.hmo2UhaKWe@tauon.atsec.com>
On 03/20/2017 02:39 PM, Stephan Müller wrote:
> Am Montag, 20. März 2017, 14:28:58 CET schrieb Herbert Xu:
>
> Hi Herbert,
>
>> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
>>> AF_ALG interface for rng does have seeding support. I think hw_random
>>> does not provide seeding support intentionally as I understand that
>>> True RNG need not require seeding (please correct me if I am wrong).
>> Yes. We should be converting PRNGs in hwrng over to algif_rng.
> IMHO this not only applies to the PRNGs in drivers/crypto (which should simply
> register with crypto_register_rngs) but also to ~/hacking/sources/linux/arch/
> s390/crypto/prng.c which exports a /dev/prandom file.
>
> For the seeding, it may make sense to follow the example given with crypto/
> drbg.c using the add_random_ready_callback function.
>
> Ciao
> Stephan
>
I'll have a look on it. Currently the s390/crypto/prng seeds itself with
an algorithm based on the jitter of the very fine granular hardware
clock of a s390 machine. There were some thoughts and measurements
by an mathematician which let to this algorithm. However, long-term
the s390 platform will provide some kind of true hardware random number
generator and the idea is to use this for seeding the prng.
regards
Harald Freudenberger
^ permalink raw reply
* Re: Question - seeding the hw pseudo random number generator
From: Corentin Labbe @ 2017-03-23 8:23 UTC (permalink / raw)
To: Herbert Xu
Cc: PrasannaKumar Muralidharan, linux-arm-kernel, linux-crypto,
Krzysztof Kozlowski, Matt Mackall
In-Reply-To: <20170320132858.GA27044@gondor.apana.org.au>
On Mon, Mar 20, 2017 at 09:28:58PM +0800, Herbert Xu wrote:
> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
> >
> > AF_ALG interface for rng does have seeding support. I think hw_random
> > does not provide seeding support intentionally as I understand that
> > True RNG need not require seeding (please correct me if I am wrong).
>
> Yes. We should be converting PRNGs in hwrng over to algif_rng.
>
Problem with this conversion, a huge regression for user space.
Using hwrng is simple as cat /dev/hwrng.
Using algif_rng via AF_ALG is ... unusable for the moment.
Perhaps creating an user space tool (prng-tool which provide a cat /dev/hwrng replacement) is mandatory before any convertion.
Regards
^ permalink raw reply
* Re: race condition in kernel/padata.c
From: Steffen Klassert @ 2017-03-23 8:40 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Netdev, Linux Crypto Mailing List, WireGuard mailing list, LKML
In-Reply-To: <CAHmME9oLWiprOyZXo7zvGm7xq+1Kchw9ybLS_TM-9xDyHF0mxQ@mail.gmail.com>
On Thu, Mar 23, 2017 at 12:03:43AM +0100, Jason A. Donenfeld wrote:
> Hey Steffen,
>
> WireGuard makes really heavy use of padata, feeding it units of work
> from different cores in different contexts all at the same time. For
> the most part, everything has been fine, but one particular user has
> consistently run into mysterious bugs. He's using a rather old dual
> core CPU, which have a tendency to bring out race conditions
> sometimes. After struggling with getting a good backtrace, we finally
> managed to extract this from list debugging:
>
> [87487.298728] WARNING: CPU: 1 PID: 882 at lib/list_debug.c:33
> __list_add+0xae/0x130
> [87487.301868] list_add corruption. prev->next should be next
> (ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00).
> [87487.339011] [<ffffffff9a53d075>] dump_stack+0x68/0xa3
> [87487.342198] [<ffffffff99e119a1>] ? console_unlock+0x281/0x6d0
> [87487.345364] [<ffffffff99d6b91f>] __warn+0xff/0x140
> [87487.348513] [<ffffffff99d6b9aa>] warn_slowpath_fmt+0x4a/0x50
> [87487.351659] [<ffffffff9a58b5de>] __list_add+0xae/0x130
> [87487.354772] [<ffffffff9add5094>] ? _raw_spin_lock+0x64/0x70
> [87487.357915] [<ffffffff99eefd66>] padata_reorder+0x1e6/0x420
> [87487.361084] [<ffffffff99ef0055>] padata_do_serial+0xa5/0x120
>
> padata_reorder calls list_add_tail with the list to which its adding
> locked, which seems correct:
>
> spin_lock(&squeue->serial.lock);
> list_add_tail(&padata->list, &squeue->serial.list);
> spin_unlock(&squeue->serial.lock);
>
> This therefore leaves only place where such inconsistency could occur:
> if padata->list is added at the same time on two different threads.
> This pdata pointer comes from the function call to
> padata_get_next(pd), which has in it the following block:
>
> next_queue = per_cpu_ptr(pd->pqueue, cpu);
> padata = NULL;
> reorder = &next_queue->reorder;
> if (!list_empty(&reorder->list)) {
> padata = list_entry(reorder->list.next,
> struct padata_priv, list);
> spin_lock(&reorder->lock);
> list_del_init(&padata->list);
> atomic_dec(&pd->reorder_objects);
> spin_unlock(&reorder->lock);
>
> pd->processed++;
>
> goto out;
> }
> out:
> return padata;
>
> I strongly suspect that the problem here is that two threads can race
> on reorder list. Even though the deletion is locked, call to
> list_entry is not locked, which means it's feasible that two threads
> pick up the same padata object and subsequently call list_add_tail on
> them at the same time. The fix would thus be to hoist that lock
> outside of that block.
Yes, looks like we should lock the whole list handling block here.
Thanks!
^ permalink raw reply
* Re: Question - seeding the hw pseudo random number generator
From: Herbert Xu @ 2017-03-23 9:44 UTC (permalink / raw)
To: Corentin Labbe
Cc: Stephan Müller, PrasannaKumar Muralidharan,
Krzysztof Kozlowski, linux-crypto, Matt Mackall, linux-arm-kernel
In-Reply-To: <20170323082307.GB16625@Red>
On Thu, Mar 23, 2017 at 09:23:07AM +0100, Corentin Labbe wrote:
>
> Problem with this conversion, a huge regression for user space.
> Using hwrng is simple as cat /dev/hwrng.
> Using algif_rng via AF_ALG is ... unusable for the moment.
> Perhaps creating an user space tool (prng-tool which provide a cat /dev/hwrng replacement) is mandatory before any convertion.
Stephan may have a tool to do this. Stephan?
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: out-of-bounds write in pre_crypt
From: Dmitry Vyukov @ 2017-03-23 10:51 UTC (permalink / raw)
To: Herbert Xu, David Miller, linux-crypto, LKML; +Cc: syzkaller
Hello,
I've got the following report while running syzkaller fuzzer.
init_crypt ignores kmalloc failure, which later leads to out-of-bounds
writes in ptr_crypt. On commit
093b995e3b55a0ae0670226ddfcb05bfbf0099ae.
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 10711 Comm: syz-executor0 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x1b8/0x28d lib/dump_stack.c:52
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x78a/0x870 lib/fault-inject.c:154
should_failslab+0xec/0x120 mm/failslab.c:31
slab_pre_alloc_hook mm/slab.h:434 [inline]
slab_alloc mm/slab.c:3394 [inline]
__do_kmalloc mm/slab.c:3734 [inline]
__kmalloc+0x220/0x730 mm/slab.c:3745
kmalloc include/linux/slab.h:495 [inline]
init_crypt+0x1c1/0x4f0 crypto/lrw.c:290
encrypt+0x1c/0x30 crypto/xts.c:298
crypto_skcipher_encrypt include/crypto/skcipher.h:445 [inline]
skcipher_recvmsg_sync crypto/algif_skcipher.c:687 [inline]
skcipher_recvmsg+0x669/0x1ea0 crypto/algif_skcipher.c:717
skcipher_recvmsg_nokey+0x60/0x80 crypto/algif_skcipher.c:834
sock_recvmsg_nosec net/socket.c:740 [inline]
sock_recvmsg+0xc9/0x110 net/socket.c:747
sock_read_iter+0x35b/0x560 net/socket.c:824
call_read_iter include/linux/fs.h:1727 [inline]
do_iter_readv_writev fs/read_write.c:694 [inline]
__do_readv_writev+0x6c8/0xf40 fs/read_write.c:862
do_readv_writev+0x10f/0x1a0 fs/read_write.c:894
vfs_readv+0x84/0xc0 fs/read_write.c:908
do_readv+0xfc/0x2a0 fs/read_write.c:934
SYSC_readv fs/read_write.c:1021 [inline]
SyS_readv+0x27/0x30 fs/read_write.c:1018
entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:00007f20d831e858 EFLAGS: 00000296 ORIG_RAX: 0000000000000013
RAX: ffffffffffffffda RBX: 0000000000708000 RCX: 0000000000445b79
RDX: 0000000000000003 RSI: 0000000020e86000 RDI: 0000000000000019
RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000296 R12: 00000000004a7e31
R13: 0000000000000000 R14: 00007f20d831e618 R15: 00007f20d831e788
==================================================================
BUG: KASAN: slab-out-of-bounds in pre_crypt+0x1078/0x1100
crypto/lrw.c:235 at addr ffff88005f17aee0
Write of size 16 by task syz-executor0/10711
CPU: 3 PID: 10711 Comm: syz-executor0 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x1b8/0x28d lib/dump_stack.c:52
kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
print_address_description mm/kasan/report.c:210 [inline]
kasan_report_error mm/kasan/report.c:294 [inline]
kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
kasan_report mm/kasan/report.c:343 [inline]
__asan_report_store16_noabort+0x2c/0x30 mm/kasan/report.c:343
pre_crypt+0x1078/0x1100 crypto/lrw.c:235
do_encrypt+0xd2/0x260 crypto/xts.c:265
encrypt+0x26/0x30 crypto/xts.c:298
crypto_skcipher_encrypt include/crypto/skcipher.h:445 [inline]
skcipher_recvmsg_sync crypto/algif_skcipher.c:687 [inline]
skcipher_recvmsg+0x669/0x1ea0 crypto/algif_skcipher.c:717
skcipher_recvmsg_nokey+0x60/0x80 crypto/algif_skcipher.c:834
sock_recvmsg_nosec net/socket.c:740 [inline]
sock_recvmsg+0xc9/0x110 net/socket.c:747
sock_read_iter+0x35b/0x560 net/socket.c:824
call_read_iter include/linux/fs.h:1727 [inline]
do_iter_readv_writev fs/read_write.c:694 [inline]
__do_readv_writev+0x6c8/0xf40 fs/read_write.c:862
do_readv_writev+0x10f/0x1a0 fs/read_write.c:894
vfs_readv+0x84/0xc0 fs/read_write.c:908
do_readv+0xfc/0x2a0 fs/read_write.c:934
SYSC_readv fs/read_write.c:1021 [inline]
SyS_readv+0x27/0x30 fs/read_write.c:1018
entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:00007f20d831e858 EFLAGS: 00000296 ORIG_RAX: 0000000000000013
RAX: ffffffffffffffda RBX: 0000000000708000 RCX: 0000000000445b79
RDX: 0000000000000003 RSI: 0000000020e86000 RDI: 0000000000000019
RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000296 R12: 00000000004a7e31
R13: 0000000000000000 R14: 00007f20d831e618 R15: 00007f20d831e788
Object at ffff88005f17a940, in cache kmalloc-2048 size: 2048
Allocated:
PID = 10711
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:517
set_track mm/kasan/kasan.c:529 [inline]
kasan_kmalloc+0xbc/0xf0 mm/kasan/kasan.c:620
__do_kmalloc mm/slab.c:3736 [inline]
__kmalloc+0x13c/0x730 mm/slab.c:3745
kmalloc include/linux/slab.h:495 [inline]
sock_kmalloc+0x118/0x180 net/core/sock.c:1793
skcipher_accept_parent_nokey+0xd8/0x670 crypto/algif_skcipher.c:931
af_alg_accept+0x47a/0x7e0 crypto/af_alg.c:297
alg_accept+0x46/0x60 crypto/af_alg.c:329
SYSC_accept4+0x37e/0x850 net/socket.c:1509
SyS_accept4 net/socket.c:1459 [inline]
SYSC_accept net/socket.c:1543 [inline]
SyS_accept+0x26/0x30 net/socket.c:1540
entry_SYSCALL_64_fastpath+0x1f/0xc2
Freed:
PID = 4482
save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
save_stack+0x43/0xd0 mm/kasan/kasan.c:517
set_track mm/kasan/kasan.c:529 [inline]
kasan_slab_free+0x81/0xc0 mm/kasan/kasan.c:593
__cache_free mm/slab.c:3514 [inline]
kfree+0xd7/0x250 mm/slab.c:3831
free_tty_struct+0x8e/0xb0 drivers/tty/tty_io.c:174
release_one_tty+0x36f/0x520 drivers/tty/tty_io.c:1647
process_one_work+0xb20/0x1b40 kernel/workqueue.c:2097
worker_thread+0x1b4/0x1340 kernel/workqueue.c:2231
kthread+0x359/0x420 kernel/kthread.c:229
ret_from_fork+0x31/0x40 arch/x86/entry/entry_64.S:430
Memory state around the buggy address:
ffff88005f17ad80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88005f17ae00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88005f17ae80: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
^
ffff88005f17af00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88005f17af80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
^ permalink raw reply
* Re: [PATCH] md5: remove from lib and only live in crypto
From: Jason A. Donenfeld @ 2017-03-23 11:13 UTC (permalink / raw)
To: Herbert Xu, Linux Crypto Mailing List, LKML; +Cc: Jason A. Donenfeld
In-Reply-To: <20170316141857.20910-1-Jason@zx2c4.com>
POKE?
^ permalink raw reply
* [PATCH] padata: avoid race in reordering
From: Jason A. Donenfeld @ 2017-03-23 11:24 UTC (permalink / raw)
To: Steffen Klassert, Linux Crypto Mailing List, LKML, Netdev
Cc: Jason A. Donenfeld
In-Reply-To: <CAHmME9oLWiprOyZXo7zvGm7xq+1Kchw9ybLS_TM-9xDyHF0mxQ@mail.gmail.com>
Under extremely heavy uses of padata, crashes occur, and with list
debugging turned on, this happens instead:
[87487.298728] WARNING: CPU: 1 PID: 882 at lib/list_debug.c:33
__list_add+0xae/0x130
[87487.301868] list_add corruption. prev->next should be next
(ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00).
[87487.339011] [<ffffffff9a53d075>] dump_stack+0x68/0xa3
[87487.342198] [<ffffffff99e119a1>] ? console_unlock+0x281/0x6d0
[87487.345364] [<ffffffff99d6b91f>] __warn+0xff/0x140
[87487.348513] [<ffffffff99d6b9aa>] warn_slowpath_fmt+0x4a/0x50
[87487.351659] [<ffffffff9a58b5de>] __list_add+0xae/0x130
[87487.354772] [<ffffffff9add5094>] ? _raw_spin_lock+0x64/0x70
[87487.357915] [<ffffffff99eefd66>] padata_reorder+0x1e6/0x420
[87487.361084] [<ffffffff99ef0055>] padata_do_serial+0xa5/0x120
padata_reorder calls list_add_tail with the list to which its adding
locked, which seems correct:
spin_lock(&squeue->serial.lock);
list_add_tail(&padata->list, &squeue->serial.list);
spin_unlock(&squeue->serial.lock);
This therefore leaves only place where such inconsistency could occur:
if padata->list is added at the same time on two different threads.
This pdata pointer comes from the function call to
padata_get_next(pd), which has in it the following block:
next_queue = per_cpu_ptr(pd->pqueue, cpu);
padata = NULL;
reorder = &next_queue->reorder;
if (!list_empty(&reorder->list)) {
padata = list_entry(reorder->list.next,
struct padata_priv, list);
spin_lock(&reorder->lock);
list_del_init(&padata->list);
atomic_dec(&pd->reorder_objects);
spin_unlock(&reorder->lock);
pd->processed++;
goto out;
}
out:
return padata;
I strongly suspect that the problem here is that two threads can race
on reorder list. Even though the deletion is locked, call to
list_entry is not locked, which means it's feasible that two threads
pick up the same padata object and subsequently call list_add_tail on
them at the same time. The fix is thus be hoist that lock outside of
that block.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
kernel/padata.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 05316c9f32da..3202aa17492c 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -186,19 +186,20 @@ static struct padata_priv *padata_get_next(struct parallel_data *pd)
reorder = &next_queue->reorder;
+ spin_lock(&reorder->lock);
if (!list_empty(&reorder->list)) {
padata = list_entry(reorder->list.next,
struct padata_priv, list);
- spin_lock(&reorder->lock);
list_del_init(&padata->list);
atomic_dec(&pd->reorder_objects);
- spin_unlock(&reorder->lock);
pd->processed++;
+ spin_unlock(&reorder->lock);
goto out;
}
+ spin_unlock(&reorder->lock);
if (__this_cpu_read(pd->pqueue->cpu_index) == next_queue->cpu_index) {
padata = ERR_PTR(-ENODATA);
--
2.11.1
^ permalink raw reply related
* Re: Question - seeding the hw pseudo random number generator
From: Stephan Müller @ 2017-03-23 11:35 UTC (permalink / raw)
To: Harald Freudenberger
Cc: Herbert Xu, PrasannaKumar Muralidharan, Krzysztof Kozlowski,
Matt Mackall, linux-crypto, linux-arm-kernel, Jan Glauber,
Harald Freudenberger
In-Reply-To: <602a68ef-c57a-0092-ebe0-161ec602fad6@linux.vnet.ibm.com>
Am Donnerstag, 23. März 2017, 09:03:23 CET schrieb Harald Freudenberger:
Hi Harald,
> I'll have a look on it. Currently the s390/crypto/prng seeds itself with
> an algorithm based on the jitter of the very fine granular hardware
> clock of a s390 machine. There were some thoughts and measurements
> by an mathematician which let to this algorithm.
It takes a page and simply writes 512 times the high-res time stamp using
get_tod_clock_fast into it. Effectively it uses the same fundamental noise
source as the jitterentropy. (A couple of months ago I had to perform an
SP800-90B assessment on exactly that code path. :-) )
> However, long-term
> the s390 platform will provide some kind of true hardware random number
> generator and the idea is to use this for seeding the prng.
The question is just that it provides a device file nobody else provides. And
the question is whether to consolidate it. If it is a DRNG, the discussion is
about consolidating it behind AF_ALG. If it is an RNG with its own noise
source (i.e. it provides entropic data by itself), it should rather be placed
into drivers/char/hw_random and use the hw-random framework. This framework
will also ensure that it may seed the /dev/random device kernel-internally.
Ciao
Stephan
^ permalink raw reply
* Re: Question - seeding the hw pseudo random number generator
From: Stephan Müller @ 2017-03-23 11:44 UTC (permalink / raw)
To: Herbert Xu
Cc: Corentin Labbe, PrasannaKumar Muralidharan, linux-arm-kernel,
linux-crypto, Krzysztof Kozlowski, Matt Mackall
In-Reply-To: <20170323094406.GA6848@gondor.apana.org.au>
Am Donnerstag, 23. März 2017, 10:44:06 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Mar 23, 2017 at 09:23:07AM +0100, Corentin Labbe wrote:
> > Problem with this conversion, a huge regression for user space.
> > Using hwrng is simple as cat /dev/hwrng.
> > Using algif_rng via AF_ALG is ... unusable for the moment.
> > Perhaps creating an user space tool (prng-tool which provide a cat
> > /dev/hwrng replacement) is mandatory before any convertion.
> Stephan may have a tool to do this. Stephan?
Creating such tool is more or less trivial. It simply requires the invocation
of kcapi_rng_init, kcapi_rng_seed, kcapi_rng_generate and eventually
kcapi_rng_destroy from [1]. I can write such a tool if requested.
I see one change we need to add to algif_rng.c: currently the caller must
provide the specific name of the DRNG to be used. With such a tool, the caller
does not care about the type of DRNG. Thus, rng_bind should be changed such
that if name is NULL, it should use crypto_get_default_rng(). This would
alleviate the caller from selecting "the right" DRNG.
[1] http://www.chronox.de/libkcapi.html
Ciao
Stephan
^ permalink raw reply
* Re: Question - seeding the hw pseudo random number generator
From: Stephan Müller @ 2017-03-23 13:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Corentin Labbe, PrasannaKumar Muralidharan, linux-arm-kernel,
linux-crypto, Krzysztof Kozlowski, Matt Mackall
In-Reply-To: <20170323094406.GA6848@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
Am Donnerstag, 23. März 2017, 10:44:06 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Mar 23, 2017 at 09:23:07AM +0100, Corentin Labbe wrote:
> > Problem with this conversion, a huge regression for user space.
> > Using hwrng is simple as cat /dev/hwrng.
> > Using algif_rng via AF_ALG is ... unusable for the moment.
> > Perhaps creating an user space tool (prng-tool which provide a cat
> > /dev/hwrng replacement) is mandatory before any convertion.
> Stephan may have a tool to do this. Stephan?
Here is a suggestion for such a tool that I could add to libkcapi. Naturally,
this code is only a demonstrator which lacks some features.
Ciao
Stephan
[-- Attachment #2: kcapi-rng.c --]
[-- Type: text/x-csrc, Size: 3542 bytes --]
/*
* Copyright (C) 2017, Stephan Mueller <smueller@chronox.de>
*
* License: see COPYING file in root directory
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
* WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
* OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
* USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
* DAMAGE.
*/
#include <unistd.h>
#include <errno.h>
#include <limits.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <linux/random.h>
#ifdef HAVE_GETRANDOM
#include <sys/random.h>
#endif
#include <kcapi.h>
struct kcapi_handle *rng = NULL;
static int read_complete(int fd, uint8_t *buf, uint32_t buflen)
{
ssize_t ret;
do {
ret = read(fd, buf, buflen);
if (0 < ret) {
buflen -= ret;
buf += ret;
}
} while ((0 < ret || EINTR == errno || ERESTART == errno)
&& buflen > 0);
if (buflen == 0)
return 0;
return 1;
}
static int read_random(uint8_t *buf, uint32_t buflen)
{
int fd;
int ret = 0;
fd = open("/dev/urandom", O_RDONLY|O_CLOEXEC);
if (0 > fd)
return fd;
ret = read_complete(fd, buf, buflen);
close(fd);
return ret;
}
static int get_random(uint8_t *buf, uint32_t buflen)
{
if (buflen > INT_MAX)
return 1;
#ifdef HAVE_GETRANDOM
return getrandom(buf, buflen, 0);
#else
# ifdef __NR_getrandom
do {
int ret = syscall(__NR_getrandom, buf, buflen, 0);
if (0 < ret) {
buflen -= ret;
buf += ret;
}
} while ((0 < ret || EINTR == errno || ERESTART == errno)
&& buflen > 0);
if (buflen == 0)
return 0;
return 1;
# else
return read_random(buf, buflen);
# endif
#endif
}
static void usage(void)
{
char version[30];
uint32_t ver = kcapi_version();
memset(version, 0, sizeof(version));
kcapi_versionstring(version, sizeof(version));
fprintf(stderr, "\nKernel Crypto API Random Number Gatherer\n");
fprintf(stderr, "\nKernel Crypto API interface library version: %s\n", version);
fprintf(stderr, "Reported numeric version number %u\n\n", ver);
fprintf(stderr, "Usage:\n");
fprintf(stderr, "\t<NUM>\tNumber of bytes to generate\n");
}
int main(int argc, char *argv[])
{
int ret;
uint8_t buf[64];
unsigned long outlen;
if (argc != 2) {
usage();
return -EINVAL;
}
outlen = strtoul(argv[1], NULL, 10);
if (outlen == ULONG_MAX) {
usage();
return -EINVAL;
}
ret = kcapi_rng_init(&rng, "drbg_nopr_hmac_sha256", 0);
if (ret)
return ret;
ret = get_random(buf, sizeof(buf));
if (ret)
goto out;
ret = kcapi_rng_seed(rng, buf, sizeof(buf));
kcapi_memset_secure(buf, 0, sizeof(buf));
if (ret)
goto out;
while (outlen) {
uint32_t todo = (outlen < sizeof(buf)) ? outlen : sizeof(buf);
ret = kcapi_rng_generate(rng, buf, todo);
if (ret < 0)
goto out;
if ((uint32_t)ret != todo) {
ret = -EFAULT;
goto out;
}
fwrite(&buf, todo, 1, stdout);
outlen -= todo;
}
out:
if (rng)
kcapi_rng_destroy(rng);
kcapi_memset_secure(buf, 0, sizeof(buf));
return ret;
}
^ permalink raw reply
* [PATCH] crypto: ixp4xx - Use sg_virt()
From: Geliang Tang @ 2017-03-23 13:16 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: Geliang Tang, linux-crypto, linux-kernel
Use sg_virt() instead of open-coding it.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/crypto/ixp4xx_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 7868765..771dd26 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -806,7 +806,7 @@ static struct buffer_desc *chainup_buffers(struct device *dev,
void *ptr;
nbytes -= len;
- ptr = page_address(sg_page(sg)) + sg->offset;
+ ptr = sg_virt(sg);
next_buf = dma_pool_alloc(buffer_pool, flags, &next_buf_phys);
if (!next_buf) {
buf = NULL;
--
2.9.3
^ permalink raw reply related
* Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)
From: Arnd Bergmann @ 2017-03-23 16:19 UTC (permalink / raw)
To: kernelci.org bot
Cc: kernel-build-reports, Linux Kernel Mailing List, linux-crypto,
linux-mips, Steven J. Hill, Ralf Baechle
In-Reply-To: <58d36150.82ce190a.a6597.51eb@mx.google.com>
On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot <bot@kernelci.org> wrote:
> acs5k_defconfig (arm) — PASS, 0 errors, 2 warnings, 0 section mismatches
>
> Warnings:
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]
> :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp]
patch sent today, we don't really want this syscall except on x86
> allmodconfig (arm64) — FAIL, 6 errors, 5 warnings, 0 section mismatches
>
> Errors:
> ERROR (phandle_references): Reference to non-existent node or label "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)
> ERROR (phandle_references): Reference to non-existent node or label "pwm_f_clk_pins"
> ERROR (phandle_references): Reference to non-existent node or label "pwm_ao_a_3_pins"
> ERROR: Input tree has errors, aborting (use -f to force output)
Kevin has already backed out the commit that caused this.
> Warnings:
> :1325:2: warning: #warning syscall statx not implemented [-Wcpp]
Should get fixed in the next few days when the patch gets picked up for arm64.
> drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]
patch sent today
> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
> include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer implicitly truncated to unsigned type [-Woverflow]
I sent this one a few days ago
> allmodconfig (x86) — PASS, 0 errors, 11 warnings, 0 section mismatches
>
> Warnings:
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'long long int' [-Wformat=]
> drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]
This one too.
> cavium_octeon_defconfig (mips) — FAIL, 830 errors, 3 warnings, 0 section mismatches
>
> Errors:
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:78:3: error: expected specifier-qualifier-list before '__BITFIELD_FIELD'
> arch/mips/include/asm/octeon/cvmx-mio-defs.h:95:3: error: expected specifier-qualifier-list before '__BITFIELD_FIELD'
Maybe caused by 4cd156de2ca8 ("MIPS: Octeon: Remove unused MIO types
and macros.")
I have not looked in detail
> net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=]
Still need to rework my patches.
Arnd
^ permalink raw reply
* Re: [PATCH] crypto: ixp4xx - Use sg_virt()
From: David Miller @ 2017-03-23 17:48 UTC (permalink / raw)
To: geliangtang; +Cc: herbert, linux-crypto, linux-kernel
In-Reply-To: <a41fae798473b657f09859ae113403655b1717f9.1490258141.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Thu, 23 Mar 2017 21:16:30 +0800
> Use sg_virt() instead of open-coding it.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ 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