[PATCH AUTOSEL for 4.14 053/110] lib/mpi: Fix umul_ppmm() for MIPS64r6

[Sasha Levin]

From: James Hogan <jho...@kernel.org>

[ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ]

Current MIPS64r6 toolchains aren't able to generate efficient
DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
performs an unsigned 64 x 64 bit multiply and returns the upper and
lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
x 128 multiply. This is both inefficient, and it results in a link error
since we don't include __multi3 in MIPS linux.

For example commit 90a53e4432b1 ("cfg80211: implement regdb signature
checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
64r6el_defconfig builds by indirectly selecting MPILIB. The same build
errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:

lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
lib/mpi/mpih-div.o In function `mpihelp_divrem':
lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
lib/mpi/mpih-div.c:142: undefined reference to `__multi3'

Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
calls being emitted.

Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA")
Signed-off-by: James Hogan <jho...@kernel.org>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-m...@linux-mips.org
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
---
 lib/mpi/longlong.h | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
index 57fd45ab7af1..08c60d10747f 100644
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -671,7 +671,23 @@ do {   \
**  MIPS/64  **
***/
 #if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
+#if defined(__mips_isa_rev) && __mips_isa_rev >= 6
+/*
+ * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C
+ * code below, so we special case MIPS64r6 until the compiler can do better.
+ */
+#define umul_ppmm(w1, w0, u, v)
\
+do {   \
+   __asm__ ("dmulu %0,%1,%2"   \
+: "=d" ((UDItype)(w0)) \
+: "d" ((UDItype)(u)),  \
+  "d" ((UDItype)(v))); \
+   __asm__ ("dmuhu %0,%1,%2"   \
+: "=d" ((UDItype)(w1)) \
+: "d" ((UDItype)(u)),  \
+  "d" ((UDItype)(v))); \
+} while (0)
+#elif (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
 #define umul_ppmm(w1, w0, u, v) \
 do {   \
typedef unsigned int __ll_UTItype __attribute__((mode(TI)));\
-- 
2.11.0

[PATCH AUTOSEL for 4.9 22/52] lib/mpi: Fix umul_ppmm() for MIPS64r6

[Sasha Levin]

From: James Hogan <jho...@kernel.org>

[ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ]

Current MIPS64r6 toolchains aren't able to generate efficient
DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
performs an unsigned 64 x 64 bit multiply and returns the upper and
lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
x 128 multiply. This is both inefficient, and it results in a link error
since we don't include __multi3 in MIPS linux.

For example commit 90a53e4432b1 ("cfg80211: implement regdb signature
checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
64r6el_defconfig builds by indirectly selecting MPILIB. The same build
errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:

lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
lib/mpi/mpih-div.o In function `mpihelp_divrem':
lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
lib/mpi/mpih-div.c:142: undefined reference to `__multi3'

Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
calls being emitted.

Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA")
Signed-off-by: James Hogan <jho...@kernel.org>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-m...@linux-mips.org
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
---
 lib/mpi/longlong.h | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
index 93336502af08..0f64fcee4ccd 100644
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -671,7 +671,23 @@ do {   \
**  MIPS/64  **
***/
 #if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
+#if defined(__mips_isa_rev) && __mips_isa_rev >= 6
+/*
+ * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C
+ * code below, so we special case MIPS64r6 until the compiler can do better.
+ */
+#define umul_ppmm(w1, w0, u, v)
\
+do {   \
+   __asm__ ("dmulu %0,%1,%2"   \
+: "=d" ((UDItype)(w0)) \
+: "d" ((UDItype)(u)),  \
+  "d" ((UDItype)(v))); \
+   __asm__ ("dmuhu %0,%1,%2"   \
+: "=d" ((UDItype)(w1)) \
+: "d" ((UDItype)(u)),  \
+  "d" ((UDItype)(v))); \
+} while (0)
+#elif (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
 #define umul_ppmm(w1, w0, u, v) \
 do {   \
typedef unsigned int __ll_UTItype __attribute__((mode(TI)));\
-- 
2.11.0

[PATCH AUTOSEL for 4.4 11/32] lib/mpi: Fix umul_ppmm() for MIPS64r6

[Sasha Levin]

From: James Hogan <jho...@kernel.org>

[ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ]

Current MIPS64r6 toolchains aren't able to generate efficient
DMULU/DMUHU based code for the C implementation of umul_ppmm(), which
performs an unsigned 64 x 64 bit multiply and returns the upper and
lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit
inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128
x 128 multiply. This is both inefficient, and it results in a link error
since we don't include __multi3 in MIPS linux.

For example commit 90a53e4432b1 ("cfg80211: implement regdb signature
checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and
64r6el_defconfig builds by indirectly selecting MPILIB. The same build
errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA:

lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1':
lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1':
lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3'
lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1':
lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3'
lib/mpi/mpih-div.o In function `mpihelp_divrem':
lib/mpi/mpih-div.c:205: undefined reference to `__multi3'
lib/mpi/mpih-div.c:142: undefined reference to `__multi3'

Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using
inline assembly and the DMULU/DMUHU instructions, to prevent __multi3
calls being emitted.

Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA")
Signed-off-by: James Hogan <jho...@kernel.org>
Cc: Ralf Baechle <r...@linux-mips.org>
Cc: Herbert Xu <herb...@gondor.apana.org.au>
Cc: "David S. Miller" <da...@davemloft.net>
Cc: linux-m...@linux-mips.org
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
---
 lib/mpi/longlong.h | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/lib/mpi/longlong.h b/lib/mpi/longlong.h
index b90e255c2a68..d2ecf0a09180 100644
--- a/lib/mpi/longlong.h
+++ b/lib/mpi/longlong.h
@@ -671,7 +671,23 @@ do {   \
**  MIPS/64  **
***/
 #if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64
-#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
+#if defined(__mips_isa_rev) && __mips_isa_rev >= 6
+/*
+ * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C
+ * code below, so we special case MIPS64r6 until the compiler can do better.
+ */
+#define umul_ppmm(w1, w0, u, v)
\
+do {   \
+   __asm__ ("dmulu %0,%1,%2"   \
+: "=d" ((UDItype)(w0)) \
+: "d" ((UDItype)(u)),  \
+  "d" ((UDItype)(v))); \
+   __asm__ ("dmuhu %0,%1,%2"   \
+: "=d" ((UDItype)(w1)) \
+: "d" ((UDItype)(u)),  \
+  "d" ((UDItype)(v))); \
+} while (0)
+#elif (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4)
 #define umul_ppmm(w1, w0, u, v) \
 do {   \
typedef unsigned int __ll_UTItype __attribute__((mode(TI)));\
-- 
2.11.0

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

[Levin, Alexander (Sasha Levin)]

On Mon, Jun 26, 2017 at 07:30:19AM -0700, Dave Watson wrote:
>On 06/25/17 02:42 AM, Levin, Alexander (Sasha Levin) wrote:
>> On Wed, Jun 14, 2017 at 11:37:14AM -0700, Dave Watson wrote:
>> >Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP
>> >sockets. Based on a similar infrastructure in tcp_cong.  The idea is that 
>> >any
>> >ULP can add its own logic by changing the TCP proto_ops structure to its own
>> >methods.
>> >
>> >Example usage:
>> >
>> >setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
>> >
>> >modules will call:
>> >tcp_register_ulp(_tls_ulp_ops);
>> >
>> >to register/unregister their ulp, with an init function and name.
>> >
>> >A list of registered ulps will be returned by tcp_get_available_ulp, which 
>> >is
>> >hooked up to /proc.  Example:
>> >
>> >$ cat /proc/sys/net/ipv4/tcp_available_ulp
>> >tls
>> >
>> >There is currently no functionality to remove or chain ULPs, but
>> >it should be possible to add these in the future if needed.
>> >
>> >Signed-off-by: Boris Pismenny <bor...@mellanox.com>
>> >Signed-off-by: Dave Watson <davejwat...@fb.com>
>>
>> Hey Dave,
>>
>> I'm seeing the following while fuzzing, which was bisected to this commit:
>>
>> ==
>> BUG: KASAN: null-ptr-deref in copy_to_user include/linux/uaccess.h:168 
>> [inline]
>> BUG: KASAN: null-ptr-deref in do_tcp_getsockopt.isra.33+0x24f/0x1e30 
>> net/ipv4/tcp.c:3057
>> Read of size 4 at addr 0020 by task syz-executor1/15452
>
>At a glance, this looks like it was fixed already by
>
>https://www.mail-archive.com/netdev@vger.kernel.org/msg175226.html
>
>Can you recheck with that patch, or verify that you already have it?
>Thanks.

I've already tried this patch, it doesn't fix the issue I've reported.

-- 

Thanks,
Sasha

Re: [PATCH v3 net-next 1/4] tcp: ULP infrastructure

[Levin, Alexander (Sasha Levin)]

On Wed, Jun 14, 2017 at 11:37:14AM -0700, Dave Watson wrote:
>Add the infrustructure for attaching Upper Layer Protocols (ULPs) over TCP
>sockets. Based on a similar infrastructure in tcp_cong.  The idea is that any
>ULP can add its own logic by changing the TCP proto_ops structure to its own
>methods.
>
>Example usage:
>
>setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
>
>modules will call:
>tcp_register_ulp(_tls_ulp_ops);
>
>to register/unregister their ulp, with an init function and name.
>
>A list of registered ulps will be returned by tcp_get_available_ulp, which is
>hooked up to /proc.  Example:
>
>$ cat /proc/sys/net/ipv4/tcp_available_ulp
>tls
>
>There is currently no functionality to remove or chain ULPs, but
>it should be possible to add these in the future if needed.
>
>Signed-off-by: Boris Pismenny 
>Signed-off-by: Dave Watson 

Hey Dave,

I'm seeing the following while fuzzing, which was bisected to this commit:

==
BUG: KASAN: null-ptr-deref in copy_to_user include/linux/uaccess.h:168 [inline]
BUG: KASAN: null-ptr-deref in do_tcp_getsockopt.isra.33+0x24f/0x1e30 
net/ipv4/tcp.c:3057
Read of size 4 at addr 0020 by task syz-executor1/15452

CPU: 0 PID: 15452 Comm: syz-executor1 Not tainted 4.12.0-rc6-next-20170623+ #173
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 
04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x11d/0x1e5 lib/dump_stack.c:52
 kasan_report_error mm/kasan/report.c:349 [inline]
 kasan_report+0x15e/0x370 mm/kasan/report.c:408
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 check_memory_region+0x14b/0x1a0 mm/kasan/kasan.c:267
 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
 copy_to_user include/linux/uaccess.h:168 [inline]
 do_tcp_getsockopt.isra.33+0x24f/0x1e30 net/ipv4/tcp.c:3057
 tcp_getsockopt+0xb0/0xd0 net/ipv4/tcp.c:3194
 sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2863
 SYSC_getsockopt net/socket.c:1869 [inline]
 SyS_getsockopt+0x180/0x360 net/socket.c:1851
 do_syscall_64+0x267/0x740 arch/x86/entry/common.c:284
 entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x451759
RSP: 002b:7f5dc2b1fc08 EFLAGS: 0216 ORIG_RAX: 0037
RAX: ffda RBX: 00718000 RCX: 00451759
RDX: 001f RSI: 0006 RDI: 0005
RBP: 0c30 R08: 207bf000 R09: 
R10: 2ffc R11: 0216 R12: 004b824b
R13:  R14: 0005 R15: 0006
==
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 15452 Comm: syz-executor1 Tainted: GB   
4.12.0-rc6-next-20170623+ #173
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1 
04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x11d/0x1e5 lib/dump_stack.c:52
 panic+0x1bc/0x3ad kernel/panic.c:180
 kasan_end_report+0x47/0x4f mm/kasan/report.c:176
 kasan_report_error mm/kasan/report.c:356 [inline]
 kasan_report+0x167/0x370 mm/kasan/report.c:408
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 check_memory_region+0x14b/0x1a0 mm/kasan/kasan.c:267
 kasan_check_read+0x11/0x20 mm/kasan/kasan.c:272
 copy_to_user include/linux/uaccess.h:168 [inline]
 do_tcp_getsockopt.isra.33+0x24f/0x1e30 net/ipv4/tcp.c:3057
 tcp_getsockopt+0xb0/0xd0 net/ipv4/tcp.c:3194
 sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2863
 SYSC_getsockopt net/socket.c:1869 [inline]
 SyS_getsockopt+0x180/0x360 net/socket.c:1851
 do_syscall_64+0x267/0x740 arch/x86/entry/common.c:284
 entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x451759
RSP: 002b:7f5dc2b1fc08 EFLAGS: 0216 ORIG_RAX: 0037
RAX: ffda RBX: 00718000 RCX: 00451759
RDX: 001f RSI: 0006 RDI: 0005
RBP: 0c30 R08: 207bf000 R09: 
R10: 2ffc R11: 0216 R12: 004b824b
R13:  R14: 0005 R15: 0006
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: 0x2480 from 0x8100 (relocation range: 
0x8000-0xbfff)
Rebooting in 86400 seconds..

-- 

Thanks,
Sasha

Re: [PATCH v5 0/3] Add Support for Cavium Cryptographic Acceleration Unit

[Sasha Levin]

On Mon, Jan 30, 2017 at 7:30 AM, George Cherian
 wrote:
> This series adds the support for Cavium Cryptographic Accelerarion Unit (CPT)
> CPT is available in Cavium's Octeon-Tx SoC series.
>
> The series was tested with ecryptfs and dm-crypt for in kernel cryptographic
> offload operations. This driver needs a firmware to work, I will be sending 
> the
> firmware to linux-firmware once the driver is accepted.

Can we have the firmware now to be able to actually test this series?

Re: [PATCH v5 2/3] drivers: crypto: Add the Virtual Function driver for CPT

[Sasha Levin]

On Mon, Jan 30, 2017 at 7:30 AM, George Cherian
 wrote:
> diff --git a/drivers/crypto/cavium/cpt/cptvf_main.c 
> b/drivers/crypto/cavium/cpt/cptvf_main.c
> new file mode 100644
> index 000..4cf466d
> --- /dev/null
> +++ b/drivers/crypto/cavium/cpt/cptvf_main.c
> @@ -0,0 +1,948 @@
> +/*
> + * Copyright (C) 2016 Cavium, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License
> + * as published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +
> +#include "cptvf.h"
> +
> +#define DRV_NAME   "thunder-cptvf"
> +#define DRV_VERSION"1.0"
> +
> +struct cptvf_wqe {
> +   struct tasklet_struct twork;
> +   void *cptvf;
> +   u32 qno;
> +};
> +
> +struct cptvf_wqe_info {
> +   struct cptvf_wqe vq_wqe[CPT_NUM_QS_PER_VF];
> +};
> +
> +static void vq_work_handler(unsigned long data)
> +{
> +   struct cptvf_wqe_info *cwqe_info = (struct cptvf_wqe_info *)data;
> +   struct cptvf_wqe *cwqe = _info->vq_wqe[0];
> +
> +   vq_post_process(cwqe->cptvf, cwqe->qno);
> +}
> +
> +static int init_worker_threads(struct cpt_vf *cptvf)
> +{
> +   struct pci_dev *pdev = cptvf->pdev;
> +   struct cptvf_wqe_info *cwqe_info;
> +   int i;
> +
> +   cwqe_info = kzalloc(sizeof(*cwqe_info), GFP_KERNEL);
> +   if (!cwqe_info)
> +   return -ENOMEM;
> +
> +   if (cptvf->nr_queues) {
> +   dev_info(>dev, "Creating VQ worker threads (%d)\n",
> +cptvf->nr_queues);
> +   }
> +
> +   for (i = 0; i < cptvf->nr_queues; i++) {
> +   tasklet_init(_info->vq_wqe[i].twork, vq_work_handler,
> +(u64)cwqe_info);
> +   cwqe_info->vq_wqe[i].qno = i;
> +   cwqe_info->vq_wqe[i].cptvf = cptvf;
> +   }
> +
> +   cptvf->wqe_info = cwqe_info;
> +
> +   return 0;
> +}
> +
> +static void cleanup_worker_threads(struct cpt_vf *cptvf)
> +{
> +   struct cptvf_wqe_info *cwqe_info;
> +   struct pci_dev *pdev = cptvf->pdev;
> +   int i;
> +
> +   cwqe_info = (struct cptvf_wqe_info *)cptvf->wqe_info;
> +   if (!cwqe_info)
> +   return;
> +
> +   if (cptvf->nr_queues) {
> +   dev_info(>dev, "Cleaning VQ worker threads (%u)\n",
> +cptvf->nr_queues);
> +   }
> +
> +   for (i = 0; i < cptvf->nr_queues; i++)
> +   tasklet_kill(_info->vq_wqe[i].twork);
> +
> +   kzfree(cwqe_info);
> +   cptvf->wqe_info = NULL;
> +}
> +
> +static void free_pending_queues(struct pending_qinfo *pqinfo)
> +{
> +   int i;
> +   struct pending_queue *queue;
> +
> +   for_each_pending_queue(pqinfo, queue, i) {
> +   if (!queue->head)
> +   continue;
> +
> +   /* free single queue */
> +   kzfree((queue->head));
> +
> +   queue->front = 0;
> +   queue->rear = 0;
> +
> +   return;
> +   }
> +
> +   pqinfo->qlen = 0;
> +   pqinfo->nr_queues = 0;
> +}
> +
> +static int alloc_pending_queues(struct pending_qinfo *pqinfo, u32 qlen,
> +   u32 nr_queues)
> +{
> +   u32 i;
> +   size_t size;
> +   int ret;
> +   struct pending_queue *queue = NULL;
> +
> +   pqinfo->nr_queues = nr_queues;
> +   pqinfo->qlen = qlen;
> +
> +   size = (qlen * sizeof(struct pending_entry));
> +
> +   for_each_pending_queue(pqinfo, queue, i) {
> +   queue->head = kzalloc((size), GFP_KERNEL);
> +   if (!queue->head) {
> +   ret = -ENOMEM;
> +   goto pending_qfail;
> +   }
> +
> +   queue->front = 0;
> +   queue->rear = 0;
> +   atomic64_set((>pending_count), (0));
> +
> +   /* init queue spin lock */
> +   spin_lock_init(>lock);
> +   }
> +
> +   return 0;
> +
> +pending_qfail:
> +   free_pending_queues(pqinfo);
> +
> +   return ret;
> +}
> +
> +static int init_pending_queues(struct cpt_vf *cptvf, u32 qlen, u32 nr_queues)
> +{
> +   struct pci_dev *pdev = cptvf->pdev;
> +   int ret;
> +
> +   if (!nr_queues)
> +   return 0;
> +
> +   ret = alloc_pending_queues(>pqinfo, qlen, nr_queues);
> +   if (ret) {
> +   dev_err(>dev, "failed to setup pending queues (%u)\n",
> +   nr_queues);
> +   return ret;
> +   }
> +
> +   return 0;
> +}
> +
> +static void cleanup_pending_queues(struct cpt_vf *cptvf)
> +{
> +   struct pci_dev *pdev = cptvf->pdev;
> +
> +   if (!cptvf->nr_queues)
> +   return;
> +
> +   dev_info(>dev, "Cleaning VQ pending queue (%u)\n",
> +cptvf->nr_queues);
> +   free_pending_queues(>pqinfo);
> +}
> +
> +static void free_command_queues(struct 

Re: [RFC PATCH 1/3] crypto: zip - Add ThunderX ZIP driver core

[Sasha Levin]

On Mon, Dec 12, 2016 at 10:04 AM, Jan Glauber  wrote:
> +/* error messages */
> +#define zip_err(fmt, args...) pr_err("ZIP ERR:%s():%d: " \
> + fmt "\n", __func__, __LINE__, ## args)
> +
> +#ifdef MSG_ENABLE
> +/* Enable all messages */
> +#define zip_msg(fmt, args...) pr_info("ZIP_MSG:" fmt "\n", ## args)
> +#else
> +#define zip_msg(fmt, args...)
> +#endif
> +
> +#if defined(ZIP_DEBUG_ENABLE) && defined(MSG_ENABLE)
> +
> +#ifdef DEBUG_LEVEL
> +
> +#define FILE_NAME (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : \
> +   strrchr(__FILE__, '\\') ? strrchr(__FILE__, '\\') + 1 : __FILE__)
> +
> +#if DEBUG_LEVEL >= 4
> +
> +#define zip_dbg(fmt, args...) pr_info("ZIP DBG: %s: %s() : %d: " \
> + fmt "\n", FILE_NAME, __func__, __LINE__, ## 
> args)
> +
> +#define zip_dbg_enter(fmt, args...) pr_info("ZIP_DBG: %s() in %s" \
> +   fmt "\n", __func__, FILE_NAME, ## args)
> +
> +#define zip_dbg_exit(fmt, args...) pr_info("ZIP_DBG:Exit %s() in %s" \
> +  fmt "\n", __func__, FILE_NAME, ## args)
> +
> +#elif DEBUG_LEVEL >= 3
> +
> +#define zip_dbg(fmt, args...) pr_info("ZIP DBG: %s: %s() : %d: " \
> + fmt "\n", FILE_NAME, __func__, __LINE__, ## 
> args)
> +
> +#elif DEBUG_LEVEL >= 2
> +
> +#define zip_dbg(fmt, args...) pr_info("ZIP DBG: %s() : %d: " \
> + fmt "\n", __func__, __LINE__, ## args)
> +
> +#else
> +
> +#define zip_dbg(fmt, args...) pr_info("ZIP DBG:" fmt "\n", ## args)
> +
> +#endif /* DEBUG LEVEL >= */
> +
> +#if DEBUG_LEVEL <= 3
> +
> +#define zip_dbg_enter(fmt, args...)
> +#define zip_dbg_exit(fmt, args...)
> +
> +#endif /* DEBUG_LEVEL <= 3 */
> +#else
> +
> +#define zip_dbg(fmt, args...) pr_info("ZIP DBG:" fmt "\n", ## args)
> +
> +#define zip_dbg_enter(fmt, args...)
> +#define zip_dbg_exit(fmt, args...)
> +
> +#endif /* DEBUG_LEVEL */
> +#else
> +
> +#define zip_dbg(fmt, args...)
> +#define zip_dbg_enter(fmt, args...)
> +#define zip_dbg_exit(fmt, args...)
> +
> +#endif /* ZIP_DEBUG_ENABLE */

The whole zip_dbg_[enter,exit] thing can be just done with tracepoints
instead of reinventing the wheel. No reason to carry that code

> +u32 zip_load_instr(union zip_inst_s *instr,
> +  struct zip_device *zip_dev)
> +{
> +   union zip_quex_doorbell dbell;
> +   u32 queue = 0;
> +   u32 consumed = 0;
> +   u64 *ncb_ptr = NULL;
> +   union zip_nptr_s ncp;
> +
> +   /*
> +* Distribute the instructions between the enabled queues based on
> +* the CPU id.
> +*/
> +   if (raw_smp_processor_id() % 2 == 0)
> +   queue = 0;
> +   else
> +   queue = 1;

Is this just simplistic load balancing scheme? There's no guarantee
that the cpu won't change later on.

> +
> +   /* Poll for the IQ cmd completion code */
> +   zip_dbg_exit();

The comment doesn't match with what actually happens?

> +static inline u64 zip_depth(void)
> +{
> +   struct zip_device *zip_dev = zip_get_device(zip_get_node_id());
> +
> +   if (!zip_dev)
> +   return -ENODEV;
> +
> +   return zip_dev->depth;
> +}
> +
> +static inline u64 zip_onfsize(void)
> +{
> +   struct zip_device *zip_dev = zip_get_device(zip_get_node_id());
> +
> +   if (!zip_dev)
> +   return -ENODEV;
> +
> +   return zip_dev->onfsize;
> +}
> +
> +static inline u64 zip_ctxsize(void)
> +{
> +   struct zip_device *zip_dev = zip_get_device(zip_get_node_id());
> +
> +   if (!zip_dev)
> +   return -ENODEV;
> +
> +   return zip_dev->ctxsize;
> +}

Where is it all used?

> +/*
> + * Allocates new ZIP device structure
> + * Returns zip_device pointer or NULL if cannot allocate memory for 
> zip_device
> + */
> +static struct zip_device *zip_alloc_device(struct pci_dev *pdev)
> +{
> +   struct zip_device *zip = NULL;
> +   int idx = 0;
> +
> +   for (idx = 0; idx < MAX_ZIP_DEVICES; idx++) {
> +   if (!zip_dev[idx])
> +   break;
> +   }
> +
> +   zip = kzalloc(sizeof(*zip), GFP_KERNEL);
> +
> +   if (!zip)
> +   return NULL;
> +
> +   zip_dev[idx] = zip;

If for some odd reason we try to allocate more than MAX_ZIP_DEVICES
this will deref an invalid pointer.

> +/**
> + * zip_get_device - Get ZIP device based on node id of cpu
> + *
> + * @node: Node id of the current cpu
> + * Return: Pointer to Zip device structure
> + */
> +struct zip_device *zip_get_device(int node)
> +{
> +   if ((node < MAX_ZIP_DEVICES) && (node >= 0))
> +   return zip_dev[node];
> +
> +   zip_err("ZIP device not found for node id %d\n", node);
> +   return NULL;
> +}
> +
> +/**
> + * zip_get_node_id - Get the node id of the current cpu
> + *
> + * Return: Node id of the current cpu
> + */
> +int zip_get_node_id(void)
> +{
> +   return 

Re: linux/bitops.h

[Sasha Levin]

On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
> On 05/04/16 15:06, John Denker wrote:
>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
 Beware that shifting by an amount >= the number of bits in the
 word remains Undefined Behavior.
>>
>>> This construct has been supported as a rotate since at least gcc2.
>>
>> How then should we understand the story told in commit d7e35dfa?
>> Is the story wrong?
>>
>> At the very least, something inconsistent is going on.  There
>> are 8 functions.  Why did d7e35dfa change one of them but
>> not the other 7?
> 
> Yes. d7e35dfa is baloney IMNSHO.  All it does is produce worse code, and the 
> description even says so.

No, the description says that it produces worse code for *really really* ancient
GCC versions.

> As I said, gcc has treated the former code as idiomatic since gcc 2, so that 
> support is beyond ancient.

Because something works in a specific way on one compiler isn't a reason to
ignore this noncompliance with the standard.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 04/18/2016 04:56 PM, Thomas D. wrote:
> Hi,
> 
> Milan Broz wrote:
>> could you please try backported patches here
>> https://mbroz.fedorapeople.org/tmp/3.18/ ?
> 
> This patch set works for me and fixes my reported problem (tested
> against 3.18.30).
> 
> Thank you!

Excellent, I'll add this in and release. Thank you both.

Sorry for missing it on my end.


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 04/18/2016 05:48 AM, Thomas D. wrote:
> Hi,
> 
> Milan's patches apply against 3.18.30, however I am getting build errors:

Milan, Herbert, should I just be reverting the offending patches:

bcfa841 crypto: af_alg - Forbid bind(2) when nokey child sockets are present
eb1ab00 crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey 
path
3db68eb crypto: af_alg - Add nokey compatibility path
ac9c75f crypto: af_alg - Fix socket double-free when accept fails
f857638 crypto: af_alg - Disallow bind/setkey/... after accept(2)

Or will you send me a backport?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 04/17/2016 06:17 PM, Thomas D. wrote:
> Hi,
> 
> Sasha, can you please revert commit
> f857638dd72680e2a8faafef7eebb4534cb39fd1 like Greg did with linux-3.10.101
> 
>> commit 1f2493fcd87bd810c608aa7976388157852eadb2
>> Author: Greg Kroah-Hartman 
>> Date:   Sat Mar 12 21:30:16 2016 -0800
>>
>> Revert: "crypto: af_alg - Disallow bind/setkey/... after accept(2)"
>> 
>> This reverts commit 5a707f0972e1c9d8a4a921ddae79d0f9dc36a341 which is
>> commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.
>> 
>> It's been widely reported that this patch breaks existing userspace
>> applications when backported to the stable kernel releases.  As no fix
>> seems to be forthcoming, just revert it to let systems work again.
> 
> and linux-3.14.65
> 
>> commit c4eb62da6f34bfa9bbcbd005210a90fdfca7e367
>> Author: Greg Kroah-Hartman 
>> Date:   Sat Mar 12 21:30:16 2016 -0800
>>
>> Revert: "crypto: af_alg - Disallow bind/setkey/... after accept(2)"
>> 
>> This reverts commit 06b4194533ff92ed540e3a6beaf29a8fe5d4 which is
>> commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream.
>> 
>> It's been widely reported that this patch breaks existing userspace
>> applications when backported to the stable kernel releases.  As no fix
>> seems to be forthcoming, just revert it to let systems work again.
> 
> 
> Linux-3.18.x is the only LTS kernel left with this problem. If nobody
> cares we should at least revert back to a working kernel...

So I mixed stuff up here, I've received a backport that would fix this problem
on 4.1, and applied it. However, I forgot about 3.18.

Would Milan's backport work on 3.18 as well 
(https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg17949.html)?


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 02/26/2016 06:25 AM, Milan Broz wrote:
> On 02/24/2016 06:12 PM, Greg KH wrote:
>> On Wed, Feb 24, 2016 at 09:54:48AM +0100, Milan Broz wrote:
>>> On 02/24/2016 09:32 AM, Jiri Slaby wrote:
> + af_alg_release_parent(sk);

 and this occurs to me like a double release?
>>>
>>> yes, my copy mistake.
>>
>> Which is why I want the real patches backported please.  Whenever we do
>> a "just this smaller patch" for a stable kernel, it is ALWAYS wrong.
> 
> I think that it was clear that I do not want you to directly include
> this patch, just it points to the direction where is the problem.
> 
> Anyway, seems the problem is only in 4.1.18.
> 
>> Please backport the patches in a correct way so that we can apply
>> them...
> 
> Not sure if it is still needed, but I'll reply to this thread with my git 
> version
> of backported patches for 4.1.18.
> (Resp. only the first need changes, other then applied cleanly from upstream).

Please do.


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 02/23/2016 04:02 PM, Milan Broz wrote:
> On 02/21/2016 05:40 PM, Milan Broz wrote:
>> > On 02/20/2016 03:33 PM, Thomas D. wrote:
>>> >> Hi,
>>> >>
>>> >> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected.
>>> >>
>>> >> v4.3.6 works. Looks like the patch set is only compatible with 
>>> >> >=linux-4.3.
>>> >>
>>> >> v3.12.54 works because it doesn't contain the patch in question.
>> > 
>> > Hi,
>> > 
>> > indeed, because whoever backported this patchset skipped two patches
>> > from series (because of skcipher interface file was introduced later).
> Ping?
> 
> I always thought that breaking userspace is not the way mainline kernel
> operates and here we break even stable tree...
> 
> Anyone planning to release new kernel version with properly backported 
> patches?
> There is already a lot of downstream distro bugs reported.

Hi Milan,

I'd really like to see an ack on your patch by one of the crypto/ maintainers
before putting it into a -stable release.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: algif_hash - correctly handle algos without state

[Sasha Levin]

Algorithms without state will cause the creation of a 0 sized array, which
is undefined outside of structs.

Signed-off-by: Sasha Levin <sasha.le...@oracle.com>
---
 crypto/algif_hash.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 68a5cea..a9f923f 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -184,7 +184,7 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
struct alg_sock *ask = alg_sk(sk);
struct hash_ctx *ctx = ask->private;
struct ahash_request *req = >req;
-   char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
+   char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))?:1];
struct sock *sk2;
struct alg_sock *ask2;
struct hash_ctx *ctx2;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 02/17/2016 10:24 AM, Thomas D. wrote:
> Hi,
> 
> Sasha Levin wrote:
>> > So either the upstream patch is broken, or the 4.1 backport is 
>> > wrong/missing
>> > dependency/missing fix.
>> > 
>> > Any chance you could try 4.5-rc3 and see if that works for you? That'll 
>> > narrow
>> > it down a lot.
> 4.5-rc3 works for me.
> 
> Linux-4.4.0 works, too.

Herbert,

Is there a dependency I missed in 4.1? I don't really see anything that
could have gone wrong there.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Broken userspace crypto in linux-4.1.18

[Sasha Levin]

On 02/17/2016 09:04 AM, Thomas D. wrote:
> Hi,
> 
> something is broken with crypto in linux-4.1.18.
> 
> On my system I have two disks (sda and sdb), both encrypted with LUKS
> (cipher=aes-xts-plain64).
> 
> My rootfs resides encrypted on sda2 (sda1 is an unencrypted boot
> partition).
> sdb has one full encrypted partition (sdb1) mounted in "/backup".
> 
> After I upgraded from linux-4.1.17 to linux-4.1.18 and rebooted I noticed
> that my encrypted rootfs was opened successfully (must be my initramfs)
> however opening sdb1 with key file failed:

Thanks for the report Thomas.

[...]

> After I bisect the kernel I found the following bad commit:
> 
>> commit 0571ba52a19e18a1c20469454231eef681cb1310
>> Author: Herbert Xu 
>> Date:   Wed Dec 30 11:47:53 2015 +0800
>>
>> crypto: af_alg - Disallow bind/setkey/... after accept(2)
>>
>> [ Upstream commit c840ac6af3f8713a71b4d2363419145760bd6044 ]
>>
>> Each af_alg parent socket obtained by socket(2) corresponds to a
>> tfm object once bind(2) has succeeded.  An accept(2) call on that
>> parent socket creates a context which then uses the tfm object.
>>
>> Therefore as long as any child sockets created by accept(2) exist
>> the parent socket must not be modified or freed.
>>
>> This patch guarantees this by using locks and a reference count
>> on the parent socket.  Any attempt to modify the parent socket will
>> fail with EBUSY.

So either the upstream patch is broken, or the 4.1 backport is wrong/missing
dependency/missing fix.

Any chance you could try 4.5-rc3 and see if that works for you? That'll narrow
it down a lot.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crypto: algif_hash: creating 0 sized array in hash_accept

[Sasha Levin]

On 01/25/2016 08:58 AM, Herbert Xu wrote:
> On Mon, Jan 25, 2016 at 07:14:20AM -0500, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next 
>> kernel
>> I've hit:
>>
>> [  828.386074] UBSAN: Undefined behaviour in crypto/algif_hash.c:185:7
>> [  828.386811] variable length array bound value 0 <= 0
>> [  828.387606] CPU: 1 PID: 17792 Comm: trinity-c313 Not tainted 
>> 4.4.0-next-20160122-sasha-00019-gd2a2eb4-dirty #2819
>> [  828.388957]  110038e06f65 87690421 8801c7037ba8 
>> a34474f1
>> [  828.394655]  41b58ab3 af84c518 a3447426 
>> 8801c7037b70
>> [  828.394684]  87690421 b329b1e0 8801c7037c38 
>> 
>> [  828.394708] Call Trace:
>> [  828.394868] dump_stack (lib/dump_stack.c:52)
>> [  828.395040] ? _atomic_dec_and_lock (lib/dump_stack.c:27)
>> [  828.395079] ubsan_epilogue (lib/ubsan.c:165)
>> [  828.395101] __ubsan_handle_vla_bound_not_positive (lib/ubsan.c:364)
>> [  828.395118] ? __ubsan_handle_out_of_bounds (lib/ubsan.c:352)
>> [  828.395179] ? sock_alloc_file (net/socket.c:388)
>> [  828.395194] ? sock_splice_read (net/socket.c:356)
>> [  828.395217] ? check_preemption_disabled (lib/smp_processor_id.c:52)
>> [  828.395244] hash_accept (crypto/algif_hash.c:185 (discriminator 1))
>> [  828.395264] SYSC_accept4 (net/socket.c:1476)
>> [  828.395282] ? sockfd_lookup_light (net/socket.c:1427)
>> [  828.395319] ? _raw_spin_unlock_bh (kernel/locking/spinlock.c:208)
>> [  828.395339] ? release_sock (net/core/sock.c:2446)
>> [  828.395645] ? hash_accept_parent_nokey (crypto/algif_hash.c:380)
>> [  828.396457] ? map_id_down (kernel/user_namespace.c:201)
>> [  828.396484] ? SyS_futex (kernel/futex.c:3099)
>> [  828.396502] ? do_futex (kernel/futex.c:3099)
>> [  828.396519] ? SyS_socket (net/socket.c:1213)
>> [  828.396536] ? move_addr_to_kernel (net/socket.c:1213)
>> [  828.396552] SyS_accept (net/socket.c:1506)
>> [  828.396569] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
>> [  828.396596] ? vm_mmap_pgoff (mm/util.c:325)
>>
>> Which is this code snippet:
>>
>> static int hash_accept(struct socket *sock, struct socket *newsock, int 
>> flags)
>> {
>> struct sock *sk = sock->sk;
>> struct alg_sock *ask = alg_sk(sk);
>> struct hash_ctx *ctx = ask->private;
>> struct ahash_request *req = >req;
>> char state[crypto_ahash_statesize(crypto_ahash_reqtfm(req))];
>>
>>
>> Where crypto_ahash_statesize(crypto_ahash_reqtfm(req)) == 0.
> 
> This should not be possible because we forbid any algorithm with
> a zero statesize from being registered.  Please tell us what
> algorithm you were using that led to this crash.

Hey Herbert,

This seems to be happening with "digest_null".


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crypto: algif_hash: creating 0 sized array in hash_accept

[Sasha Levin]

On 01/26/2016 09:07 AM, Herbert Xu wrote:
> On Tue, Jan 26, 2016 at 08:26:41AM -0500, Sasha Levin wrote:
>> >
>> > This seems to be happening with "digest_null".
> In that case this is expected as digest_null obviously has no
> state.  So why is a zero-length array disallowed by ubsan?

The C spec forbids it, so ubsan complains :)


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mm: kill kmemcheck

[Sasha Levin]

On 03/11/2015 01:20 PM, David Miller wrote:
 From: Sasha Levin sasha.le...@oracle.com
 Date: Wed, 11 Mar 2015 09:39:33 -0400
 
  On 03/11/2015 08:40 AM, Steven Rostedt wrote:
  On Wed, 11 Mar 2015 08:34:46 -0400
  Sasha Levin sasha.le...@oracle.com wrote:
  
   Fair enough. We knew there are existing kmemcheck users, but KASan 
   should be
   superior both in performance and the scope of bugs it finds. It 
   also shouldn't
   impose new limitations beyond requiring gcc 4.9.2+.
  
  Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3.
  
  It will be a while before I upgrade my build farm to something newer.
  
  Are you actually compiling new kernels with 4.6.3, or are you using older
  kernels as well?
  
  There's no real hurry to kill kmemcheck right now, but we do want to stop
  supporting that in favour of KASan.
 Is the spectrum of CPU's supported by this GCC feature equal to all of the
 CPU's supported by the kernel right now?
 
 If not, removing kmemcheck will always be a regression for someone.

You're probably wondering why there are changes to SPARC in that patchset? :)

I don't really know. Both kmemcheck and KASan run only on x86. I've also asked
Vegard, who didn't know either... I guess it got copy-pasted from a different
code.

As far as I know the only regression is requiring newer GCC.


Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mm: kill kmemcheck

[Sasha Levin]

On 03/11/2015 08:40 AM, Steven Rostedt wrote:
 On Wed, 11 Mar 2015 08:34:46 -0400
 Sasha Levin sasha.le...@oracle.com wrote:
 
  Fair enough. We knew there are existing kmemcheck users, but KASan should 
  be
  superior both in performance and the scope of bugs it finds. It also 
  shouldn't
  impose new limitations beyond requiring gcc 4.9.2+.
 
 Ouch! OK, then I can't use it. I'm currently compiling with gcc 4.6.3.
 
 It will be a while before I upgrade my build farm to something newer.

Are you actually compiling new kernels with 4.6.3, or are you using older
kernels as well?

There's no real hurry to kill kmemcheck right now, but we do want to stop
supporting that in favour of KASan.


Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mm: kill kmemcheck

[Sasha Levin]

On 03/11/2015 08:19 AM, Steven Rostedt wrote:
 I removed the Cc list as it was so large, I'm sure that it exceeded the
 LKML Cc size limit, and your email probably didn't make it to the list
 (or any of them).

Thanks. I'll resend in a bit if it doesn't show up on lkml.org.

 On Wed, 11 Mar 2015 07:43:59 -0400
 Sasha Levin sasha.le...@oracle.com wrote:
 
  As discussed on LSF/MM, kill kmemcheck.
  
  KASan is a replacement that is able to work without the limitation of
  kmemcheck (single CPU, slow). KASan is already upstream.
  
  We are also not aware of any users of kmemcheck (or users who don't 
  consider
  KASan as a suitable replacement).
 I use kmemcheck and I am unaware of KASan. I'll try to play with KASan
 and see if it suites my needs.

Fair enough. We knew there are existing kmemcheck users, but KASan should be
superior both in performance and the scope of bugs it finds. It also shouldn't
impose new limitations beyond requiring gcc 4.9.2+.


Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mm: kill kmemcheck

[Sasha Levin]

On 03/11/2015 10:26 AM, Steven Rostedt wrote:
 There's no real hurry to kill kmemcheck right now, but we do want to stop
  supporting that in favour of KASan.
 Understood, but the kernel is suppose to support older compilers.
 Perhaps we can keep kmemcheck for now and say it's obsoleted if you
 have a newer compiler. Because it will be a while before I upgrade my
 compilers. I don't upgrade unless I have a good reason to do so. Not
 sure KASan fulfills that requirement.

It's not that there's a performance overhead with kmemcheck, it's the
maintenance effort that we want to get rid of.

The kernel should keep supporting old kernels, and after this kmemcheck
removal your kernel will still keep working - this is more of a removal
of a mostly unused feature that had hooks everywhere in the kernel.

Did you actually find anything recently with kmemcheck? How do you deal
with the 1 CPU limit and the massive performance hit?

Could you try KASan for your use case and see if it potentially uncovers
anything new?


Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

crypto: gpf on boot with linux-next

[Sasha Levin]

Hi all,

I'm seeing the following panic when booting the latest linux-next kernel:

[   44.210559] general protection fault:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   44.210618] CPU 0 
[   44.210618] Pid: 1, comm: swapper/0 Tainted: GW
3.5.0-rc3-next-20120622-sasha-dirty #457  
[   44.210618] RIP: 0010:[811644b0]  [811644b0] 
__lock_acquire+0x110/0x4b0
[   44.210618] RSP: 0018:89519a519aa0  EFLAGS: 00010002
[   44.210618] RAX: 6b6b6b6b6b6b6b6b RBX: 89519a51 RCX: 
[   44.210618] RDX:  RSI:  RDI: 
[   44.210618] RBP: 89519a519b00 R08: 0001 R09: 0001
[   44.210618] R10:  R11: 0001 R12: 0002
[   44.210618] R13: 8951806f0a40 R14:  R15: 
[   44.210618] FS:  () GS:89525ba0() 
knlGS:
[   44.210618] CS:  0010 DS:  ES:  CR0: 8005003b
[   44.210618] CR2:  CR3: 04825000 CR4: 06f0
[   44.210618] DR0:  DR1:  DR2: 
[   44.210618] DR3:  DR6: 0ff0 DR7: 0400
[   44.210618] Process swapper/0 (pid: 1, threadinfo 89519a518000, task 
89519a51)
[   44.210618] Stack:
[   44.210618]  89519a519ae0 810ffa20 89519a519b00 
85374700
[   44.210618]  85374700 fffd0333 89519a519ae0 
89519a51
[   44.210618]   0002  

[   44.210618] Call Trace:
[   44.210618]  [810ffa20] ? del_timer_sync+0x120/0x140
[   44.210618]  [811649da] lock_acquire+0x18a/0x1e0
[   44.210618]  [836fd47a] ? wait_for_common+0x10a/0x170
[   44.210618]  [836ff171] _raw_spin_lock_irq+0x61/0xa0
[   44.210618]  [836fd47a] ? wait_for_common+0x10a/0x170
[   44.210618]  [836fd47a] wait_for_common+0x10a/0x170
[   44.210618]  [81133d40] ? try_to_wake_up+0x290/0x290
[   44.210618]  [836fd52e] 
wait_for_completion_interruptible_timeout+0xe/0x10
[   44.210618]  [81913a77] cryptomgr_schedule_probe+0x2d7/0x310
[   44.210618]  [81913c75] cryptomgr_notify+0x25/0x40
[   44.210618]  [811231be] notifier_call_chain+0xee/0x130
[   44.210618]  [811235a6] __blocking_notifier_call_chain+0xa6/0xd0
[   44.210618]  [8112174e] ? up_write+0x1e/0x40
[   44.210618]  [811235e1] blocking_notifier_call_chain+0x11/0x20
[   44.210618]  [8190ad89] crypto_probing_notify+0x29/0x50
[   44.210618]  [8190b479] crypto_alg_mod_lookup+0x39/0x80
[   44.210618]  [8190b52c] crypto_alloc_base+0x3c/0xb0
[   44.210618]  [851675a5] ? af_rxrpc_init+0x1a3/0x1a3
[   44.210618]  [851675ed] rxkad_init+0x48/0x69
[   44.210618]  [850cf639] do_one_initcall+0x7a/0x155
[   44.210618]  [850cf7db] do_basic_setup+0x9c/0xba
[   44.210618]  [850cf7f9] ? do_basic_setup+0xba/0xba
[   44.210618]  [850f1173] ? smp_init+0x8a/0x92
[   44.210618]  [850cfa5c] kernel_init+0x208/0x28a
[   44.210618]  [83701e34] kernel_thread_helper+0x4/0x10
[   44.210618]  [837000b4] ? retint_restore_args+0x13/0x13
[   44.210618]  [850cf854] ? repair_env_string+0x5b/0x5b
[   44.210618]  [83701e30] ? gs_change+0x13/0x13
[   44.210618] Code: 4d b8 44 89 4d b0 4c 89 55 a8 4c 89 ef e8 39 b4 ff ff 8b 
4d b8 48 85 c0 44 8b 4d b0 4c 8b 55 a8 0f 84 7d 03 00 00 0f 1f 44 00 00 f0 ff 
80 98 01 00 00 8b 15 27 f2 1c 04 44 8b b3 f0 08 00 00 85 
[   44.210618] RIP  [811644b0] __lock_acquire+0x110/0x4b0
[   44.210618]  RSP 89519a519aa0
[   44.210618] ---[ end trace 8f6ca168297608b8 ]---

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 17:43 -0400, Steve Grubb wrote:
 On Wednesday, September 07, 2011 05:35:18 PM Jarod Wilson wrote:
  Another proposal that has been kicked around: a 3rd random chardev, 
  which implements this functionality, leaving urandom unscathed. Some 
  udev magic or a driver param could move/disable/whatever urandom and put 
  this alternate device in its place. Ultimately, identical behavior, but 
  the true urandom doesn't get altered at all.
 
 Right, and that's what I was trying to say is that if we do all that and 
 switch out 
 urandom with something new that does what we need, what's the difference in 
 just 
 patching the behavior into urandom and calling it a day? Its simpler, less 
 fragile, 
 admins won't make mistakes setting up the wrong one in a chroot, already has 
 the 
 FIPS-140 dressing, and is auditable.

Whats the difference between changing the behavior of a well defined
interface (/dev/urandom) which may cause userspace applications to fail,
in opposed to a non-intrusive usermode CUSE driver which can do exactly
what you need (and more - if more is required in the future)? None, none
at all...

CUSE supports kernel auditing, admins making mistakes is hardly the
kernels' problem (unless it makes it easy for them to do mistakes) and
code moved into the kernel doesn't suddenly become more stable and
simpler.

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote:
 Certain security-related certifications and their respective review
 bodies have said that they find use of /dev/urandom for certain
 functions, such as setting up ssh connections, is acceptable, but if and
 only if /dev/urandom can block after a certain threshold of bytes have
 been read from it with the entropy pool exhausted. Initially, we were
 investigating increasing entropy pool contributions, so that we could
 simply use /dev/random, but since that hasn't (yet) panned out, and
 upwards of five minutes to establsh an ssh connection using an
 entropy-starved /dev/random is unacceptable, we started looking at the
 blocking urandom approach.

Can't you accomplish this in userspace by trying to read as much as you
can out of /dev/random without blocking, then reading out
of /dev/urandom the minimum between allowed threshold and remaining
bytes, and then blocking on /dev/random?

For example, lets say you need 100 bytes of randomness, and your
threshold is 30 bytes. You try reading out of /dev/random and get 50
bytes, at that point you'll read another 30 (=threshold) bytes
out /dev/urandom and then you'll need to block on /dev/random until you
get the remaining 20 bytes.

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote:
 Sasha Levin wrote:
  On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote:
  Certain security-related certifications and their respective review
  bodies have said that they find use of /dev/urandom for certain
  functions, such as setting up ssh connections, is acceptable, but if and
  only if /dev/urandom can block after a certain threshold of bytes have
  been read from it with the entropy pool exhausted. Initially, we were
  investigating increasing entropy pool contributions, so that we could
  simply use /dev/random, but since that hasn't (yet) panned out, and
  upwards of five minutes to establsh an ssh connection using an
  entropy-starved /dev/random is unacceptable, we started looking at the
  blocking urandom approach.
 
  Can't you accomplish this in userspace by trying to read as much as you
  can out of /dev/random without blocking, then reading out
  of /dev/urandom the minimum between allowed threshold and remaining
  bytes, and then blocking on /dev/random?
 
  For example, lets say you need 100 bytes of randomness, and your
  threshold is 30 bytes. You try reading out of /dev/random and get 50
  bytes, at that point you'll read another 30 (=threshold) bytes
  out /dev/urandom and then you'll need to block on /dev/random until you
  get the remaining 20 bytes.
 
 We're looking for a generic solution here that doesn't require 
 re-educating every single piece of userspace. [...]

A flip-side here is that you're going to break every piece of userspace
which assumed (correctly) that /dev/urandom never blocks. Since this is
a sysctl you can't fine tune which processes/threads/file-handles will
block on /dev/urandom and which ones won't.

 [..] And anything done in 
 userspace is going to be full of possible holes [..]

Such as? Is there an example of a case which can't be handled in
userspace?

  [..] there needs to be 
 something in place that actually *enforces* the policy, and centralized 
 accounting/tracking, lest you wind up with multiple processes racing to 
 grab the entropy.

Does the weak entropy you get out of /dev/urandom get weaker the more
you pull out of it? I assumed that this change is done because you want
to limit the amount of weak entropy mixed in with strong entropy.


btw, Is the threshold based on a research done on the linux RNG? Or is
it an arbitrary number that would be set by your local sysadmin? 

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 15:30 -0400, Jarod Wilson wrote:
 Sasha Levin wrote:
  On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote:
  Sasha Levin wrote:
  [..] And anything done in
  userspace is going to be full of possible holes [..]
 
  Such as? Is there an example of a case which can't be handled in
  userspace?
 
 How do you mandate preventing reads from urandom when there isn't 
 sufficient entropy? You likely wind up needing to restrict access to the 
 actual urandom via permissions and selinux policy or similar, and then 
 run a daemon or something that provides a pseudo-urandom that brokers 
 access to the real urandom. Get the permissions or policy wrong, and 
 havoc ensues. An issue with the initscript or udev rule to hide the real 
 urandom, and things can fall down. Its a whole lot more fragile than 
 this approach, and a lot more involved in setting it up.

Replace /dev/urandom with a simple CUSE driver, redirect reads to the
real urandom after applying your threshold.

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote:
 On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote:
  On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote:
   We're looking for a generic solution here that doesn't require
   re-educating every single piece of userspace. And anything done in
   userspace is going to be full of possible holes -- there needs to be
   something in place that actually *enforces* the policy, and
   centralized accounting/tracking, lest you wind up with multiple
   processes racing to grab the entropy.
  
  Yeah, but there are userspace programs that depend on urandom not
  blocking... so your proposed change would break them.
 
 The only time this kicks in is when a system is under attack. If you have set 
 this and 
 the system is running as normal, you will never notice it even there. Almost 
 all uses 
 of urandom grab 4 bytes and seed openssl or libgcrypt or nss. It then uses 
 those 
 libraries. There are the odd cases where something uses urandom to generate a 
 key or 
 otherwise grab a chunk of bytes, but these are still small reads in the 
 scheme of 
 things. Can you think of any legitimate use of urandom that grabs 100K or 1M 
 from 
 urandom? Even those numbers still won't hit the sysctl on a normally function 
 system.
 

As far as I remember, several wipe utilities are using /dev/urandom to
overwrite disks (possibly several times).

Something similar probably happens for getting junk on disks before
creating an encrypted filesystem on top of them.

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote:
 On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote:
  On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote:
   On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote:
On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote:
 We're looking for a generic solution here that doesn't require
 re-educating every single piece of userspace. And anything done in
 userspace is going to be full of possible holes -- there needs to be
 something in place that actually *enforces* the policy, and
 centralized accounting/tracking, lest you wind up with multiple
 processes racing to grab the entropy.

Yeah, but there are userspace programs that depend on urandom not
blocking... so your proposed change would break them.
   
   The only time this kicks in is when a system is under attack. If you have
   set this and the system is running as normal, you will never notice it
   even there. Almost all uses of urandom grab 4 bytes and seed openssl or
   libgcrypt or nss. It then uses those libraries. There are the odd cases
   where something uses urandom to generate a key or otherwise grab a chunk
   of bytes, but these are still small reads in the scheme of things. Can
   you think of any legitimate use of urandom that grabs 100K or 1M from
   urandom? Even those numbers still won't hit the sysctl on a normally
   function system.
  
  As far as I remember, several wipe utilities are using /dev/urandom to
  overwrite disks (possibly several times).
 
 Which should generate disk activity and feed entropy to urandom.

I thought you need to feed random, not urandom.

Anyway, it won't happen fast enough to actually not block.

Writing 1TB of urandom into a disk won't generate 1TB (or anything close
to that) of randomness to cover for itself.

  Something similar probably happens for getting junk on disks before
  creating an encrypted filesystem on top of them.
 
 During system install, this sysctl is not likely to be applied.

It may happen at any time you need to create a new filesystem, which
won't necessarily happen during system install. 

See for example the instructions on how to set up a LUKS filesystem:
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Preparation_and_mapping

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 16:56 -0400, Steve Grubb wrote:
 On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote:
  On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote:
   On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote:
On Wed, 2011-09-07 at 16:02 -0400, Steve Grubb wrote:
 On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote:
  On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote:
   We're looking for a generic solution here that doesn't require
   re-educating every single piece of userspace. And anything done
   in userspace is going to be full of possible holes -- there
   needs to be something in place that actually *enforces* the
   policy, and centralized accounting/tracking, lest you wind up
   with multiple processes racing to grab the entropy.
  
  Yeah, but there are userspace programs that depend on urandom not
  blocking... so your proposed change would break them.
 
 The only time this kicks in is when a system is under attack. If you
 have set this and the system is running as normal, you will never
 notice it even there. Almost all uses of urandom grab 4 bytes and
 seed openssl or libgcrypt or nss. It then uses those libraries.
 There are the odd cases where something uses urandom to generate a
 key or otherwise grab a chunk of bytes, but these are still small
 reads in the scheme of things. Can you think of any legitimate use
 of urandom that grabs 100K or 1M from urandom? Even those numbers
 still won't hit the sysctl on a normally function system.

As far as I remember, several wipe utilities are using /dev/urandom to
overwrite disks (possibly several times).
   
   Which should generate disk activity and feed entropy to urandom.
  
  I thought you need to feed random, not urandom.
 
 I think they draw from the same pool.

There is a blocking and a non blocking pool.

  
  Anyway, it won't happen fast enough to actually not block.
  
  Writing 1TB of urandom into a disk won't generate 1TB (or anything close
  to that) of randomness to cover for itself.
 
 We don't need a 1:1 mapping of RNG used to entropy acquired. Its more on the 
 scale of 
 8,000,000:1 or higher.

I'm just saying that writing 1TB into a disk using urandom will start to
block, it won't generate enough randomness by itself.

 
Something similar probably happens for getting junk on disks before
creating an encrypted filesystem on top of them.
   
   During system install, this sysctl is not likely to be applied.
  
  It may happen at any time you need to create a new filesystem, which
  won't necessarily happen during system install.
  
  See for example the instructions on how to set up a LUKS filesystem:
  https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Preparatio
  n_and_mapping
 
 Those instructions might need to be changed. That is one way of many to get 
 random 
 numbers on the disk. Anyone really needing the security to have the sysctl on 
 will 
 also probably accept that its doing its job and keeping the numbers random. 
 Again, no 
 effect unless you turn it on.

There are bunch of other places that would need to be changed in that
case :)

Why not implement it as a user mode CUSE driver that would
wrap /dev/urandom and make it behave any way you want to? why push it
into the kernel?

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] random: add blocking facility to urandom

[Sasha Levin]

On Wed, 2011-09-07 at 17:28 -0400, Steve Grubb wrote:
 On Wednesday, September 07, 2011 05:10:27 PM Sasha Levin wrote:
  Something similar probably happens for getting junk on disks before
  creating an encrypted filesystem on top of them.
 
 During system install, this sysctl is not likely to be applied.

It may happen at any time you need to create a new filesystem, which
won't necessarily happen during system install.

See for example the instructions on how to set up a LUKS filesystem:
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Prepar
atio n_and_mapping
   
   Those instructions might need to be changed. That is one way of many to
   get random numbers on the disk. Anyone really needing the security to
   have the sysctl on will also probably accept that its doing its job and
   keeping the numbers random. Again, no effect unless you turn it on.
  
  There are bunch of other places that would need to be changed in that
  case :)
  
  Why not implement it as a user mode CUSE driver that would
  wrap /dev/urandom and make it behave any way you want to? why push it
  into the kernel?
 
 For one, auditing does not work for FUSE or things like that. We have to be 
 able to 
 audit who is using what. Then there are the FIPS-140 requirements and this 
 will spread 
 it. There are problems sending crypto audit events from user space, too.

auditd doesn't work with FUSE? afaik it should, FUSE is a filesystem
like any other.

-- 

Sasha.

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html