Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1392220
| From | Theodore Ts'o <tytso@mit.edu> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs |
| Date | 2016-05-02 15:50 +0200 |
| Message-ID | <rumoy-4ah-17@gated-at.bofh.it> (permalink) |
| References | <rufwK-6Ok-3@gated-at.bofh.it> <rufwK-6Ok-11@gated-at.bofh.it> <rug9r-7sB-1@gated-at.bofh.it> <rulCa-3sZ-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote: > > - entropy pool draining: when having a timer-based reseeding on a quiet > > system, the entropy pool can be drained during the expiry of the timer. So, I > > tried to handle that by increasing the timer by, say, 100 seconds for each new > > NUMA node. Note, even the baseline of 300 seconds with CRNG_RESEED_INTERVAL is > > low. When I experimented with that on a KVM test system and left it quiet, > > entropy pool draining was prevented at around 500 seconds. One other thought. If your KVM test system was completely quiet, then all of the entropy was coming from timer interrupts. It is an open question whether an adversary could predict the bit of "entropy" you are generating with better than 50% probability if both the host and the guest system are quiescent. And if they can, then maybe assuming one bit of entropy per interrupt might be a too optimistic. This is especially true on bare metal where very often, especially on smaller machines, where there is a single oscillator from which all of the clocks on the SOC or motherboard are derived. There is a reason why I was being ultra conservative in sampling 64 interrupts into a 32-bit fast-mix pool before mixing it into the input pool, and only crediting the pool with a single bit of entropy each time I did this. (It's also because of this conservatism that I was comfortable with having add_disk_randomness giving some extra credit for interrupts that are probably more likely to be hard-to-predict by an adversary. Especially if the interrupts are coming from a device with spinning rust platters.) - Ted
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH 0/3] random: replace urandom pool with a CRNG Theodore Ts'o <tytso@mit.edu> - 2016-05-02 08:30 +0200
[PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Theodore Ts'o <tytso@mit.edu> - 2016-05-02 08:30 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Stephan Mueller <smueller@chronox.de> - 2016-05-03 11:00 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Jeffrey Walton <noloader@gmail.com> - 2016-05-04 19:00 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG tytso@mit.edu - 2016-05-04 19:40 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG "H. Peter Anvin" <hpa@zytor.com> - 2016-05-04 20:00 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Stephan Mueller <smueller@chronox.de> - 2016-05-03 11:40 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Stephan Mueller <smueller@chronox.de> - 2016-05-04 08:30 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Jeffrey Walton <noloader@gmail.com> - 2016-05-04 16:50 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG tytso@mit.edu - 2016-05-04 19:50 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Jeffrey Walton <noloader@gmail.com> - 2016-05-04 20:30 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG "H. Peter Anvin" <hpa@zytor.com> - 2016-05-04 20:40 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG tytso@thunk.org - 2016-05-04 21:10 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG "H. Peter Anvin" <hpa@zytor.com> - 2016-05-04 23:00 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG John Denker <jsd@av8n.com> - 2016-05-04 23:50 +0200
Re: better patch for linux/bitops.h John Denker <jsd@av8n.com> - 2016-05-05 00:00 +0200
Re: better patch for linux/bitops.h Jeffrey Walton <noloader@gmail.com> - 2016-05-05 03:40 +0200
Re: better patch for linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-05 04:50 +0200
Re: better patch for linux/bitops.h Jeffrey Walton <noloader@gmail.com> - 2016-05-05 05:00 +0200
Re: better patch for linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-05 05:10 +0200
Re: better patch for linux/bitops.h Jeffrey Walton <noloader@gmail.com> - 2016-05-05 05:40 +0200
Re: better patch for linux/bitops.h Theodore Ts'o <tytso@mit.edu> - 2016-05-05 06:00 +0200
Re: better patch for linux/bitops.h Jeffrey Walton <noloader@gmail.com> - 2016-05-05 06:10 +0200
Re: better patch for linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-05 08:40 +0200
Re: UB in general ... and linux/bitops.h in particular John Denker <jsd@av8n.com> - 2016-05-05 18:20 +0200
Re: UB in general ... and linux/bitops.h in particular Andi Kleen <andi@firstfloor.org> - 2016-05-05 19:40 +0200
Re: UB in general ... and linux/bitops.h in particular Jeffrey Walton <noloader@gmail.com> - 2016-05-06 04:30 +0200
Re: better patch for linux/bitops.h Sandy Harris <sandyinchina@gmail.com> - 2016-05-05 23:40 +0200
Re: better patch for linux/bitops.h tytso@mit.edu - 2016-05-06 00:20 +0200
Re: better patch for linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-06 00:30 +0200
Re: better patch for linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-06 00:40 +0200
Re: better patch for linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-06 02:20 +0200
Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG "H. Peter Anvin" <hpa@zytor.com> - 2016-05-05 00:00 +0200
Re: linux/bitops.h John Denker <jsd@av8n.com> - 2016-05-05 00:10 +0200
Re: linux/bitops.h Andi Kleen <andi@firstfloor.org> - 2016-05-05 01:10 +0200
Re: linux/bitops.h John Denker <jsd@av8n.com> - 2016-05-05 02:20 +0200
Re: linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-05 03:30 +0200
Re: linux/bitops.h Jeffrey Walton <noloader@gmail.com> - 2016-05-05 03:30 +0200
Re: linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-05 02:40 +0200
Re: linux/bitops.h Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-05 02:50 +0200
Re: linux/bitops.h Sasha Levin <sasha.levin@oracle.com> - 2016-05-06 22:10 +0200
Re: linux/bitops.h Sasha Levin <sasha.levin@oracle.com> - 2016-05-06 22:10 +0200
Re: linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-06 22:30 +0200
Re: linux/bitops.h "H. Peter Anvin" <hpa@zytor.com> - 2016-05-06 22:40 +0200
[PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs Theodore Ts'o <tytso@mit.edu> - 2016-05-02 08:30 +0200
Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs Stephan Mueller <smueller@chronox.de> - 2016-05-02 09:10 +0200
Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs Theodore Ts'o <tytso@mit.edu> - 2016-05-02 15:00 +0200
Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs Theodore Ts'o <tytso@mit.edu> - 2016-05-02 15:50 +0200
Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs Stephan Mueller <smueller@chronox.de> - 2016-05-02 16:00 +0200
[PATCH 3/3] random: add interrupt callback to VMBus IRQ handler Theodore Ts'o <tytso@mit.edu> - 2016-05-02 08:30 +0200
Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler Jeffrey Walton <noloader@gmail.com> - 2016-05-02 11:10 +0200
Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler Stephan Mueller <smueller@chronox.de> - 2016-05-02 11:20 +0200
Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler Theodore Ts'o <tytso@mit.edu> - 2016-05-02 15:00 +0200
csiph-web