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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

crypto: gpf on boot with linux-next

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 [

Re: [PATCH] mm: kill kmemcheck

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

Re: [PATCH] mm: kill kmemcheck

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

Re: [PATCH] mm: kill kmemcheck

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

Re: [PATCH] mm: kill kmemcheck

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

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

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_

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

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 >>> >>

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

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

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

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: U

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

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 a

Re: Broken userspace crypto in linux-4.1.18

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

Re: Broken userspace crypto in linux-4.1.18

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

Re: linux/bitops.h

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

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

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 -

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

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

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

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

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

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 > @@

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

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 >

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

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

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

; 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 +

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

; 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 +

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

; 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 +

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

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 >> >

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

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