From: Stephan Mueller <smueller@chronox.de>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
hpa@zytor.com, joern@logfs.org, macro@linux-mips.org,
ralf@linux-mips.org, dave.taht@gmail.com, blogic@openwrt.org,
andrewmcgr@gmail.com, geert@linux-m68k.org, tg@mirbsd.de
Subject: Re: [PATCH, RFC 07/12] random: allow architectures to optionally define random_get_entropy()
Date: Mon, 23 Sep 2013 12:38:26 +0200 [thread overview]
Message-ID: <1436634.TJZIP2QOy7@tauon> (raw)
In-Reply-To: <1379882338-7209-8-git-send-email-tytso@mit.edu>
Am Sonntag, 22. September 2013, 16:38:53 schrieb Theodore Ts'o:
Hi Theodore,
>Allow architectures which have a disabled get_cycles() function to
>provide a random_get_entropy() function which provides a fine-grained,
>rapidly changing counter that can be used by the /dev/random driver.
Are there any plans to get such function implemented on large list of
architectures without a get_cycles function?
Thanks
>
>For example, an architecture might have a rapidly changing register
>used to control random TLB cache eviction, or DRAM refresh that
>doesn't meet the requirements of get_cycles(), but which is good
>enough for the needs of the random driver.
>
>Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
>---
> drivers/char/random.c | 8 ++++----
> include/linux/timex.h | 17 +++++++++++++++++
> 2 files changed, 21 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/char/random.c b/drivers/char/random.c
>index 9564144..ba23d5c 100644
>--- a/drivers/char/random.c
>+++ b/drivers/char/random.c
>@@ -707,7 +707,7 @@ struct timer_rand_state {
> */
> void add_device_randomness(const void *buf, unsigned int size)
> {
>- unsigned long time = get_cycles() ^ jiffies;
>+ unsigned long time = random_get_entropy() ^ jiffies;
> unsigned long flags;
>
> trace_add_device_randomness(size, _RET_IP_);
>@@ -751,7 +751,7 @@ static void add_timer_randomness(struct
>timer_rand_state *state, unsigned num) goto out;
>
> sample.jiffies = jiffies;
>- sample.cycles = get_cycles();
>+ sample.cycles = random_get_entropy();
> sample.num = num;
> mix_pool_bytes(&input_pool, &sample, sizeof(sample), NULL);
>
>@@ -818,7 +818,7 @@ void add_interrupt_randomness(int irq, int
>irq_flags) struct fast_pool *fast_pool =
>&__get_cpu_var(irq_randomness); struct pt_regs *regs =
>get_irq_regs();
> unsigned long now = jiffies;
>- __u32 input[4], cycles = get_cycles();
>+ __u32 input[4], cycles = random_get_entropy();
>
> input[0] = cycles ^ jiffies;
> input[1] = irq;
>@@ -1580,7 +1580,7 @@ unsigned int get_random_int(void)
>
> hash = get_cpu_var(get_random_int_hash);
>
>- hash[0] += current->pid + jiffies + get_cycles();
>+ hash[0] += current->pid + jiffies + random_get_entropy();
> md5_transform(hash, random_int_secret);
> ret = hash[0];
> put_cpu_var(get_random_int_hash);
>diff --git a/include/linux/timex.h b/include/linux/timex.h
>index b3726e6..f9780cc 100644
>--- a/include/linux/timex.h
>+++ b/include/linux/timex.h
>@@ -64,6 +64,23 @@
>
> #include <asm/timex.h>
>
>+#ifndef random_get_entropy
>+/*
>+ * The random_get_entropy() function is used by the /dev/random driver
>+ * in order to extract entropy via the relative unpredictability of +
>* when an interrupt takes places versus a high speed, fine-grained + *
>timing source or cycle counter. Since it will be occurred on every +
>* single interrupt, it must have a very low cost/overhead.
>+ *
>+ * By default we use get_cycles() for this purpose, but individual
>+ * architectures may override this in their asm/timex.h header file.
>+ */
>+static inline cycles_t random_get_entropy(void)
>+{
>+ return get_cycles();
>+}
>+#endif
>+
> /*
> * SHIFT_PLL is used as a dampening factor to define how much we
> * adjust the frequency correction for a given offset in PLL mode.
Ciao
Stephan
next prev parent reply other threads:[~2013-09-23 10:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-22 20:38 [PATCH, RFC 00/12] random driver changes Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 01/12] random: run random_int_secret_init() run after all late_initcalls Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 02/12] random: Statically compute poolbitshift, poolbytes, poolbits Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 03/12] random: Allow fractional bits to be tracked Theodore Ts'o
2013-09-23 4:01 ` Theodore Ts'o
2013-09-23 4:03 ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 04/12] random: Account for entropy loss due to overwrites Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 05/12] random: fix the tracepoint for get_random_bytes(_arch) Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 06/12] random: optimize spinlock use in add_device_randomness() Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 07/12] random: allow architectures to optionally define random_get_entropy() Theodore Ts'o
2013-09-23 10:38 ` Stephan Mueller [this message]
2013-09-23 11:05 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf() Theodore Ts'o
2013-09-23 4:11 ` H. Peter Anvin
2013-09-23 4:33 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 09/12] random: optimize the entropy_store structure Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded Theodore Ts'o
2013-09-22 21:21 ` H. Peter Anvin
2013-09-22 21:40 ` Theodore Ts'o
2013-09-22 22:45 ` H. Peter Anvin
2013-09-22 23:23 ` Theodore Ts'o
2013-09-23 0:26 ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 11/12] random: speed up the fast_mix function by a factor of four Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 12/12] random: adjust the generator polynomials in the mixing function slightly Theodore Ts'o
2013-09-25 10:51 ` Jörg-Volker Peetz
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=1436634.TJZIP2QOy7@tauon \
--to=smueller@chronox.de \
--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=tg@mirbsd.de \
--cc=tytso@mit.edu \
/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.