All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Jörn Engel" <joern@logfs.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	macro@linux-mips.org, ralf@linux-mips.org, dave.taht@gmail.com,
	blogic@openwrt.org, andrewmcgr@gmail.com, smueller@chronox.de,
	geert@linux-m68k.org, tg@mirbsd.de
Subject: Re: [PATCH,RFC] random: collect cpu randomness
Date: Mon, 3 Feb 2014 11:37:29 -0500	[thread overview]
Message-ID: <20140203163729.GA13634@thunk.org> (raw)
In-Reply-To: <20140203155042.GD9499@logfs.org>

On Mon, Feb 03, 2014 at 10:50:42AM -0500, Jörn Engel wrote:
> If the measurement event is an interrupt and the CPU has a
> cycle-counter, you are set.  On interesting systems lacking a
> cycle-counter, we still have a high-resolution counter or sorts that
> is the CPU itself.
> 
> Instruction pointer and stack pointer for both kernel and userland are
> one way to read out the "counter".  Main problem here are tight loops
> where your "counter" is not high-resolution at all.  But something
> within the CPU is constantly changing.  And that something tends to be
> contained in the registers.
> 
> How about taking the saved registers from the interrupted CPU, xor'ing
> them all and calling the result random_get_entropy() on systems
> lacking a good cycles-counter?

So we could take the struct pt_regs which we get from get_irq_regs(),
XOR them together and use them to feed into input[2] amd input[3] in
add_interrupt_randomness().  Or some other way of distributing the
values of all of the irq registers into the __u32 input[4] array.

That would probably be a good and useful thing to do.  Was that
basically what you were suggesting?

						- Ted

  reply	other threads:[~2014-02-03 16:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-02 20:36 [PATCH,RFC] random: collect cpu randomness Jörn Engel
2014-02-02 21:25 ` Stephan Mueller
2014-02-03  1:24   ` Jörn Engel
2014-02-03  1:28     ` H. Peter Anvin
2014-02-03 13:36     ` Stephan Mueller
2014-02-03  1:39   ` Theodore Ts'o
2014-02-03  3:35     ` Jörn Engel
2014-02-03 12:54     ` Thorsten Glaser
2014-02-03 13:06     ` Stephan Mueller
2014-02-03 15:50 ` Jörn Engel
2014-02-03 16:37   ` Theodore Ts'o [this message]
2014-02-03 18:48     ` Jörn Engel
2014-03-23 18:00       ` [PATCH] random: mix all saved registers into entropy pool Jörn Engel
2014-02-03 21:54     ` [PATCH,RFC] random: collect cpu randomness Maciej W. Rozycki
2014-02-03 22:44       ` Theodore Ts'o
2014-02-06 22:20 ` Kees Cook
2014-02-06 22:21   ` Dave Taht
2014-02-07  7:44   ` Jörn Engel
2014-02-20  9:50 ` Paolo Bonzini

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=20140203163729.GA13634@thunk.org \
    --to=tytso@mit.edu \
    --cc=andrewmcgr@gmail.com \
    --cc=blogic@openwrt.org \
    --cc=dave.taht@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=hpa@zytor.com \
    --cc=joern@logfs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=smueller@chronox.de \
    --cc=tg@mirbsd.de \
    /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.