From: "Theodore Ts'o" <tytso@mit.edu>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
greg@kroah.com, w@1wt.eu, ewust@umich.edu, zakir@umich.edu,
mpm@selenic.com, nadiah@cs.ucsd.edu, jhalderm@umich.edu,
tglx@linutronix.de, davem@davemloft.net, mingo@kernel.org,
DJ Johnston <dj.johnston@intel.com>,
stable@vger.kernel.org
Subject: Re: [PATCH RFC] random: Account for entropy loss due to overwrites
Date: Tue, 16 Oct 2012 11:53:07 -0400 [thread overview]
Message-ID: <20121016155307.GF17446@thunk.org> (raw)
In-Reply-To: <507CE663.2060502@linux.intel.com>
On Mon, Oct 15, 2012 at 09:45:23PM -0700, H. Peter Anvin wrote:
>
> Or we could compute poolwords (and poolbits, and poolbytes) from it,
> since shifts generally are cheap. I don't strongly care, whatever your
> preference is.
We are already calculating poolbits from poolwords:
#define POOLBITS poolwords*32
#define POOLBYTES poolwords*4
So you'd basically be suggesting that we define
#define POOLWORDS (1 << (poolshift - 5))
#define POOLBYTES (1 << (poolshift - 3))
#define POOLBITS (1 << poolshift)
Yeah, that works; we don't use poolwords in that many places, and a
data dependent shift is cheap at least on x86 and arm (so probably all
modern platforms).
There was one aesthetic reason for using POOLWORDS, which was that
first term of the generating polynomial was the same as poolwords,
i.e:
/* x^128 + x^103 + x^76 + x^51 +x^25 + x + 1 -- 105 */
{ 128, 103, 76, 51, 25, 1 },
/* x^32 + x^26 + x^20 + x^14 + x^7 + x + 1 -- 15 */
{ 32, 26, 20, 14, 7, 1 },
If we change it to be:
/* x^128 + x^103 + x^76 + x^51 +x^25 + x + 1 -- 105 */
{ 12, 103, 76, 51, 25, 1 },
/* x^32 + x^26 + x^20 + x^14 + x^7 + x + 1 -- 15 */
{ 10, 26, 20, 14, 7, 1 },
It's a wee bit less obvious where the "12" and "10" is coming form. I
don't see an easy way to fix this, though, other than perhaps making
sure it's clear in the comments. Unfortunately we can't count on gcc
doing a built-in optimization for a log2 of a constant as far as I
know.... or can we?
Hmm, this does get optimized correctly at least with gcc 4.7:
#define shiftbits(words) ((int) __builtin_log2((double) (words)) + 5)
... and it looks like include/linux/log2.h already has a definition
for ilog2() which should definitely work for all versions of gcc, so
we could do this instead:
#define shiftbits(w) (ilog2((w)) + 5)
/* x^128 + x^103 + x^76 + x^51 +x^25 + x + 1 -- 105 */
{ shiftbits(128), 103, 76, 51, 25, 1 },
/* x^32 + x^26 + x^20 + x^14 + x^7 + x + 1 -- 15 */
{ shiftbits(32), 26, 20, 14, 7, 1 },
- Ted
next prev parent reply other threads:[~2012-10-16 15:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 17:26 [PATCH RFC] random: Account for entropy loss due to overwrites H. Peter Anvin
2012-08-15 19:30 ` Matt Mackall
2012-08-15 20:37 ` H. Peter Anvin
2012-09-29 19:47 ` H. Peter Anvin
2012-10-16 4:08 ` Theodore Ts'o
2012-10-16 4:45 ` H. Peter Anvin
2012-10-16 15:53 ` Theodore Ts'o [this message]
2012-10-16 16:10 ` H. Peter Anvin
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=20121016155307.GF17446@thunk.org \
--to=tytso@mit.edu \
--cc=davem@davemloft.net \
--cc=dj.johnston@intel.com \
--cc=ewust@umich.edu \
--cc=greg@kroah.com \
--cc=hpa@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jhalderm@umich.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpm@selenic.com \
--cc=nadiah@cs.ucsd.edu \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=w@1wt.eu \
--cc=zakir@umich.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.