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
next prev parent 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.