Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Am Samstag, 17. Juni 2017, 05:45:57 CEST schrieb Lee Duncan: Hi Lee, > In your testing, how long might a process have to wait? Are we talking > seconds? Longer? What about timeouts? > In current kernels (starting with 4.8) this timeout should clear within a few seconds after boot. In older

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

Am Sonntag, 18. Juni 2017, 17:46:25 CEST schrieb Theodore Ts'o: Hi Theodore, > > IMHO, users using the get_random_u64 or get_random_u32 are use cases that > > do not require a fully seeded DRNG thus do not need a cryptographically > > strong random number. Hence, I would think that the logging

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Thu, Jun 15, 2017 at 01:59:43PM +0200, Stephan Müller wrote: > I would think that the issue regarding the logging is relevant for > cryptographic use cases or use cases requiring strong random numbers only. > Only those use cases should be fixed eventually to wait for a fully seeded > DRNG.

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 5:46 PM, Theodore Ts'o wrote: > You are effectively proposing that there ought to be a middle range of > security between prandom_32, get_random_u32/get_random_u64 and > get_random_bytes(). I think that's going to lead to all sorts of > complexity and bugs

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 7:55 PM, Stephan Müller wrote: > But you bring up an interesting point: if it is true you say that it is hard > for people to use differnent types of APIs regarding entropy and random > numbers right (which I would concur with), and considering that

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

On Tue, Jun 06, 2017 at 03:44:17PM +0200, Corentin Labbe wrote: > The crypto engine could actually only enqueue hash and ablkcipher request. > This patch permit it to enqueue skcipher requets by adding all necessary > functions. > The only problem is that ablkcipher and skcipher id are the same,

Re: [PATCH v2 0/6] crypto: aes - allow generic AES to be omitted

Hi Ard, On Fri, Jun 16, 2017 at 01:17:43PM +0200, Ard Biesheuvel wrote: > The generic AES driver uses 16 lookup tables of 1 KB each, and has > encryption and decryption routines that are fully unrolled. Given how > the dependencies between this code and other drivers are declared in > Kconfig

Re: [PATCH] hwrng: do not warn when there are no devices

On Fri, May 12, 2017 at 01:49:52PM +0530, PrasannaKumar Muralidharan wrote: > > I leave it to Herbert to decide whether to accept this patch in > current form or not. I think the correct fix would be for the TPM subsystem to signal that it is ready and then register the tpm-rng device. Thanks,

Re: [PATCH] hwrng: do not warn when there are no devices

On Sun, Jun 18, 2017 at 9:12 PM, Herbert Xu wrote: > On Fri, May 12, 2017 at 01:49:52PM +0530, PrasannaKumar Muralidharan wrote: > > I leave it to Herbert to decide whether to accept this patch in > > current form or not. > > I think the correct fix would be for the TPM subsystem to signal that >

Re: [PATCH v2 1/3] dt-bindings: rng: add MediaTek MT7622 Hardware Random Generator bindings

On Mon, Jun 12, 2017 at 11:56:54PM +0800, sean.w...@mediatek.com wrote: > From: Sean Wang > > Document the bindings used by MediaTek MT7622 SoC hardware random number > generator. > > Signed-off-by: Sean Wang > --- >

Re: [PATCH] of: update ePAPR references to point to Devicetree Specification

On Tue, Jun 13, 2017 at 07:49:04PM -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The Devicetree Specification has superseded the ePAPR as the > base specification for bindings. Update files in Documentation > to reference the new document. > > Some files