[opensuse-factory] haveged - now enabled by default?
Hi, I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jul 24, 2011 at 03:19:47PM +0100, Olipro wrote:
I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool.
See https://bugzilla.novell.com/show_bug.cgi?id=675841 which was refereced by the haveged package change log. - avoid unnecessary services. bnc#675841 also the start should be mediated by YaST or kiwi depending on presence of a virtualization environment, not by the package itself. Would it enhance the result if the installer suggest to enable haveged if we decide to operate in runlevel 3? The amount of black magic in changing defaults in the background without notifying the user must kept as minimal as possible. Please drive this via bugzilla to make references in the package change log to the bug IDs possible. In bugzilla you're able to place a pointer to the archive of this mailing list thread http://lists.opensuse.org/opensuse-factory/2011-07/msg00378.html Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Haveged has actually become higher priority with 12.1. I was advocating enabling it by default so I'm surprised to see that development has gone the opposite way.
In releases prior to 12.1, drivers for popular network devices contributed to the entropy pool. Those patches weren't getting much traction upstream so we dropped them in the 12.1 kernel. The entropy pool will not be replenished as quickly on 12.1 naturally so haveged being enabled by default would be a good idea.
-Jeff
--
Jeff Mahoney
(apologies for the top post -- from my mobile)
On Jul 24, 2011, at 11:02 AM, Lars Müller
On Sun, Jul 24, 2011 at 03:19:47PM +0100, Olipro wrote:
I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool.
See https://bugzilla.novell.com/show_bug.cgi?id=675841 which was refereced by the haveged package change log.
- avoid unnecessary services. bnc#675841 also the start should be mediated by YaST or kiwi depending on presence of a virtualization environment, not by the package itself.
Would it enhance the result if the installer suggest to enable haveged if we decide to operate in runlevel 3?
The amount of black magic in changing defaults in the background without notifying the user must kept as minimal as possible.
Please drive this via bugzilla to make references in the package change log to the bug IDs possible. In bugzilla you're able to place a pointer to the archive of this mailing list thread http://lists.opensuse.org/opensuse-factory/2011-07/msg00378.html
Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time. We reviewed haveged for SLE 11, from a integrity security side it is ok. We reviewed the randomness it generates briefly (!) and found no issues. However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me. It insanity rating is similar to using /dev/urandom, refering to a previous comment. That said, we are fine with enabling it if people consider it necessary. Ciao, Marcus On Sun, Jul 24, 2011 at 03:34:23PM -0400, Jeff Mahoney wrote:
Haveged has actually become higher priority with 12.1. I was advocating enabling it by default so I'm surprised to see that development has gone the opposite way.
In releases prior to 12.1, drivers for popular network devices contributed to the entropy pool. Those patches weren't getting much traction upstream so we dropped them in the 12.1 kernel. The entropy pool will not be replenished as quickly on 12.1 naturally so haveged being enabled by default would be a good idea.
-Jeff
-- Jeff Mahoney (apologies for the top post -- from my mobile)
On Jul 24, 2011, at 11:02 AM, Lars Müller
wrote: On Sun, Jul 24, 2011 at 03:19:47PM +0100, Olipro wrote:
I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool.
See https://bugzilla.novell.com/show_bug.cgi?id=675841 which was refereced by the haveged package change log.
- avoid unnecessary services. bnc#675841 also the start should be mediated by YaST or kiwi depending on presence of a virtualization environment, not by the package itself.
Would it enhance the result if the installer suggest to enable haveged if we decide to operate in runlevel 3?
The amount of black magic in changing defaults in the background without notifying the user must kept as minimal as possible.
Please drive this via bugzilla to make references in the package change log to the bug IDs possible. In bugzilla you're able to place a pointer to the archive of this mailing list thread http://lists.opensuse.org/opensuse-factory/2011-07/msg00378.html
Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- Working, but not speaking, for the following german company: SUSE LINUX Products GmbH, HRB 16746 (AG Nuernberg) Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/26/2011 02:34 PM, Marcus Meissner wrote:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
Ciao, Marcus
On Sun, Jul 24, 2011 at 03:34:23PM -0400, Jeff Mahoney wrote:
Haveged has actually become higher priority with 12.1. I was advocating enabling it by default so I'm surprised to see that development has gone the opposite way.
In releases prior to 12.1, drivers for popular network devices contributed to the entropy pool. Those patches weren't getting much traction upstream so we dropped them in the 12.1 kernel. The entropy pool will not be replenished as quickly on 12.1 naturally so haveged being enabled by default would be a good idea.
-Jeff
-- Jeff Mahoney (apologies for the top post -- from my mobile)
On Jul 24, 2011, at 11:02 AM, Lars Müller
wrote: On Sun, Jul 24, 2011 at 03:19:47PM +0100, Olipro wrote:
I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool.
See https://bugzilla.novell.com/show_bug.cgi?id=675841 which was refereced by the haveged package change log.
- avoid unnecessary services. bnc#675841 also the start should be mediated by YaST or kiwi depending on presence of a virtualization environment, not by the package itself.
Would it enhance the result if the installer suggest to enable haveged if we decide to operate in runlevel 3?
The amount of black magic in changing defaults in the background without notifying the user must kept as minimal as possible.
Please drive this via bugzilla to make references in the package change log to the bug IDs possible. In bugzilla you're able to place a pointer to the archive of this mailing list thread http://lists.opensuse.org/opensuse-factory/2011-07/msg00378.html
Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Marcus, I'm using haveged, for example on a multi-purpose webserver dns, hosting etc. here the munin report about the entropy with haveged on (until May it was a 11.2 openSUSE) Last month http://dl.dropbox.com/u/13333867/openSUSE/haveged-entropy-month.png Last year http://dl.dropbox.com/u/13333867/openSUSE/havged-entropy-year.png I can push several other hosts, with same kind of data. Just ask. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Jul 26, 2011 at 02:43:05PM +0200, Bruno Friedmann wrote: ...
Marcus, I'm using haveged, for example on a multi-purpose webserver dns, hosting etc. here the munin report about the entropy with haveged on (until May it was a 11.2 openSUSE)
Last month http://dl.dropbox.com/u/13333867/openSUSE/haveged-entropy-month.png
Last year http://dl.dropbox.com/u/13333867/openSUSE/havged-entropy-year.png
I can push several other hosts, with same kind of data. Just ask.
The bad thing is that a cryptographic encrypted stream of pseudo randomness is not really distinguishable from real randomness. You would need to evaluate the underlying technology. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 26 July 2011 14:07, Marcus Meissner
On Tue, Jul 26, 2011 at 02:43:05PM +0200, Bruno Friedmann wrote: ... The bad thing is that a cryptographic encrypted stream of pseudo randomness is not really distinguishable from real randomness.
You would need to evaluate the underlying technology.
How is that a bad thing? If you can't distinguish, then how could an attacker exploit it? I understand that some deployments will want to have carefully "unquestionable" entropy sources, but that appears to me to be an argument to enable haveged in general. May be I'm missing something, but for general installation with practical relaxed requirements this sounds like a "feature", a remote attacker would have problems to "evaluate the underlying technology" to select target. Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/26/2011 08:34 AM, Marcus Meissner wrote:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
Hrm, if the quality is indistinguishable from /dev/urandom, why wouldn't we just pump from /dev/urandom when /dev/random runs out? - -Jeff
Ciao, Marcus
On Sun, Jul 24, 2011 at 03:34:23PM -0400, Jeff Mahoney wrote:
Haveged has actually become higher priority with 12.1. I was advocating enabling it by default so I'm surprised to see that development has gone the opposite way.
In releases prior to 12.1, drivers for popular network devices contributed to the entropy pool. Those patches weren't getting much traction upstream so we dropped them in the 12.1 kernel. The entropy pool will not be replenished as quickly on 12.1 naturally so haveged being enabled by default would be a good idea.
-Jeff
-- Jeff Mahoney (apologies for the top post -- from my mobile)
On Jul 24, 2011, at 11:02 AM, Lars Müller
wrote: On Sun, Jul 24, 2011 at 03:19:47PM +0100, Olipro wrote:
I see someone else made a post back in May about this and I was wondering if anything came of it since; This daemon is sadly disabled by default in 11.4 which results in /dev/random having very little available entropy at all and thus anything that uses /dev/random for key generation will tend to stall for inordinate amounts of time, especially on systems that are only running from the commandline, for example, I have occasionally seen DNSSEC tutorials for openSUSE which use /dev/urandom - something that I think is just insane, but most likely a result of nothing being available to fill the entropy pool.
See https://bugzilla.novell.com/show_bug.cgi?id=675841 which was refereced by the haveged package change log.
- avoid unnecessary services. bnc#675841 also the start should be mediated by YaST or kiwi depending on presence of a virtualization environment, not by the package itself.
Would it enhance the result if the installer suggest to enable haveged if we decide to operate in runlevel 3?
The amount of black magic in changing defaults in the background without notifying the user must kept as minimal as possible.
Please drive this via bugzilla to make references in the package change log to the bug IDs possible. In bugzilla you're able to place a pointer to the archive of this mailing list thread http://lists.opensuse.org/opensuse-factory/2011-07/msg00378.html
Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4uwqUACgkQLPWxlyuTD7JijQCeNBSWbOfoSA6V18+QZvlKSJps NO0An0isOguoMG4oxTM6DM5AWTTXjD1g =FRUL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Jul 26, 2011 at 09:35:33AM -0400, Jeff Mahoney wrote:
On 07/26/2011 08:34 AM, Marcus Meissner wrote:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
Hrm, if the quality is indistinguishable from /dev/urandom, why wouldn't we just pump from /dev/urandom when /dev/random runs out?
I just wanted to point out that it is hard to differ real entropy and pseudo randomness. haveged claims to derive randomness from timer fluctuations in calculations and cache timings and cache flushings, and we used timer based randomness when feeding from network cards and human input devices. As long as the CPUs don't have predictable timings in the used calculations currently haveged can be used for "real" entropy. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 26 Jul 2011 15:01:33 Marcus Meissner wrote:
On Tue, Jul 26, 2011 at 09:35:33AM -0400, Jeff Mahoney wrote:
On 07/26/2011 08:34 AM, Marcus Meissner wrote:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
Hrm, if the quality is indistinguishable from /dev/urandom, why wouldn't we just pump from /dev/urandom when /dev/random runs out?
I just wanted to point out that it is hard to differ real entropy and pseudo randomness.
haveged claims to derive randomness from timer fluctuations in calculations and cache timings and cache flushings, and we used timer based randomness when feeding from network cards and human input devices.
As long as the CPUs don't have predictable timings in the used calculations currently haveged can be used for "real" entropy.
Ciao, Marcus
I believe it's also worth pointing out that haveged only feeds the data into the kernel, it does not manipulate the entropy estimate - therefore, even if someone were to hack or replace haveged with something that feeds the kernel non-random data, the kernel will simply not increase its entropy estimate. If there were actual issues where you could perform poisoning of the entropy pool in the kernel by feeding it non-random data, then you probably shouldn't be allowing non-root users to write /dev/random as far as I am aware, there aren't any such issues. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 26 Jul 2011 15:01:33 Marcus Meissner wrote:
On Tue, Jul 26, 2011 at 09:35:33AM -0400, Jeff Mahoney wrote:
On 07/26/2011 08:34 AM, Marcus Meissner wrote:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
Hrm, if the quality is indistinguishable from /dev/urandom, why wouldn't we just pump from /dev/urandom when /dev/random runs out?
I just wanted to point out that it is hard to differ real entropy and pseudo randomness.
haveged claims to derive randomness from timer fluctuations in calculations and cache timings and cache flushings, and we used timer based randomness when feeding from network cards and human input devices.
As long as the CPUs don't have predictable timings in the used calculations currently haveged can be used for "real" entropy.
Ciao, Marcus
If you find it "too good to be true" then here's a very simple experiment you can do to demonstrate exactly how big of a difference there is between pseudo- random and actually (or indeterminable from random) data there is. 1) remove/disable all sources of entropy as best as you possibly can 2) dd if=/dev/random of=/dev/null obs=16 3) watch /proc/sys/kernel/random/entropy_avail until available entropy drops to around the 100 mark. 4) dd if=/dev/urandom of=/dev/random - we are now dumping pseudo-random data directly into the kernel's RNG entropy pool. 5) observe how it fails to make absolutely any difference to entropy_avail You can thus rest assured that the microtime a CPU takes to perform x number of loops will never be the same ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 27 July 2011 08:23, Olipro
I believe it's also worth pointing out that haveged only feeds the data into the kernel, it does not manipulate the entropy estimate - therefore, even if someone were to hack or replace haveged with something that feeds the kernel non-random data, the kernel will simply not increase its entropy estimate.
It's quite a while since I looked at the Fate entry on entropy sources being required, and the experimental code I wrote which played with timers is deleted long ago, but IIRC you needed to increase the kernel's estimate of entropy, to stop the blocking, not just do the data writing. The kernel estimating the randomness of data written to /dev/random sounds expensive. Did anyone look at "audio entropy daemon" http://www.vanheusden.com/aed/ which aims to use static noise from unused sound card? Presumably such would be widely available thanks to integrated audio, even on diskless installs. This program feeds the /dev/random device with entropy-data read from an audio device. The audio-data is not copied as is but first 'de-biased' and analysed to determine how much bits of entropy is in it. This program is usefull for systems doing lots of cryptographic stuff like VPN endpoints or GPG clients; it helps preventing that the /dev/random device gets depleted and blocks reads. Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob Davies wrote:
On 27 July 2011 08:23, Olipro
wrote: I believe it's also worth pointing out that haveged only feeds the data into the kernel, it does not manipulate the entropy estimate - therefore, even if someone were to hack or replace haveged with something that feeds the kernel non-random data, the kernel will simply not increase its entropy estimate.
It's quite a while since I looked at the Fate entry on entropy sources being required, and the experimental code I wrote which played with timers is deleted long ago, but IIRC you needed to increase the kernel's estimate of entropy, to stop the blocking, not just do the data writing. The kernel estimating the randomness of data written to /dev/random sounds expensive.
Did anyone look at "audio entropy daemon" http://www.vanheusden.com/aed/ which aims to use static noise from unused sound card? Presumably such would be widely available thanks to integrated audio, even on diskless installs.
Perhaps except on servers - none of mine have on-board sound. /Per -- Per Jessen, Zürich (23.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 27 July 2011 14:02, Per Jessen
Rob Davies wrote:
Presumably such would be widely available thanks to integrated audio, even on diskless installs.
Perhaps except on servers - none of mine have on-board sound.
Ok, so are your servers entropy starved or are there sufficient interrupts in practice? Would USB key type hardware be practical? Presumably your server boards are not budget models and operate in a controlled secure environment. Do you have (assuming you see entropy starvation and hardware solution impractical) objections to running haveged, making it poor choice? What else would be doable? The Fate entry I was thinking of mentioned networked diskless installations, which might need fair amount of entropy but receive less as network card contributed entropy has issues and they may have unused audio input. The timing unpredictability approach, appeared simpler to deploy, because it did not require hardware, yet seems less trusted as "real" hardware interrupts. I wondered if the audio based daemon might have a niche. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob Davies wrote:
On 27 July 2011 14:02, Per Jessen
wrote: Rob Davies wrote:
Presumably such would be widely available thanks to integrated audio, even on diskless installs.
Perhaps except on servers - none of mine have on-board sound.
Ok, so are your servers entropy starved or are there sufficient interrupts in practice?
Probably no and very probably yes. I wasn't trying to argue either way, just thought I'd mention it.
Would USB key type hardware be practical? Presumably your server boards are not budget models and operate in a controlled secure environment.
Yup.
Do you have (assuming you see entropy starvation and hardware solution impractical) objections to running haveged, making it poor choice?
To me (albeit with very limited understanding of the issues involved here), running haveged by default sounds like a perfectly good idea. If I needed a higher quality random source, hardware would likely be my choice.
The Fate entry I was thinking of mentioned networked diskless installations, which might need fair amount of entropy but receive less as network card contributed entropy has issues and they may have unused audio input. The timing unpredictability approach, appeared simpler to deploy, because it did not require hardware, yet seems less trusted as "real" hardware interrupts. I wondered if the audio based daemon might have a niche.
It sounds like an idea worth exploring. One thing I've been wondering about (whilst reading this thread) - in which kind of environment does the problem occur? (assuming problem = low entropy, high demand) -- Per Jessen, Zürich (20.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 27 July 2011 18:28, Per Jessen
It sounds like an idea worth exploring. One thing I've been wondering about (whilst reading this thread) - in which kind of environment does the problem occur? (assuming problem = low entropy, high demand)
https://features.opensuse.org/306591 "Headless and diskless servers with limited input have relied on entropy added by interrupts flagged with IRQF_SAMPLE_RANDOM. However, this feature will be disappearing from the Kernel soon." Then mentioned video, audio & egd (Entropy Gathering Daemon), which seemed all to have drawbacks. haveged wasn't mentioned or turn up when I looked for something better. Talk about TPM kernel modules rather killed my interest, as impractical for me; I didn't want to be stranded in "No Man's Land" between those who wanted best possible cryptographic security and those who "just want it to work" with less stringent requirements with each side objecting to suggested solutions for the other requirements. The basic problem is caused by profligate consumption of entropy from /dev/random, by things that could be fine with /dev/urandom, lack of user interaction, moving mouse & typing adds entropy, lack of other interrupts on hardware in question. I found entropy was consumed, running rsync over ssh for example. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob Davies wrote:
On 27 July 2011 18:28, Per Jessen
wrote: It sounds like an idea worth exploring. One thing I've been wondering about (whilst reading this thread) - in which kind of environment does the problem occur? (assuming problem = low entropy, high demand)
https://features.opensuse.org/306591
"Headless and diskless servers with limited input have relied on entropy added by interrupts flagged with IRQF_SAMPLE_RANDOM. However, this feature will be disappearing from the Kernel soon."
Thanks. I guess that is primarily virtual and/or blade systems with iscsi or network file systems? -- Per Jessen, Zürich (18.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Wed, 27 Jul 2011 18:47:15 +0100
schrieb Rob Davies
The basic problem is caused by profligate consumption of entropy from /dev/random, by things that could be fine with /dev/urandom, lack of user interaction, moving mouse & typing adds entropy, lack of other interrupts on hardware in question.
echo "ln -sf urandom /dev/random" >> /etc/init.d/boot.local :-) -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 27 July 2011 20:45, Stefan Seyfried
Am Wed, 27 Jul 2011 18:47:15 +0100 schrieb Rob Davies
: The basic problem is caused by profligate consumption of entropy from /dev/random
echo "ln -sf urandom /dev/random" >> /etc/init.d/boot.local
:) But probably not what you really want to do if you distributing softate that wants to generate long lived keys. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Dienstag, 26. Juli 2011 schrieb Marcus Meissner:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
I think we can easily install it by default and if someone writes a yast agent to enable it for runlevel 3 installations, I'm fine with that too. But I don't want an extra daemon running on default installs that usually don't need it - and those that do need it, can easily enable it. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 27 Jul 2011 08:28:44 Stephan Kulow wrote:
Am Dienstag, 26. Juli 2011 schrieb Marcus Meissner:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
I think we can easily install it by default and if someone writes a yast agent to enable it for runlevel 3 installations, I'm fine with that too. But I don't want an extra daemon running on default installs that usually don't need it - and those that do need it, can easily enable it.
Greetings, Stephan
The problem is largely that those that *do* need it probably don't actually know they need it. So if you don't want it running on default installs, rather than just blanket turning it off, do something intelligent to determine whether it should be enabled or not. How many people do you think are aware of things like the kernel's entropy pool etcetera? my bet is that the correct answer is "very few" given so many people are swapping random with urandom. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/27/2011 11:16 AM, Olipro wrote:
On Wednesday 27 Jul 2011 08:28:44 Stephan Kulow wrote:
Am Dienstag, 26. Juli 2011 schrieb Marcus Meissner:
Hi,
The reasoning to not have it enabled was the mimimal set of services running to reduce security attack surface and to enhance startup time.
We reviewed haveged for SLE 11, from a integrity security side it is ok.
We reviewed the randomness it generates briefly (!) and found no issues.
However ... the sheer amount of randomness it claims to generate feels a bit too good to be true to me.
It insanity rating is similar to using /dev/urandom, refering to a previous comment.
That said, we are fine with enabling it if people consider it necessary.
I think we can easily install it by default and if someone writes a yast agent to enable it for runlevel 3 installations, I'm fine with that too. But I don't want an extra daemon running on default installs that usually don't need it - and those that do need it, can easily enable it.
Greetings, Stephan
The problem is largely that those that *do* need it probably don't actually know they need it. So if you don't want it running on default installs, rather than just blanket turning it off, do something intelligent to determine whether it should be enabled or not.
How many people do you think are aware of things like the kernel's entropy pool etcetera? my bet is that the correct answer is "very few" given so many people are swapping random with urandom.
One of the other reason to have it enabled early in the installation process or just before you start configuring things is : ssl key generation think about vpn server, dns, ldap, CA, ssh keys, ssl/tls vhosts, databases tls connexion and will become more and more used : dns signing zone DNSSEC Yeap typically not a workstation usage, but pretty much all server pattern should have it. No ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 27 July 2011 10:57, Bruno Friedmann
One of the other reason to have it enabled early in the installation process or just before you start configuring things is : ssl key generation think about vpn server, dns, ldap, CA, ssh keys, ssl/tls vhosts, databases tls connexion and will become more and more used : dns signing zone DNSSEC
Yeap typically not a workstation usage, but pretty much all server pattern should have it.
No ?
Including something in default install does not really HELP anyone, but imposes taxes (adds a small cost on) very many installations that don't need it. So I think that is logically the WORST option of all. After all it's easy with zypper to install packages eg) "zypper in haveged; chkconfig haveged on" as Olipro said, the problem is knowing you need it. It is better to do nothing and not install haveged at all, at least the objectors are then happy.. Patterns sound better to me than the "if install to runlevel 3" idea. Because it's quite legitimate to install to graphical or text, and then change default run level later, or have graphical display idle without UI. But including via recommends or server pattern something that operates "on demand" when entropy consumers are installed actually does target real useage. I think avoiding slowing boot up is the basis for Coolo's objection. And according to http://www.issihosts.com/haveged/ 1) "Ultimately, I decided that urandom was a bad idea. To see why, look at figure 2.1 in Gutterman, Pinkas, and Reinman (page 5). You will see that pulling from an empty urandom pool, triggers a fill from the primary entropy pool - the thing you are trying to fill! I don't know of anyone who has really tested what the result of this is, but the output of any pseudo random number generator has to have a hardware seed somewhere and this arrangement looks prone to generating artifacts. And since there is no check on data sanity in this arrangement so who knows what is really in the random pools?" Which is one answer to Jeff's question "why not pull from /dev/urandom to fill random". 2) "The daemon suspends itself on the random device waiting for a write_low_watemark event." Suggests something may be doable with systemd, to trigger entropy suplementation on demand, which is "interesting". Especially if Cristian Rodríguez as haveged maintainer isn't set on a hardware or in kernel solution, meaning he'd reject on principal contributions which explore this possibility. in /proc/sys/kernel/random we have : entropy_avail poolsize write_wakeup_threshold read_wakeup_threshold So would a solution that reacts to low entropy, that remains consistently low for 5 or 10 seconds, be in principal acceptable, even if it only reported via log likely entropy starvation? Regards Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 24/07/11 10:19, Olipro escribió:
something that I think is just insane,
Yes, it is insane, point your guns to kernel developers ;) This haveged daemon is an userspace workaround, that provides strong, high quality entropy (passes all FIPS tests) but it is not a long term solution. If you want a permanent solution, get one of this http://www.entropykey.co.uk/ Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sunday 24 Jul 2011 17:41:25 Cristian Rodríguez wrote:
El 24/07/11 10:19, Olipro escribió:
something that I think is just insane,
Yes, it is insane, point your guns to kernel developers ;)
This haveged daemon is an userspace workaround, that provides strong, high quality entropy (passes all FIPS tests) but it is not a long term solution.
If you want a permanent solution, get one of this http://www.entropykey.co.uk/
Cheers.
Is this the mailing list for SuSE or random advertisements of RNG hardware? (pun intended) The issue wasn't really about grandstanding over what sort of entropy gathering should or should not be in the kernel but rather the fact that as it stands, openSUSE has a significant issue with the /dev/random device which could be alleviated by enabling haveged by default at (preferably) runlevels 3 and 5. I think what needs to be done is to make an objective evaluation of what sort of footprint haveged has on a system when left enabled by default, and weigh that cost up against the benefit of ensuring that programs using /dev/random are not impacted - personally, I would say that classifying it as "unnecessary" is disingenous and that having it enabled by default has benefits far greater than the few Kb of memory it will consume. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 24 July 2011 18:34, Olipro
On Sunday 24 Jul 2011 17:41:25 Cristian Rodríguez wrote:
El 24/07/11 10:19, Olipro escribió:
something that I think is just insane,
Yes, it is insane, point your guns to kernel developers ;)
This haveged daemon is an userspace workaround, that provides strong, high quality entropy (passes all FIPS tests) but it is not a long term solution.
If you want a permanent solution, get one of this http://www.entropykey.co.uk/
Is this the mailing list for SuSE or random advertisements of RNG hardware? (pun intended)
It brings a smile seeing a USB key described as a "permanent solution" though! The complaint in Bug#675841, was about the Release Notes, with changes undocumented due to the low level of detail provided, https://bugzilla.novell.com/show_bug.cgi?id=675841. The Changelog for haveged item "- avoid unnecessary services. bnc#675841" appears misleading. However http://www.issihosts.com/haveged/ suggests "haveged" isn't just a few kb, it talks about a "collects entropy harvests in a 8MB buffer which is read byte by byte", though I guess that can be paged out if you don't really need the daemon. Another option might be to enable the daemon, on machines where entropy available becomes low and only slowly replaced. Run it on a machine, that can become entropy starved, say overnight without active UI. The daemon suspends itself on the random device waiting for a write_low_watemark event. So perhaps a stub, could do the same and intelligently enable the daemon if it appears necessary? Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sunday 24 Jul 2011 19:37:25 you wrote:
On 24 July 2011 18:34, Olipro
wrote: On Sunday 24 Jul 2011 17:41:25 Cristian Rodríguez wrote:
El 24/07/11 10:19, Olipro escribió:
something that I think is just insane,
Yes, it is insane, point your guns to kernel developers ;)
This haveged daemon is an userspace workaround, that provides strong, high quality entropy (passes all FIPS tests) but it is not a long term solution.
If you want a permanent solution, get one of this http://www.entropykey.co.uk/
Is this the mailing list for SuSE or random advertisements of RNG hardware? (pun intended)
It brings a smile seeing a USB key described as a "permanent solution" though!
The complaint in Bug#675841, was about the Release Notes, with changes undocumented due to the low level of detail provided, https://bugzilla.novell.com/show_bug.cgi?id=675841. The Changelog for haveged item "- avoid unnecessary services. bnc#675841" appears misleading.
However http://www.issihosts.com/haveged/ suggests "haveged" isn't just a few kb, it talks about a "collects entropy harvests in a 8MB buffer which is read byte by byte", though I guess that can be paged out if you don't really need the daemon.
Another option might be to enable the daemon, on machines where entropy available becomes low and only slowly replaced. Run it on a machine, that can become entropy starved, say overnight without active UI. The daemon suspends itself on the random device waiting for a write_low_watemark event. So perhaps a stub, could do the same and intelligently enable the daemon if it appears necessary?
Rob
I believe the daemon only consumes memory when entropy gets low... it then proceeds to replenish the kernel and goes back to sleep... At least that's why a cursory google search has led me to believe; if this isn't so then surely this could be easily achieved with a small modification. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 24/07/11 14:37, Rob Davies escribió:
It brings a smile seeing a USB key described as a "permanent solution" though!
Well, permanent as long the USB key doesn't break or the noise generator inside is considered broken..or the the hash algorithm used (skein 256) becomes "weak"...
So perhaps a stub, could do the same and intelligently enable the daemon if it appears necessary?
aka, magic. no thanks ! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 24 July 2011 20:18, Cristian Rodríguez
El 24/07/11 14:37, Rob Davies escribió:
It brings a smile seeing a USB key described as a "permanent solution" though!
Well, permanent as long the USB key doesn't break or the noise generator inside is considered broken..or the the hash algorithm used (skein 256) becomes "weak"...
Or Hot unplug... Magic or an algorithmn? All kinds of things are likely to be going on in a modern OS, without your say so. cron.daily scripts, GC's, new features coming like auto-defrag on BTRFS. Having such packages uninstalled defends those who care a lot about the entropy pool, who bother with hardware solutions. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 24/07/11 15:31, Rob Davies escribió:
On 24 July 2011 20:18, Cristian Rodríguez
wrote: El 24/07/11 14:37, Rob Davies escribió:
It brings a smile seeing a USB key described as a "permanent solution" though!
Well, permanent as long the USB key doesn't break or the noise generator inside is considered broken..or the the hash algorithm used (skein 256) becomes "weak"...
Or Hot unplug...
Unplug is logged...
cron.daily scripts, GC's,
To do what you suggest you need exactly what the daemon itself already does, monitor the entropy amount of the system, if it goes lower than a limit it starts working. You are telling that we add another level of complexity in determining "if the daemon is needed" and then starting it according, it is as equally crazy as what I was asked to add in the past (I maintain "haveged"), which was "the daemon starting by default only in virtual machines" Sometimes I think users are completely nuts :-)
new features coming like auto-defrag on BTRFS.
The kernel can do nice things, this is exactly my argument why all this entropy thing does not belong in userspace but in kernel ;-) Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 24 July 2011 20:45, Cristian Rodríguez
On 24 July 2011 20:18, Cristian Rodríguez
wrote: El 24/07/11 14:37, Rob Davies escribió:
To do what you suggest you need exactly what the daemon itself already does, monitor the entropy amount of the system, if it goes lower than a
El 24/07/11 15:31, Rob Davies escribió: limit it starts working.
Saying "it should" be done by kernel doesn't help, when Linux 3.0 doesn't and that's what we've got. Can you really see many installs having those USB keys? (I can't, I just think, you'll get some users saying openSUSE's slow.). On demand daemon starting is an issue for 12.1, if you do it for CUPS why not something that provides entropy if it's generally not useful to most installs? It's just events, print job submitted, low water mark hit. I have not seen what the objections were to having the daemon started by default, and I pointed out that the changelog misrepresented the discussion in the bug, which was about lack of information in the release notes. Very likely that's the simplest practical solution. Far from "telling that we add another level of complexity", I just pointed out a possible alternative, rather than just blocking ignoring or reporting a problem, the system activates something to ameliorate it when it seems useful. I DO NOT care that would be ineffiecient, it is far more efficient than a call to a sysadmin. I don't understand why you think reacting to such an issue is too complicated, because good sysadmins end up writing scripts to do that kind of maintenance rather often, and there were objections to the non-obvious inclusion in Installer. Overloading the choice of run level 3 rather than 5, seems rather indirect and fragile to me; install time can be very different from real usage so dislike of that alternative is understandable. Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 24/07/11 17:56, Rob Davies escribió:
Saying "it should" be done by kernel doesn't help, when Linux 3.0 doesn't and that's what we've got.
Usually helps ;) when complaining and bitching reaches the right person at the right time, things get fixed ! ;-)
Can you really see many installs having those USB keys? (I can't, I just think, you'll get some users saying openSUSE's slow.).
No, I don't see many installs running those keys.
if you do it for CUPS
why not something that provides entropy if it's generally not useful to most installs? It's just events, print job submitted, low water mark hit.
Does cups do that without the cupsd daemon running and/or without the kernel or udev's help ?
I have not seen what the objections were to having the daemon started by default,
I don't know, I have not changed the default, it was objected by someone else.
I don't understand why you think reacting to such an issue is too complicated,
Maybe because I have to it ? :-D I think the daemon should be started by default, or as I have said previously, moving this stuff where it belongs which is in the kernel, where it loads hardware rng and feeds the random pool by itself, and fallbacks to an "haveged like" kernel module when there is no such hardware present. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sunday 24 Jul 2011 22:56:06 Rob Davies wrote:
On 24 July 2011 20:45, Cristian Rodríguez
wrote: On 24 July 2011 20:18, Cristian Rodríguez
wrote: El 24/07/11 14:37, Rob Davies escribió: To do what you suggest you need exactly what the daemon itself already does, monitor the entropy amount of the system, if it goes lower than a
El 24/07/11 15:31, Rob Davies escribió: limit it starts working.
Saying "it should" be done by kernel doesn't help, when Linux 3.0 doesn't and that's what we've got. Can you really see many installs having those USB keys? (I can't, I just think, you'll get some users saying openSUSE's slow.).
On demand daemon starting is an issue for 12.1, if you do it for CUPS why not something that provides entropy if it's generally not useful to most installs? It's just events, print job submitted, low water mark hit.
I have not seen what the objections were to having the daemon started by default, and I pointed out that the changelog misrepresented the discussion in the bug, which was about lack of information in the release notes. Very likely that's the simplest practical solution.
Far from "telling that we add another level of complexity", I just pointed out a possible alternative, rather than just blocking ignoring or reporting a problem, the system activates something to ameliorate it when it seems useful. I DO NOT care that would be ineffiecient, it is far more efficient than a call to a sysadmin. I don't understand why you think reacting to such an issue is too complicated, because good sysadmins end up writing scripts to do that kind of maintenance rather often, and there were objections to the non-obvious inclusion in Installer. Overloading the choice of run level 3 rather than 5, seems rather indirect and fragile to me; install time can be very different from real usage so dislike of that alternative is understandable.
Rob
Agreed. In any case, from having haveged running on my 11.4 box, its footprint seems to be very small, around 6Kb and it simply sits there idling; if I dd /dev/random into /dev/null then it starts consuming CPU cycles but does not increase memory consumption. I could completely understand disabling this if you were running SUSE on some embedded system where memory was incredibly tight to the point that you were compiling your own stripped-down kernel to accommodate for the fact - in all other instances, haveged is just going to sit there and do nothing if the system always has sufficient entropy. So the cost-benefit analysis is that either you cost everyone who doesn't know that they don't need haveged a few Kb of memory to have it running at all times to ensure people on entropy starved machines don't ever run into issues with applications that rely on /dev/random or you decide to save a few Kb at the cost of causing hassle for people with insufficient system entropy. the only other possibility I can think of is to have the installation environment (or some post-install runonce) attempt to empty out /dev/random and see how quickly it replenishes and use that to make a decision as to whether or not to enable haveged for that particular system, given that haveged will give you roughly 1.7MB/s of entropy. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (11)
-
Bruno Friedmann
-
Cristian Rodríguez
-
Jeff Mahoney
-
Jeff Mahoney
-
Lars Müller
-
Marcus Meissner
-
Olipro
-
Per Jessen
-
Rob Davies
-
Stefan Seyfried
-
Stephan Kulow