On Mon, Apr 07, 2014 at 09:30:57PM +0200, Sebastian Andrzej Siewior wrote:
> Yes. Usually there is generic function doing something sane but not as
> good as it could do with arch specific code. Or the code is completly
> disabled unless the architecture wires it up. Dropping a new function and
>
On Mon, Apr 07, 2014 at 09:30:57PM +0200, Sebastian Andrzej Siewior wrote:
Yes. Usually there is generic function doing something sane but not as
good as it could do with arch specific code. Or the code is completly
disabled unless the architecture wires it up. Dropping a new function and
On Mon, Apr 07, 2014 at 09:30:57PM +0200, Sebastian Andrzej Siewior wrote:
>
> You dropped that part where I suggested to use something like AES+CTR
> and create the numbers on demand and dropping that attempt to create as
> much random data with custom functions as possible. You completly
On 2014-04-07 00:01:37 [-0400], Theodore Ts'o wrote:
> Yes, ARM sucks for not implement random_get_entropy() on all
> platforms. Film at 11. I'm told that Cortex ARM systms are supposed
> to have a cycle counter. I'm not sure why it hasn't been wired up,
> but it really should be.
I see.
>
On 2014-04-07 00:01:37 [-0400], Theodore Ts'o wrote:
Yes, ARM sucks for not implement random_get_entropy() on all
platforms. Film at 11. I'm told that Cortex ARM systms are supposed
to have a cycle counter. I'm not sure why it hasn't been wired up,
but it really should be.
I see.
On Mon, Apr 07, 2014 at 09:30:57PM +0200, Sebastian Andrzej Siewior wrote:
You dropped that part where I suggested to use something like AES+CTR
and create the numbers on demand and dropping that attempt to create as
much random data with custom functions as possible. You completly dislike
On Fri, Apr 04, 2014 at 06:54:47PM +0200, Sebastian Andrzej Siewior wrote:
> And finally cycles which is random_get_entropy(). On ARM (as previously on
> MIPS) this returns 0. Well not always but for all platforms which do not
> implement register_current_timer_delay() which makes a lot of them.
On Fri, Apr 04, 2014 at 06:54:47PM +0200, Sebastian Andrzej Siewior wrote:
And finally cycles which is random_get_entropy(). On ARM (as previously on
MIPS) this returns 0. Well not always but for all platforms which do not
implement register_current_timer_delay() which makes a lot of them.
On 2013-10-01 08:44:24 [-0400], Theodore Ts'o wrote:
> The changes queued for the next merge window in the random tree solve
> this problem slightly differently:
>
> ...
> input[0] = cycles ^ j_high ^ irq;
> input[1] = now ^ c_high;
> ip = regs ? instruction_pointer(regs)
On 2013-10-01 08:44:24 [-0400], Theodore Ts'o wrote:
The changes queued for the next merge window in the random tree solve
this problem slightly differently:
...
input[0] = cycles ^ j_high ^ irq;
input[1] = now ^ c_high;
ip = regs ? instruction_pointer(regs) :
On Mon, Sep 30, 2013 at 08:51:43PM +, Luck, Tony wrote:
> > In this case fast_mix would use two uninitialized ints from the stack
> > and mix it into the pool.
>
> Is the concern here is that an attacker might know (or be able to control)
> what is on
> the stack - and so get knowledge of
On Mon, Sep 30, 2013 at 08:51:43PM +, Luck, Tony wrote:
In this case fast_mix would use two uninitialized ints from the stack
and mix it into the pool.
Is the concern here is that an attacker might know (or be able to control)
what is on
the stack - and so get knowledge of what is
> In this case fast_mix would use two uninitialized ints from the stack
> and mix it into the pool.
Is the concern here is that an attacker might know (or be able to control) what
is on
the stack - and so get knowledge of what is being mixed into the pool?
> In this case set the input to 0.
From: Andi Kleen
In some cases, e.g. after this
arch/ia64/kernel/irq.c:185: struct pt_regs *old_regs =
set_irq_regs(NULL);
arch/ia64/kernel/irq_ia64.c:560:struct pt_regs
*old_regs = set_irq_regs(NULL);
the regs passed to add_interrupt_randomness()
From: Andi Kleen a...@linux.intel.com
In some cases, e.g. after this
arch/ia64/kernel/irq.c:185: struct pt_regs *old_regs =
set_irq_regs(NULL);
arch/ia64/kernel/irq_ia64.c:560:struct pt_regs
*old_regs = set_irq_regs(NULL);
the regs passed to
In this case fast_mix would use two uninitialized ints from the stack
and mix it into the pool.
Is the concern here is that an attacker might know (or be able to control) what
is on
the stack - and so get knowledge of what is being mixed into the pool?
In this case set the input to 0.
And
16 matches
Mail list logo
