linux-kernel - Re: [kernel-hardening] Re: [PATCH v2 1/3] Add the latent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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: [kernel-hardening] 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