On Sat, Jun 09, 2007 at 08:33:25PM -0400, Benjamin Gilbert wrote:
Jeff Garzik wrote:
Matt Mackall wrote:
Have you benchmarked this against lib/sha1.c? Please post the results.
Until then, I'm frankly skeptical that your unrolled version is faster
because when I introduced lib/sha1.c
On Fri, 2009-02-13 at 07:09 +0800, Herbert Xu wrote:
On Fri, Feb 13, 2009 at 12:10:45AM +1100, Nick Piggin wrote:
I would be interested to know how that goes. You always have this
circular issue that if a little more space helps significantly, then
maybe it is a good idea to explicitly
On Sun, 2009-02-15 at 13:36 -0800, Andrew Morton wrote:
On Thu, 12 Feb 2009 17:55:04 +0200 Pekka Enberg penb...@cs.helsinki.fi
wrote:
On Thu, Feb 12, 2009 at 12:45:21PM +0200, Pekka Enberg wrote:
Because the API was being widely abused in the nommu code, for example.
I'd rather
On Sun, 2009-02-15 at 13:55 -0800, Andrew Morton wrote:
On Sun, 15 Feb 2009 15:43:14 -0600 Matt Mackall m...@selenic.com wrote:
On Sun, 2009-02-15 at 13:36 -0800, Andrew Morton wrote:
On Thu, 12 Feb 2009 17:55:04 +0200 Pekka Enberg penb...@cs.helsinki.fi
wrote:
On Thu, Feb 12
On Mon, 2009-02-16 at 09:21 +0800, Herbert Xu wrote:
On Sun, Feb 15, 2009 at 05:00:52PM -0800, Andrew Morton wrote:
But kmem_cache_size() would tell you how much extra secret memory there
is available after the object?
How that gets along with redzoning is a bit of a mystery though.
On Sun, 2009-02-15 at 17:00 -0800, Andrew Morton wrote:
On Sun, 15 Feb 2009 17:49:41 -0600 Matt Mackall m...@selenic.com wrote:
The whole concept is quite hacky and nasty, isn't it?.
It is, which is part of why we were trying to kill it. The primary users
were thing growing buffers ala realloc
On Mon, 2009-02-16 at 09:52 +0800, Herbert Xu wrote:
On Sun, Feb 15, 2009 at 07:28:46PM -0600, Matt Mackall wrote:
Yeah. That sucks. We should probably stick in an skb-friendly slab size
and see what happens on network benchmarks.
I don't see how that's going to help since we don't want
On Thu, 2009-06-04 at 15:50 -0400, Neil Horman wrote:
FIPS-140 requires that all random number generators implement continuous self
tests in which each extracted block of data is compared against the last block
for repetition. The ansi_cprng implements such a test, but it would be nice
if
don't see that this got picked up in the crypto tree. Are there
subsequent objections?
Matt, are you OK with me picking this up or do you want to pick it
up?
Acked-by: Matt Mackall m...@selenic.com
You can pick it up. Speaking of, do you care if I route other RNG bits
through your crypto
On Tue, 2010-05-18 at 15:40 -0700, David Miller wrote:
All of the CPP tests like the one used by linux/crypto.h are
ludicrious. It should absolutely be not necessary for any code to
duplicate this kind of calculation.
Instead, this sequence should be in linux/slab.h, and be used
On Wed, 2010-05-19 at 13:50 +0200, Geert Uytterhoeven wrote:
On Wed, May 19, 2010 at 13:40, David Woodhouse dw...@infradead.org wrote:
On Wed, 2010-05-19 at 13:32 +0200, Geert Uytterhoeven wrote:
Instead of having (different) defaults in sl[aou]b, perhaps we should
just remove the defaults
On Tue, 2011-06-14 at 08:39 -0400, Kent Borg wrote:
H. Peter Anvin wrote:
Those already are doing this.
They used to via IRQF_SAMPLE_RANDOM, but these are being removed
(according to Documentation/feature-removal-schedule.txt). In 2.6.39 I
can only find 10 remaining instances, out of
++
include/linux/clocksource.h |6 ++
include/linux/random.h |1 +
kernel/time/clocksource.c| 33 +++
9 files changed, 241 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/clock-entropy.c
CC: Matt Mackall m...@selenic.com
CC: Venkatesh Pallipadi
On Tue, 2011-06-14 at 11:18 -0400, Jarod Wilson wrote:
Matt Mackall wrote:
On Mon, 2011-06-13 at 18:06 -0400, Jarod Wilson wrote:
Many server systems are seriously lacking in sources of entropy,
as we typically only feed the entropy pool by way of input layer
events, a few NIC driver
On Tue, 2011-06-14 at 13:48 -0400, Kent Borg wrote:
Matt Mackall wrote:
Kent Borg wrote:
So network entropy is being eradicated, and nothing is being done to
replace it.
Nothing is being done is a more accurate summary of the situation.
So the feature-removal-schedule.txt entry
On Wed, 2011-06-15 at 10:49 -0400, Jarod Wilson wrote:
Matt Mackall wrote:
On Tue, 2011-06-14 at 18:51 -0400, Jarod Wilson wrote:
Matt Mackall wrote:
...
But that's not even the point. Entropy accounting here is about
providing a theoretical level of security above cryptographically
On Fri, 2011-06-17 at 12:48 -0700, h...@zytor.com wrote:
On 06/14/2011 04:12 PM, Matt Mackall wrote:
Various people have offered to spend some time fixing this; I haven't
had time to look at it for a while.
So on my (long...) list of things to do for a while is enablement of
RDRAND
On Tue, 2011-06-21 at 11:38 -0500, Kim Phillips wrote:
[adding linux-crypto]
On Tue, 21 Jun 2011 10:56:02 -0500
Matt Mackall m...@selenic.com wrote:
On Tue, 2011-06-21 at 08:19 -0400, Josh Boyer wrote:
+static struct hwrng ppc4xx_rng = {
+ .name = MODULE_NAME,
+ .data_present
On Tue, 2014-03-04 at 11:59 -0800, Kees Cook wrote:
On Tue, Mar 4, 2014 at 11:53 AM, Jason Cooper ja...@lakedaemon.net wrote:
On Tue, Mar 04, 2014 at 11:01:49AM -0800, Kees Cook wrote:
On Tue, Mar 4, 2014 at 7:38 AM, Jason Cooper ja...@lakedaemon.net wrote:
Kees, Ted,
On Mon, Mar 03,
On Wed, 2014-03-05 at 16:11 -0500, Jason Cooper wrote:
In other words, if there are 4096 bits of unknownness in X to start
with, and I can get those same 4096 bits of unknownness back by
unmixing X' and Y, then there must still be 4096 bits of unknownness
in X'. If X' is 4096 bits long,
20 matches
Mail list logo
