[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140203163729.GA13634@thunk.org>
Date: Mon, 3 Feb 2014 11:37:29 -0500
From: Theodore Ts'o <tytso@....edu>
To: Jörn Engel <joern@...fs.org>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
macro@...ux-mips.org, ralf@...ux-mips.org, dave.taht@...il.com,
blogic@...nwrt.org, andrewmcgr@...il.com, smueller@...onox.de,
geert@...ux-m68k.org, tg@...bsd.de
Subject: Re: [PATCH,RFC] random: collect cpu randomness
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists