All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: PaX Team <pageexec@freemail.hu>
Cc: kernel-hardening@lists.openwall.com,
	David Brown <david.brown@linaro.org>,
	emese Revfy <re.emese@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	spender@grsecurity.net, mmarek@suse.com, keescook@chromium.org,
	linux-kernel@vger.kernel.org, yamada.masahiro@socionext.com,
	linux-kbuild@vger.kernel.org, linux-mm@kvack.org,
	axboe@kernel.dk, viro@zeniv.linux.org.uk,
	paulmck@linux.vnet.ibm.com, mingo@redhat.com, tglx@linutronix.de,
	bart.vanassche@sandisk.com, davem@davemloft.net
Subject: Re: [kernel-hardening] Re: [PATCH v2 1/3] Add the latent_entropy gcc plugin
Date: Mon, 6 Jun 2016 19:13:19 -0400	[thread overview]
Message-ID: <20160606231319.GC7057@thunk.org> (raw)
In-Reply-To: <5755CF44.24670.9C7568D@pageexec.freemail.hu>

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, 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.

Since we're not claiming any additional entropy, I suppose it won't
hurt to do it twice, two different ways, but I'm not sure how much it
will actually help, and by doing the instrumentation in every single
basic block, instead of in the interrupt handler, I would think it
would be cheaper to do it in the interrupt handler.

      	 	       	     - Ted

WARNING: multiple messages have this Message-ID (diff)
From: Theodore Ts'o <tytso@mit.edu>
To: PaX Team <pageexec@freemail.hu>
Cc: kernel-hardening@lists.openwall.com,
	David Brown <david.brown@linaro.org>,
	emese Revfy <re.emese@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	spender@grsecurity.net, mmarek@suse.com, keescook@chromium.org,
	linux-kernel@vger.kernel.org, yamada.masahiro@socionext.com,
	linux-kbuild@vger.kernel.org, linux-mm@kvack.org,
	axboe@kernel.dk, viro@zeniv.linux.org.uk,
	paulmck@linux.vnet.ibm.com, mingo@redhat.com, tglx@linutronix.de,
	bart.vanassche@sandisk.com, davem@davemloft.net
Subject: Re: [kernel-hardening] Re: [PATCH v2 1/3] Add the latent_entropy gcc plugin
Date: Mon, 6 Jun 2016 19:13:19 -0400	[thread overview]
Message-ID: <20160606231319.GC7057@thunk.org> (raw)
In-Reply-To: <5755CF44.24670.9C7568D@pageexec.freemail.hu>

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, 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.

Since we're not claiming any additional entropy, I suppose it won't
hurt to do it twice, two different ways, but I'm not sure how much it
will actually help, and by doing the instrumentation in every single
basic block, instead of in the interrupt handler, I would think it
would be cheaper to do it in the interrupt handler.

      	 	       	     - Ted

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-06-06 23:13 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-30 23:30 [PATCH v2 0/3] Introduce the latent_entropy gcc plugin Emese Revfy
2016-05-30 23:30 ` [kernel-hardening] " Emese Revfy
2016-05-30 23:30 ` Emese Revfy
2016-05-30 23:31 ` [PATCH v2 1/3] Add " Emese Revfy
2016-05-30 23:31   ` [kernel-hardening] " Emese Revfy
2016-05-30 23:31   ` Emese Revfy
2016-06-01 19:42   ` Andrew Morton
2016-06-01 19:42     ` [kernel-hardening] " Andrew Morton
2016-06-01 19:42     ` Andrew Morton
2016-06-03 17:42     ` Emese Revfy
2016-06-03 17:42       ` [kernel-hardening] " Emese Revfy
2016-06-03 17:42       ` Emese Revfy
2016-06-06 13:38       ` [kernel-hardening] " David Brown
2016-06-06 13:38         ` David Brown
2016-06-06 15:50         ` Kees Cook
2016-06-06 15:50           ` Kees Cook
2016-06-06 15:50           ` Kees Cook
2016-06-06 19:30         ` PaX Team
2016-06-06 19:30           ` PaX Team
2016-06-06 23:13           ` Theodore Ts'o [this message]
2016-06-06 23:13             ` Theodore Ts'o
2016-06-07 12:19             ` PaX Team
2016-06-07 12:19               ` PaX Team
2016-06-07 13:58               ` Theodore Ts'o
2016-06-07 13:58                 ` Theodore Ts'o
2016-06-09 17:22                 ` PaX Team
2016-06-09 17:22                   ` PaX Team
2016-06-09 19:55                   ` Theodore Ts'o
2016-06-09 19:55                     ` Theodore Ts'o
2016-06-09 20:08                     ` Kees Cook
2016-06-09 20:08                       ` Kees Cook
2016-06-09 20:08                       ` Kees Cook
2016-06-09 21:51   ` Kees Cook
2016-06-09 21:51     ` [kernel-hardening] " Kees Cook
2016-06-09 21:51     ` Kees Cook
2016-06-09 21:51     ` Kees Cook
2016-06-13 21:49     ` Emese Revfy
2016-06-13 21:49       ` [kernel-hardening] " Emese Revfy
2016-06-13 21:49       ` Emese Revfy
2016-06-13 21:49       ` Emese Revfy
2016-06-14 18:27       ` Kees Cook
2016-06-14 18:27         ` [kernel-hardening] " Kees Cook
2016-06-14 18:27         ` Kees Cook
2016-06-14 18:27         ` Kees Cook
2016-06-14 22:31         ` Emese Revfy
2016-06-14 22:31           ` [kernel-hardening] " Emese Revfy
2016-06-14 22:31           ` Emese Revfy
2016-06-14 22:31           ` Emese Revfy
2016-05-30 23:32 ` [PATCH v2 2/3] Mark functions with the latent_entropy attribute Emese Revfy
2016-05-30 23:32   ` [kernel-hardening] " Emese Revfy
2016-05-30 23:32   ` Emese Revfy
2016-05-30 23:34 ` [PATCH v2 3/3] Add the extra_latent_entropy kernel parameter Emese Revfy
2016-05-30 23:34   ` [kernel-hardening] " Emese Revfy
2016-05-30 23:34   ` Emese Revfy
2016-06-09 21:18 ` [PATCH v2 0/3] Introduce the latent_entropy gcc plugin Kees Cook
2016-06-09 21:18   ` [kernel-hardening] " Kees Cook
2016-06-09 21:18   ` Kees Cook
2016-06-09 21:18   ` Kees Cook
2016-06-09 23:33   ` Emese Revfy
2016-06-09 23:33     ` [kernel-hardening] " Emese Revfy
2016-06-09 23:33     ` Emese Revfy
2016-06-09 23:33     ` Emese Revfy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160606231319.GC7057@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bart.vanassche@sandisk.com \
    --cc=davem@davemloft.net \
    --cc=david.brown@linaro.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=mmarek@suse.com \
    --cc=pageexec@freemail.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=re.emese@gmail.com \
    --cc=spender@grsecurity.net \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.