mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@linux.intel.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	DJ Johnston <dj.johnston@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jiri Kosina <jkosina@suse.cz>, "H. Peter Anvin" <hpa@zytor.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>
Subject: [PATCH v4 0/3] random: Account for entropy loss due to overwrites
Date: Mon,  9 Sep 2013 00:54:46 -0700	[thread overview]
Message-ID: <1378713289-21617-1-git-send-email-hpa@linux.intel.com> (raw)

From: "H. Peter Anvin" <hpa@linux.intel.com>

[ Resending due to fumble-fingering vger.kernel.org. Sorry about that. ]

Version 4: my attempt at rebasing this patchset on top of 3.11, with
its changes to use cmpxchg.  I believe my adaptions are correct, but I
have not had the time to test them extensively.

When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool.  This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!

This version of the patchset avoids manually duplicating information
by using a macro.  This removes *all* dynamic computation of derived
pool information and replaces them with static information: on just
about every architecture accessing pointer+offset is no more expensive
than just plain pointer, and this lets us get the information we
actually need from the start.

This version of the patchset adds handling of fractional bits, so that
we can continue to add a single bit of entropy without it being
rounded down to zero.  This version has 3 bits of fraction, which
means that with a 4096-bit input pool the multiply still cannot
overflow 32 bits; if we want to add the capability of crediting
fractional bits of entropy, which may be useful in itself, then we
probably need more bits of fraction and would have to use a 64-bit
multiply and shift.

             reply	other threads:[~2013-09-09  7:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09  7:54 H. Peter Anvin [this message]
2013-09-09  7:54 ` [PATCH v4 1/3] random: Statically compute poolbitshift, poolbytes, poolbits H. Peter Anvin
2013-09-09  7:54 ` [PATCH v4 2/3] random: Allow fractional bits to be tracked H. Peter Anvin
2013-09-09  7:54 ` [PATCH v4 3/3] random: Account for entropy loss due to overwrites 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=1378713289-21617-1-git-send-email-hpa@linux.intel.com \
    --to=hpa@linux.intel.com \
    --cc=dj.johnston@intel.com \
    --cc=hpa@zytor.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome