Re: Why does reading from /dev/urandom deplete entropy so much?
Theodore Tso wrote: On Sat, Dec 08, 2007 at 02:37:57AM -0500, Jon Masters wrote: BTW, You may be better off using "uuidgen -t" to generate the UUID in the smolt RPM, since that will use 12 bits of randomness from /dev/random, plus the MAC, address and timestamp. So even if there is zero randomness in /dev/random, and the time is January 1, 1970, at least the MAC will contribute some uniqueness to the UUID. I haven't checked how uuidgen uses the MAC, but I would suggest that that is not something Fedora should jump at doing - although it would help ensure unique UUIDs, it also contributes to the tinfoil hat responses that usually come up with things like smolt. Huh? What's the concern? All you are submitting is a list of hardware devices in your system. That's hardly anything sensitive We actually had a very vocal minority about all of that which ended up putting us in the unfortunate position of generating a random UUID instead of using a hardware UUID from hal :-/ -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Matt Mackall wrote: On Tue, Dec 04, 2007 at 04:23:12PM -0600, Mike McGrath wrote: Matt Mackall wrote: On Tue, Dec 04, 2007 at 03:18:27PM -0600, Mike McGrath wrote: Matt Mackall wrote: which would have been in v2.6.22-rc4 through the normal CVE process. The only other bits in there are wall time and utsname, so systems with no CMOS clock would behave repeatably. Can we find out what kernels are affected? We can but it will likely take a few weeks to get a good sampling. UUID is unique in the db so when someone checks in with the same UUID, the old one gets overwritten. We can probably assume that for whatever reason the two things with duplicate UUID had the same seed. If not, we've got -much- bigger problems. Ok, I think I see whats going on here. I have some further investigation to do but it seems that the way our Live CD installer works is causing these issues. I'm going to try to grab some live CD's and hardware to confirm but at this point it seems thats whats going on. Alright, keep me posted. We probably need a scheme to make the initial seed more robust regardless of what you find out Ok, whats going on here is an issue with how the smolt RPM installs the UUID and how Fedora's Live CD does an install. It's a complete false alarm on the kernel side, sorry for the confusion. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Matt Mackall wrote: On Tue, Dec 04, 2007 at 03:18:27PM -0600, Mike McGrath wrote: Matt Mackall wrote: which would have been in v2.6.22-rc4 through the normal CVE process. The only other bits in there are wall time and utsname, so systems with no CMOS clock would behave repeatably. Can we find out what kernels are affected? We can but it will likely take a few weeks to get a good sampling. UUID is unique in the db so when someone checks in with the same UUID, the old one gets overwritten. We can probably assume that for whatever reason the two things with duplicate UUID had the same seed. If not, we've got -much- bigger problems. Ok, I think I see whats going on here. I have some further investigation to do but it seems that the way our Live CD installer works is causing these issues. I'm going to try to grab some live CD's and hardware to confirm but at this point it seems thats whats going on. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Theodore Tso wrote: On Tue, Dec 04, 2007 at 02:48:12PM -0600, Mike McGrath wrote: Alan Cox wrote: Here's the top 5: 266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132 336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a 402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f 884 06e84493-e024-44b1-9b32-32d78af04039 931 e2b67e1d-e325-4740-b938-795addb45280 The left number is times this month someone has submitted a profile with that UUID. If we take the last one as an example has come from over 800 IP's in the last 20 days. It seems very unlikely that one person would find his way to 800 different IP's this month. Let me know if you'd like more. Background - Smolt runs this during its install: /bin/cat /proc/sys/kernel/random/uuid > /etc/sysconfig/hw-uuid For most users this would be run by the RPM %post scripts during install from anaconda. For some reason there are some UUID's (like those listed above) that come up more often then it seems they should if they are truly random. Would this be by any chance using kickstart where there is no user interaction, and no way of gathering entropy during the install process? The random number generator isn't *magic* you know This is certainly possible but I think its unlikely. Not many people know about smolt. Most of our profiles come from prompting people during firstboot which gets skipped when people are running kickstart. I'll make sure to follow up with people that report a duplicate. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Matt Mackall wrote: which would have been in v2.6.22-rc4 through the normal CVE process. The only other bits in there are wall time and utsname, so systems with no CMOS clock would behave repeatably. Can we find out what kernels are affected? We can but it will likely take a few weeks to get a good sampling. UUID is unique in the db so when someone checks in with the same UUID, the old one gets overwritten. I'll have to do regular copies of what the UUID holds over time. Smolt schedules a monthly check in which we literally just missed a few days ago. We seen a huge number of duplicates for certain values: >From Mike McGrath (added to Cc) Here's the top 5: 266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132 336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a 402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f 884 06e84493-e024-44b1-9b32-32d78af04039 931 e2b67e1d-e325-4740-b938-795addb45280 The left number is times this month someone has submitted a profile with that UUID. If we take the last one as an example has come from over 800 IP's in the last 20 days. It seems very unlikely that one person would find his way to 800 different IP's this month. Let me know if you'd like more. Any other details would be interesting. We'll be able to get lots of stuff. Here's a profile of whats currently in e2b67e1d-e325-4740-b938-795addb45280. u_u_id: e2b67e1d-e325-4740-b938-795addb45280 o_s: Fedora release 7.92 (Rawhide) platform: i686 bogomips: 3660.33 system_memory: 2025 system_swap: 964 vendor: Sony Corporation system: VGN-FE31Z C3LMPJWX cpu_vendor: GenuineIntel cpu_model: Intel(R) Core(TM)2 CPU T num_cp_us: 2 cpu_speed: 1833 language: en_US.UT default_runlevel: 5 kernel_version: 2.6.23.1-23.fc8 formfactor: laptop last_modified: 2007-10-02 04:22:42 rating: 3 selinux_enabled: 1 selinux_enforce: targeted I'll grab the suspect UUID profiles over time to see what we end up with. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Alan Cox wrote: Here's the top 5: 266 28caf2c3-9766-4fe1-9e4c-d6b0ba8a0132 336 810e7126-1c69-4aff-b8b1-9db0fa8aa15a 402 c8dbb9d3-a9bd-4ba6-b92e-4a294ba5a95f 884 06e84493-e024-44b1-9b32-32d78af04039 931 e2b67e1d-e325-4740-b938-795addb45280 The left number is times this month someone has submitted a profile with that UUID. If we take the last one as an example has come from over 800 IP's in the last 20 days. It seems very unlikely that one person would find his way to 800 different IP's this month. Let me know if you'd like more. Background - Smolt runs this during its install: /bin/cat /proc/sys/kernel/random/uuid > /etc/sysconfig/hw-uuid For most users this would be run by the RPM %post scripts during install from anaconda. For some reason there are some UUID's (like those listed above) that come up more often then it seems they should if they are truly random. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
