[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5756BBC2.3735.D63200E@pageexec.freemail.hu>
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.
