Re: [PATCH v2 2/5] crypto: stm32 - Support for STM32 CRC32 crypto module
On 21 March 2017 at 20:43, Fabien Dessenne wrote:
> This module registers a CRC32 ("Ethernet") and a CRC32C (Castagnoli)
> algorithm that make use of the STMicroelectronics STM32 crypto hardware.
>
> Theses algorithms are compatible with the little-endian generic ones.
> Both algorithms use ~0 as default seed (key).
> With CRC32C the output is xored with ~0.
>
> Using TCRYPT CRC32C speed test, this shows up to 900% speedup compared
> to the crc32c-generic algorithm.
Comparing with crc3c-generic alogrithm does not sound like a good
metric for someone who has to decide between hw crypto or not.
Wouldn't it be better if the comparison is between crc32 using NEON
with hw crypto module? It will help in choosing between hw crypto or
arch optimised crc routiene.
> Signed-off-by: Fabien Dessenne
> ---
> drivers/crypto/Kconfig | 2 +
> drivers/crypto/Makefile| 1 +
> drivers/crypto/stm32/Kconfig | 8 +
> drivers/crypto/stm32/Makefile | 2 +
> drivers/crypto/stm32/stm32_crc32.c | 324
> +
> 5 files changed, 337 insertions(+)
> create mode 100644 drivers/crypto/stm32/Kconfig
> create mode 100644 drivers/crypto/stm32/Makefile
> create mode 100644 drivers/crypto/stm32/stm32_crc32.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 473d312..922b323 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -619,4 +619,6 @@ config CRYPTO_DEV_BCM_SPU
> Secure Processing Unit (SPU). The SPU driver registers ablkcipher,
> ahash, and aead algorithms with the kernel cryptographic API.
>
> +source "drivers/crypto/stm32/Kconfig"
> +
> endif # CRYPTO_HW
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index 7396094..95bf2f9 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
> obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
> obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
> obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32) += stm32/
> obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
> obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
> obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
> diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig
> new file mode 100644
> index 000..792335b
> --- /dev/null
> +++ b/drivers/crypto/stm32/Kconfig
> @@ -0,0 +1,8 @@
> +config CRYPTO_DEV_STM32
> + tristate "Support for STM32 crypto accelerators"
> + depends on ARCH_STM32
> + select CRYPTO_HASH
> + help
> + This enables support for the CRC32 hw accelerator which can be
> found
> + on STMicroelectronis STM32 SOC.
> +
> diff --git a/drivers/crypto/stm32/Makefile b/drivers/crypto/stm32/Makefile
> new file mode 100644
> index 000..73b4c6e
> --- /dev/null
> +++ b/drivers/crypto/stm32/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_CRYPTO_DEV_STM32) += stm32_cryp.o
> +stm32_cryp-objs := stm32_crc32.o
> diff --git a/drivers/crypto/stm32/stm32_crc32.c
> b/drivers/crypto/stm32/stm32_crc32.c
> new file mode 100644
> index 000..7652822
> --- /dev/null
> +++ b/drivers/crypto/stm32/stm32_crc32.c
> @@ -0,0 +1,324 @@
> +/*
> + * Copyright (C) STMicroelectronics SA 2017
> + * Author: Fabien Dessenne
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +#define DRIVER_NAME "stm32-crc32"
> +#define CHKSUM_DIGEST_SIZE 4
> +#define CHKSUM_BLOCK_SIZE 1
> +
> +/* Registers */
> +#define CRC_DR 0x
> +#define CRC_CR 0x0008
> +#define CRC_INIT0x0010
> +#define CRC_POL 0x0014
> +
> +/* Registers values */
> +#define CRC_CR_RESETBIT(0)
> +#define CRC_CR_REVERSE (BIT(7) | BIT(6) | BIT(5))
> +#define CRC_INIT_DEFAULT0x
> +
> +/* Polynomial reversed */
> +#define POLY_CRC32 0xEDB88320
> +#define POLY_CRC32C 0x82F63B78
> +
> +struct stm32_crc {
> + struct list_head list;
> + struct device*dev;
> + void __iomem *regs;
> + struct clk *clk;
> + u8 pending_data[sizeof(u32)];
> + size_t nb_pending_bytes;
> +};
> +
> +struct stm32_crc_list {
> + struct list_head dev_list;
> + spinlock_t lock; /* protect dev_list */
> +};
> +
> +static struct stm32_crc_list crc_list = {
> + .dev_list = LIST_HEAD_INIT(crc_list.dev_list),
> + .lock = __SPIN_LOCK_UNLOCKED(crc_list.lock),
> +};
> +
> +struct stm32_crc_ctx {
> + u32 key;
> + u32 poly;
> +};
> +
> +struct stm32_crc_desc_ctx {
> + u32partial; /* crc32c: partial in first 4 bytes of that struct */
> + struct stm32_crc *crc;
> +};
> +
> +static int stm32_crc32_cra_init(struct crypto_tfm *tfm)
> +{
> + s
Re: [PATCH] arm64: dts: ls1012a: add crypto node
On Wed, Mar 22, 2017 at 02:29:39PM +0200, Horia Geantă wrote:
> LS1012A has a SEC v5.4 security engine.
>
> Signed-off-by: Horia Geantă
> ---
> 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;
> + };
What are these aliases used for? Are they board specific? If not, we
should probably have them in fsl-ls1012a.dtsi, since you are adding
them for all three fsl-ls1012a based boards.
> };
>
> &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
> +#include
>
> / {
> compatible = "fsl,ls1012a";
> @@ -113,6 +113,95 @@
> big-endian;
> };
>
> + crypto: crypto@170 {
> + 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 0x170 0x10>;
> + reg = <0x00 0x170 0x0 0x10>;
> + interrupts = ;
> +
> + sec_jr0: jr@1 {
> + compatible = "fsl,sec-v5.4-job-ring",
> + "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg= <0x1 0x1>;
> + interrupts = ;
> + };
> +
> + sec_jr1: jr@2 {
> + compatible = "fsl,sec-v5.4-job-ring",
> + "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg= <0x2 0x1>;
> + interrupts = ;
> + };
> +
> + sec_jr2: jr@3 {
> + compatible = "fsl,sec-v5.4-job-ring",
> + "fsl,sec-v5.0-job-ring",
> + "fsl,sec-v4.0-job-ring";
> + reg= <0x3 0x1>;
> + interrupts = ;
> + };
> +
> + sec_jr3: jr
[ANNOUNCE] Linux Security Summit 2017 - CFP
== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT 2017 14-15 September LOS ANGELES, USA == DESCRIPTION The Linux Security Summit (LSS) is a technical forum for collaboration between Linux developers, researchers, and end users. Its primary aim is to foster community efforts in analyzing and solving Linux security challenges. LSS this year will be co-located with the Open Source Summit and the Linux Plumbers Conference. The program committee currently seeks proposals for: * Refereed Presentations: 45 minutes in length, including at least 10 minutes of discussion. * Discussion Topics: 30 minutes in length. Topic areas include, but are not limited to: * Kernel self-protection * Access control * Cryptography and key management * Integrity control * Hardware Security * Iot and embedded security * Virtualization and containers * System-specific system hardening * Case studies * Security tools * Security UX * Emerging technologies, threats & techniques Proposals should be submitted via: http://events.linuxfoundation.org/events/linux-security-summit/program/cfp DATES * CFP Close: June 5, 2017 * CFP Notifications: June 12, 2017 * Schedule Announced: June 19, 2017 * Slide Submission: August 31, 2017 WHO SHOULD ATTEND We're seeking a diverse range of attendees, and welcome participation by people involved in Linux security development, operations, and research. The LSS is a unique global event which provides the opportunity to present and discuss your work or research with key Linux security community members and maintainers. It’s also useful for those who wish to keep up with the latest in Linux security development, and to provide input to the development process. WEB SITE http://events.linuxfoundation.org/events/linux-security-summit TWITTER For event updates and announcements, follow: https://twitter.com/LinuxSecSummit PROGRAM COMMITTEE The program committee for LSS 2017 is: * James Morris, Oracle * Serge Hallyn, Canonical * Paul Moore, Red Hat * Stephen Smalley, NSA * Elena Reshetova, Intel * John Johansen, Canonical * Kees Cook, Google * Casey Schaufler, Intel * Mimi Zohar, IBM * David A. Wheeler, Institute for Defense Analyses The program committee may be contacted as a group via email: lss-pc () lists.linuxfoundation.org
Re: [PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure
From: Eric Biggers
Date: Thu, 23 Mar 2017 13:39:46 -0700
> From: Eric Biggers
>
> In the generic XTS and LRW algorithms, for input data > 128 bytes, a
> temporary buffer is allocated to hold the values to be XOR'ed with the
> data before and after encryption or decryption. If the allocation
> fails, the fixed-size buffer embedded in the request buffer is meant to
> be used as a fallback --- resulting in more calls to the ECB algorithm,
> but still producing the correct result. However, we weren't correctly
> limiting subreq->cryptlen in this case, resulting in pre_crypt()
> overrunning the embedded buffer. Fix this by setting subreq->cryptlen
> correctly.
>
> Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
> Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
> Cc: sta...@vger.kernel.org # v4.10+
> Reported-by: Dmitry Vyukov
> Signed-off-by: Eric Biggers
Acked-by: David S. Miller
[PATCH] crypto: xts,lrw - fix out-of-bounds write after kmalloc failure
From: Eric Biggers
In the generic XTS and LRW algorithms, for input data > 128 bytes, a
temporary buffer is allocated to hold the values to be XOR'ed with the
data before and after encryption or decryption. If the allocation
fails, the fixed-size buffer embedded in the request buffer is meant to
be used as a fallback --- resulting in more calls to the ECB algorithm,
but still producing the correct result. However, we weren't correctly
limiting subreq->cryptlen in this case, resulting in pre_crypt()
overrunning the embedded buffer. Fix this by setting subreq->cryptlen
correctly.
Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")
Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
Cc: sta...@vger.kernel.org # v4.10+
Reported-by: Dmitry Vyukov
Signed-off-by: Eric Biggers
---
crypto/lrw.c | 7 +--
crypto/xts.c | 7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/crypto/lrw.c b/crypto/lrw.c
index ecd8474018e3..3ea095adafd9 100644
--- a/crypto/lrw.c
+++ b/crypto/lrw.c
@@ -286,8 +286,11 @@ static int init_crypt(struct skcipher_request *req,
crypto_completion_t done)
subreq->cryptlen = LRW_BUFFER_SIZE;
if (req->cryptlen > LRW_BUFFER_SIZE) {
- subreq->cryptlen = min(req->cryptlen, (unsigned)PAGE_SIZE);
- rctx->ext = kmalloc(subreq->cryptlen, gfp);
+ unsigned int n = min(req->cryptlen, (unsigned int)PAGE_SIZE);
+
+ rctx->ext = kmalloc(n, gfp);
+ if (rctx->ext)
+ subreq->cryptlen = n;
}
rctx->src = req->src;
diff --git a/crypto/xts.c b/crypto/xts.c
index baeb34dd8582..c976bfac29da 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -230,8 +230,11 @@ static int init_crypt(struct skcipher_request *req,
crypto_completion_t done)
subreq->cryptlen = XTS_BUFFER_SIZE;
if (req->cryptlen > XTS_BUFFER_SIZE) {
- subreq->cryptlen = min(req->cryptlen, (unsigned)PAGE_SIZE);
- rctx->ext = kmalloc(subreq->cryptlen, gfp);
+ unsigned int n = min(req->cryptlen, (unsigned int)PAGE_SIZE);
+
+ rctx->ext = kmalloc(n, gfp);
+ if (rctx->ext)
+ subreq->cryptlen = n;
}
rctx->src = req->src;
--
2.12.1.500.gab5fba24ee-goog
Re: crypto: out-of-bounds write in pre_crypt
Hi Dmitry, On Thu, Mar 23, 2017 at 11:51:30AM +0100, Dmitry Vyukov wrote: > 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. > Thanks for finding this! Nice to see that the crypto code is getting tested... This bug was introduced in v4.10 and affects the generic XTS and LRW drivers. They are supposed to work in the event of a kmalloc failure, but evidently it's broken. I'm sending a patch shortly. - Eric
Re: [PATCH] md5: remove from lib and only live in crypto
On Thu, Mar 16, 2017 at 03:18:57PM +0100, Jason A. Donenfeld wrote: > The md5_transform function is no longer used any where in the tree, > except for the crypto api's actual implementation of md5, so we can drop > the function from lib and put it as a static function of the crypto > file, where it belongs. There should be no new users of md5_transform, > anyway, since there are more modern ways of doing what it once achieved. > > Signed-off-by: Jason A. Donenfeld > --- > In the last patch like this, we managed to get rid of halfmd4 from this > file. In this series we get rid of md5, now that the patches have landed > that remove such improper md5 usage from the kernel. When a final > dependency on the (dead) sha1 is removed, then cryptohash.h will be removed > all together. This patch is for the md5 removal. > The patch itself looks good to me, and you can add Reviewed-by: Eric Biggers There is a small issue, though, which is that currently cryptodev/master (where this patch would be applied to) still has md5_transform() in drivers/char/random.c, because cryptodev/master is based on v4.11-rc1 instead of v4.11-rc2. It's up to Herbert how he wants to deal with this, but maybe he could merge in a later -rc. - Eric
Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)
On Thu, Mar 23, 2017 at 05:19:14PM +0100, Arnd Bergmann wrote:
> Date: Thu, 23 Mar 2017 17:19:14 +0100
> From: Arnd Bergmann
> To: "kernelci.org bot"
> Cc: kernel-build-repo...@lists.linaro.org, Linux Kernel Mailing List
> , linux-crypto@vger.kernel.org,
> linux-m...@linux-mips.org, "Steven J. Hill" , Ralf
> Baechle
> Subject: Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444
> warnings (next-20170323)
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot 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
Seems an #include is missing. I'm going to sort
this one.
Thanks,
Ralf
[PATCH] crypto: ccp - Make some CCP DMA channels private
The CCP registers its queues as channels capable of handling
general DMA operations. The NTB driver will use DMA if
directed, but as public channels can be reserved for use in
asynchronous operations some channels should be held back
as private. Since the public/private determination is
handled at a device level, reserve the "other" (secondary)
CCP channels as private.
Add a module parameter that allows for override, to be
applied to all channels on all devices.
CC: # 4.10.x-
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev-v5.c|1 +
drivers/crypto/ccp/ccp-dev.h |5
drivers/crypto/ccp/ccp-dmaengine.c | 41
3 files changed, 47 insertions(+)
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 41cc853..fc08b4e 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -1015,6 +1015,7 @@ static void ccp5other_config(struct ccp_device *ccp)
const struct ccp_vdata ccpv5b = {
.version = CCP_VERSION(5, 0),
+ .dma_chan_attr = DMA_PRIVATE,
.setup = ccp5other_config,
.perform = &ccp5_actions,
.bar = 2,
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index 2b5c01f..aa36f3f 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -179,6 +179,10 @@
/* General CCP Defines */
+#defineCCP_DMA_DFLT0x0
+#defineCCP_DMA_PRIV0x1
+#defineCCP_DMA_PUB 0x2
+
#define CCP_DMAPOOL_MAX_SIZE 64
#define CCP_DMAPOOL_ALIGN BIT(5)
@@ -636,6 +640,7 @@ struct ccp_actions {
/* Structure to hold CCP version-specific values */
struct ccp_vdata {
const unsigned int version;
+ const unsigned int dma_chan_attr;
void (*setup)(struct ccp_device *);
const struct ccp_actions *perform;
const unsigned int bar;
diff --git a/drivers/crypto/ccp/ccp-dmaengine.c
b/drivers/crypto/ccp/ccp-dmaengine.c
index 8d0eeb4..e00be01 100644
--- a/drivers/crypto/ccp/ccp-dmaengine.c
+++ b/drivers/crypto/ccp/ccp-dmaengine.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -25,6 +26,37 @@
(mask == 0) ? 64 : fls64(mask); \
})
+/* The CCP as a DMA provider can be configured for public or private
+ * channels. Default is specified in the vdata for the device (PCI ID).
+ * This module parameter will override for all channels on all devices:
+ * dma_chan_attr = 0x2 to force all channels public
+ * = 0x1 to force all channels private
+ * = 0x0 to defer to the vdata setting
+ * = any other value: warning, revert to 0x0
+ */
+static unsigned int dma_chan_attr = CCP_DMA_DFLT;
+module_param(dma_chan_attr, uint, 0444);
+MODULE_PARM_DESC(dma_chan_attr, "Set DMA channel visibility: 0 (default) =
device defaults, 1 = make private, 2 = make public");
+
+unsigned int ccp_get_dma_chan_attr(struct ccp_device *ccp)
+{
+ switch (dma_chan_attr) {
+ case CCP_DMA_DFLT:
+ return ccp->vdata->dma_chan_attr;
+
+ case CCP_DMA_PRIV:
+ return DMA_PRIVATE;
+
+ case CCP_DMA_PUB:
+ return 0;
+
+ default:
+ dev_info_once(ccp->dev, "Invalid value for dma_chan_attr: %d\n",
+ dma_chan_attr);
+ return ccp->vdata->dma_chan_attr;
+ }
+}
+
static void ccp_free_cmd_resources(struct ccp_device *ccp,
struct list_head *list)
{
@@ -675,6 +707,15 @@ int ccp_dmaengine_register(struct ccp_device *ccp)
dma_cap_set(DMA_SG, dma_dev->cap_mask);
dma_cap_set(DMA_INTERRUPT, dma_dev->cap_mask);
+ /* The DMA channels for this device can be set to public or private,
+* and overridden by the module parameter dma_chan_attr.
+* Default: according to the value in vdata (dma_chan_attr=0)
+* dma_chan_attr=0x1: all channels private (override vdata)
+* dma_chan_attr=0x2: all channels public (override vdata)
+*/
+ if (ccp_get_dma_chan_attr(ccp) == DMA_PRIVATE)
+ dma_cap_set(DMA_PRIVATE, dma_dev->cap_mask);
+
INIT_LIST_HEAD(&dma_dev->channels);
for (i = 0; i < ccp->cmd_q_count; i++) {
chan = ccp->ccp_dma_chan + i;
Re: [PATCH] crypto: ixp4xx - Use sg_virt()
From: Geliang Tang Date: Thu, 23 Mar 2017 21:16:30 +0800 > Use sg_virt() instead of open-coding it. > > Signed-off-by: Geliang Tang Acked-by: David S. Miller
Re: next build: 208 builds: 9 failed, 199 passed, 857 errors, 444 warnings (next-20170323)
On Thu, Mar 23, 2017 at 6:46 AM, kernelci.org bot 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
[PATCH] crypto: ixp4xx - Use sg_virt()
Use sg_virt() instead of open-coding it.
Signed-off-by: Geliang Tang
---
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
Re: Question - seeding the hw pseudo random number generator
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/*
* Copyright (C) 2017, Stephan Mueller
*
* 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
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifdef HAVE_GETRANDOM
#include
#endif
#include
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\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;
}
Re: Question - seeding the hw pseudo random number generator
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
Re: Question - seeding the hw pseudo random number generator
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
[PATCH] padata: avoid race in reordering
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
(b17abfc043d0), but was 8dba70872c80. (prev=8dba70872b00).
[87487.339011] [] dump_stack+0x68/0xa3
[87487.342198] [] ? console_unlock+0x281/0x6d0
[87487.345364] [] __warn+0xff/0x140
[87487.348513] [] warn_slowpath_fmt+0x4a/0x50
[87487.351659] [] __list_add+0xae/0x130
[87487.354772] [] ? _raw_spin_lock+0x64/0x70
[87487.357915] [] padata_reorder+0x1e6/0x420
[87487.361084] [] 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
---
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
Re: [PATCH] md5: remove from lib and only live in crypto
POKE?
crypto: out-of-bounds write in pre_crypt
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:7f20d831e858 EFLAGS: 0296 ORIG_RAX: 0013 RAX: ffda RBX: 00708000 RCX: 00445b79 RDX: 0003 RSI: 20e86000 RDI: 0019 RBP: 0086 R08: R09: R10: R11: 0296 R12: 004a7e31 R13: R14: 7f20d831e618 R15: 7f20d831e788 == BUG: KASAN: slab-out-of-bounds in pre_crypt+0x1078/0x1100 crypto/lrw.c:235 at addr 88005f17aee0 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:7f20d831e858 EFLAGS: 0296 ORIG_RAX: 0013 RAX: ffda RBX: 00708000 RCX: 00445b79 RDX: 0003 RSI: 20e86000 RDI: 0019 RBP: 0086 R08: R09: R10: R11: 0296 R12: 004a7e31 R13: R14: 7f20d831e618 R15: 7f20d831e788 Object at 88005f17a940, 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
Re: Question - seeding the hw pseudo random number generator
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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0
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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: race condition in kernel/padata.c
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
> (b17abfc043d0), but was 8dba70872c80. (prev=8dba70872b00).
> [87487.339011] [] dump_stack+0x68/0xa3
> [87487.342198] [] ? console_unlock+0x281/0x6d0
> [87487.345364] [] __warn+0xff/0x140
> [87487.348513] [] warn_slowpath_fmt+0x4a/0x50
> [87487.351659] [] __list_add+0xae/0x130
> [87487.354772] [] ? _raw_spin_lock+0x64/0x70
> [87487.357915] [] padata_reorder+0x1e6/0x420
> [87487.361084] [] 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!
Re: Question - seeding the hw pseudo random number generator
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
Re: Question - seeding the hw pseudo random number generator
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
