Il 02/02/2014 21:36, Jörn Engel ha scritto:
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wuninitialized"
+ input[0] ^= cycles ^ jiffies;
+ input[1] ^= (unsigned long)caller;
+ input[2] ^= (unsigned long)val;
+ input[3] ^= (unsigned long)&input;
+#pragma G
On Thu, 6 February 2014 14:20:02 -0800, Kees Cook wrote:
> On Sun, Feb 02, 2014 at 03:36:17PM -0500, Jörn Engel wrote:
> > Collects entropy from random behaviour all modern cpus exhibit. The
> > scheduler and slab allocator are instrumented for this purpose. How
> > much randomness can be gathere
On Thu, Feb 6, 2014 at 5:20 PM, Kees Cook wrote:
> Hi Jörn,
>
> On Sun, Feb 02, 2014 at 03:36:17PM -0500, Jörn Engel wrote:
>> Collects entropy from random behaviour all modern cpus exhibit. The
>> scheduler and slab allocator are instrumented for this purpose. How
>> much randomness can be gath
Hi Jörn,
On Sun, Feb 02, 2014 at 03:36:17PM -0500, Jörn Engel wrote:
> Collects entropy from random behaviour all modern cpus exhibit. The
> scheduler and slab allocator are instrumented for this purpose. How
> much randomness can be gathered is clearly hardware-dependent and hard
> to estimate.
On Mon, Feb 03, 2014 at 09:54:22PM +, Maciej W. Rozycki wrote:
>
> Can we be sure we don't leak information this way? Just being
> paranoid...
The register information will be mixed pretty thoroughly by the time
it gets to the entropy pool, and then we don't ever expose the entropy
pool to
On Mon, 3 Feb 2014, Theodore Ts'o wrote:
> > How about taking the saved registers from the interrupted CPU, xor'ing
> > them all and calling the result random_get_entropy() on systems
> > lacking a good cycles-counter?
>
> So we could take the struct pt_regs which we get from get_irq_regs(),
> XO
On Mon, 3 February 2014 11:37:29 -0500, Theodore Ts'o wrote:
>
> So we could take the struct pt_regs which we get from get_irq_regs(),
> XOR them together and use them to feed into input[2] amd input[3] in
> add_interrupt_randomness(). Or some other way of distributing the
> values of all of the
On Mon, Feb 03, 2014 at 10:50:42AM -0500, Jörn Engel wrote:
> If the measurement event is an interrupt and the CPU has a
> cycle-counter, you are set. On interesting systems lacking a
> cycle-counter, we still have a high-resolution counter or sorts that
> is the CPU itself.
>
> Instruction point
On Sun, 2 February 2014 15:36:17 -0500, Jörn Engel wrote:
>
> Measuring the randomness from random_get_entropy() with above approach
> failed because there was so much randomness. All numbers in all runs
> were different. Taking the delta between the numbers, again almost all
> numbers were diff
Am Sonntag, 2. Februar 2014, 20:24:21 schrieb Jörn Engel:
Hi Jörn,
>On Sun, 2 February 2014 22:25:31 +0100, Stephan Mueller wrote:
>> Am Sonntag, 2. Februar 2014, 15:36:17 schrieb Jörn Engel:
>> > Collects entropy from random behaviour all modern cpus exhibit.
>> > The
>> > scheduler and slab al
Theodore Ts'o dixit:
>I really like Jvrn's tests doing repeated boot testing and observing
>on a SMP system, the slab allocation pattern is quite deterministic.
>So even though the numbers might *look* random, an attacker with deep
>knowledge of how the kernel was compiled and what memory allocati
Am Sonntag, 2. Februar 2014, 20:39:22 schrieb Theodore Ts'o:
Hi Theodore,
>On Sun, Feb 02, 2014 at 10:25:31PM +0100, Stephan Mueller wrote:
>> Second, when I offered my initial patch which independently collects
>> some entropy on the CPU execution timing, I got shot down with one
>> concern rais
On Sun, 2 February 2014 20:39:22 -0500, Theodore Ts'o wrote:
>
> The real question is how much overhead does it add, and is it worth
> it. Jörn, I take it that was the reason for creating an even faster,
> but weaker mixing function? Was the existing "fast mix" causing a
> measurable overhead, o
On Sun, Feb 02, 2014 at 10:25:31PM +0100, Stephan Mueller wrote:
> Second, when I offered my initial patch which independently collects some
> entropy on the CPU execution timing, I got shot down with one concern raised
> by Ted, and that was about whether a user can influence the entropy
> coll
On 02/02/2014 05:24 PM, Jörn Engel wrote:
>
> For my part, I think the whole business of estimating entropy is
> bordering on the esoteric. If the hash on the output side is any
> good, you have a completely unpredictable prng once the entropy pool
> is unpredictable. Additional random bits are
On Sun, 2 February 2014 22:25:31 +0100, Stephan Mueller wrote:
> Am Sonntag, 2. Februar 2014, 15:36:17 schrieb Jörn Engel:
>
> > Collects entropy from random behaviour all modern cpus exhibit. The
> > scheduler and slab allocator are instrumented for this purpose. How
> > much randomness can be
Am Sonntag, 2. Februar 2014, 15:36:17 schrieb Jörn Engel:
Hi Jörn,
> Collects entropy from random behaviour all modern cpus exhibit. The
> scheduler and slab allocator are instrumented for this purpose. How
> much randomness can be gathered is clearly hardware-dependent and hard
> to estimate.
Collects entropy from random behaviour all modern cpus exhibit. The
scheduler and slab allocator are instrumented for this purpose. How
much randomness can be gathered is clearly hardware-dependent and hard
to estimate. Therefore the entropy estimate is zero, but random bits
still get mixed into
18 matches
Mail list logo