Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Jun 2016 14:19:14 +0200
From: "PaX Team" <pageexec@...email.hu>
To: "Theodore Ts'o" <tytso@....edu>
CC: kernel-hardening@...ts.openwall.com, David Brown <david.brown@...aro.org>,
        emese Revfy <re.emese@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>, spender@...ecurity.net,
        mmarek@...e.com, keescook@...omium.org, linux-kernel@...r.kernel.org,
        yamada.masahiro@...ionext.com, linux-kbuild@...r.kernel.org,
        linux-mm@...ck.org, axboe@...nel.dk, viro@...iv.linux.org.uk,
        paulmck@...ux.vnet.ibm.com, mingo@...hat.com, tglx@...utronix.de,
        bart.vanassche@...disk.com, davem@...emloft.net
Subject: Re: Re: [PATCH v2 1/3] Add the latent_entropy gcc plugin

On 6 Jun 2016 at 19:13, Theodore Ts'o wrote:

> On Mon, Jun 06, 2016 at 09:30:12PM +0200, PaX Team wrote:
> > 
> > what matters for latent entropy is not the actual values fed into the entropy
> > pool (they're effectively compile time constants save for runtime data dependent
> > computations) but the precise sequence of them. interrupts stir this sequence
> > and thus extract entropy. perhaps as a small example imagine that an uninterrupted
> > kernel boot sequence feeds these values into the entropy pool:
> >   A B C
> > 
> > now imagine that a single interrupt can occur around any one of these values:
> >   I A B C
> >   A I B C
> >   A B I C
> >   A B C I
> > 
> > this way we can obtain 4 different final pool states that translate into up
> > to 2 bits of latent entropy (depends on how probable each sequence is). note
> > that this works regardless whether the underlying hardware has a high resolution
> > timer whose values the interrupt handler would feed into the pool.
> 
> Right, but if it's only about interrupts,

(i believe that) latent entropy is found in more than just interrupt timing, there're
also data dependent computations that can have entropy, either on a single system or
across a population of them.

> we're doing this already inside modern Linux kernels.  On every single
> interrupt we are mixing into a per-CPU "fast mix" pool the IP from the
> interrupt registers. 

i agree that sampling the kernel register state can have entropy (the plugin
already extracts the current stack pointer) but i'm much less sure about
userland (at least i see no dependence on !user_mode(...)) since an attacker
could feed no entropy into the pool but still get it credited.

cheers,
 PaX Team

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.