On Tue, Apr 26, 2016 at 01:47:09PM -0700, Andi Kleen wrote:
>
> I posted patches to fix this. At some point it definitely has to be.
Can you point me to the patch submission?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herber
On Tue, Apr 26, 2016 at 01:42:56PM +0200, Ben Hutchings wrote:
>
> It looks like the bug was introduced in 3.10 by:
>
> d733ac90f9fe8ac284e523f9920b507555b12f6d
> Author: Jussi Kivilinna
> Date: Sun Apr 7 16:43:46 2013 +0300
>
> crypto: gcm - fix rfc4543 to handle async crypto correctly
>
> And considering that I only want to have 0.9 bits of entropy, why
> should I not collapse it? The XOR operation does not destroy the existing
> entropy, it only caps it to at most one bit of information theoretical
> entropy.
No. Absolutely, demonstrably false.
The XOR operation certainly *doe
On Fri, 2016-03-18 at 22:42 +0800, Herbert Xu wrote:
> This bug has already bee fixed upstream since 4.2. However, it
> was fixed during the AEAD conversion so no fix was backported to
> the older kernels.
>
> When we do an RFC 4543 decryption, we will end up writing the
> ICV beyond the end of t
Am Dienstag, 26. April 2016, 16:43:30 schrieb George Spelvin:
Hi George,
(I am not covering the initial part as I leave you time to read through the
paper which should cover those aspects)
>
> That's what I don't like about Intel's RDRAND and similar hardware RNGs:
> they are whitening too ear
On Tue, Apr 26, 2016 at 07:04:15PM +0800, Herbert Xu wrote:
> Theodore Ts'o wrote:
> >
> > Yet another difference which I've noticed as I've been going over the
> > patches is that that since it relies on CRYPTO_DRBG, it drags in a
> > fairly large portion of the crypto subsystem, and requires it
Schrieb Stephan Mueller:
> Am Montag, 25. April 2016, 21:59:43 schrieb George Spelvin:
>> Indeed, this is an incredibly popular novice mistake and I don't
>> understand why people keep making it.
> Can you please elaborate on your statement to help me understanding the issue
> and substantiate yo
Hi!
> > > > When dropping the add_disk_randomness function in the legacy
> > > > /dev/random, I
> > > > would assume that without changes to add_input_randomness and
> > > > add_interrupt_randomness, we become even more entropy-starved.
> > >
> > > Sure, but your system isn't doing anything magic
Am Dienstag, 26. April 2016, 20:44:39 schrieb Pavel Machek:
Hi Pavel,
> Hi1
>
> > > When dropping the add_disk_randomness function in the legacy
> > > /dev/random, I
> > > would assume that without changes to add_input_randomness and
> > > add_interrupt_randomness, we become even more entropy-st
Hi1
> > When dropping the add_disk_randomness function in the legacy /dev/random, I
> > would assume that without changes to add_input_randomness and
> > add_interrupt_randomness, we become even more entropy-starved.
>
> Sure, but your system isn't doing anything magical here. The main
> diffe
Am Montag, 25. April 2016, 21:59:43 schrieb George Spelvin:
Hi George,
>
> > not the rest of Stephan's input handling code: the parity
> > calculation and XORing the resulting single bit into the entropy pool.
>
> Indeed, this is an incredibly popular novice mistake and I don't
> understand why
Am Montag, 25. April 2016, 23:07:35 schrieb Theodore Ts'o:
Hi Theodore,
>
> > When dropping the add_disk_randomness function in the legacy /dev/random,
> > I
> > would assume that without changes to add_input_randomness and
> > add_interrupt_randomness, we become even more entropy-starved.
>
> S
On Mon, Apr 25, 2016 at 12:06 PM, Andi Kleen wrote:
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
I did not write that. I think Andi is quoting himself here, not me.
> https:/
Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen:
Hi Andi,
> > > > If it is the latter, can you explain where the scalability issue comes
> > > > in?
> > >
> > > A single pool which is locked/written to does not scale. Larger systems
> > > need multiple pools
> >
> > That would imply that
On Sat, 2016-03-19 at 10:23 +0800, Herbert Xu wrote:
> On Fri, Mar 18, 2016 at 10:34:23AM -0700, Greg KH wrote:
> >
> > On Fri, Mar 18, 2016 at 10:42:40PM +0800, Herbert Xu wrote:
> > >
> > > This bug has already bee fixed upstream since 4.2. However, it
> > > was fixed during the AEAD conversio
Theodore Ts'o wrote:
>
> Yet another difference which I've noticed as I've been going over the
> patches is that that since it relies on CRYPTO_DRBG, it drags in a
> fairly large portion of the crypto subsystem, and requires it to be
> compiled into the kernel (instead of being loaded as needed as
Hi Marek,
On 26.04.2016 10:29, Marek Szyprowski wrote:
> sg_dma_len() macro can be used only on scattelists which are mapped, so
> all calls to it before dma_map_sg() are invalid. Replace them by proper
> check for direct sg segment length read.
>
> Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5P
On 04/26/2016 09:29 AM, Marek Szyprowski wrote:
> sg_dma_len() macro can be used only on scattelists which are mapped, so
> all calls to it before dma_map_sg() are invalid. Replace them by proper
> check for direct sg segment length read.
>
> Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 adv
sg_dma_len() macro can be used only on scattelists which are mapped, so
all calls to it before dma_map_sg() are invalid. Replace them by proper
check for direct sg segment length read.
Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 advanced crypto engine
support")
Fixes: 9e4a1100a445 ("crypt
19 matches
Mail list logo
