4:31 a.m.
I just submitted my profile a few days ago and immediately tried to
retrieve it and got some other machine that didn't match my config. So
I submitted it again and things looked a bit more reasonable. Today I
checked it again and the vast majority of it has changed.
So there is some massive database corruption going on AFAICT. Did I
miss a message somewhere indicating this?
ref my machine:
http://smolt.fedoraproject.org/show?UUID=c8dbb9d3-a9bd-4ba6-b92e-4a294ba5...
/Mike
10:13 p.m.
On Monday 19 November 2007, Michael Wiktowy wrote:
I just submitted my profile a few days ago and immediately tried to
retrieve it and got some other machine that didn't match my config. So
I submitted it again and things looked a bit more reasonable. Today I
checked it again and the vast majority of it has changed.
So there is some massive database corruption going on AFAICT. Did I
miss a message somewhere indicating this?
I noticed something similar many months ago, where my machine's entry didn't
even have the right architecture. As I recall, I emailed the Smolt
maintainer, and he said it was probably a problem with the client-side UUID
generation not being random enough. As a result, multiple machines could
get the same UUID and so write to the same server database entry. That's
the last I heard about it.
David
10:32 p.m.
On Nov 19, 2007 11:13 PM, David Kewley <kewley(a)gps.caltech.edu> wrote:
I noticed something similar many months ago, where my machine's
entry didn't
even have the right architecture. As I recall, I emailed the Smolt
maintainer, and he said it was probably a problem with the client-side UUID
generation not being random enough. As a result, multiple machines could
get the same UUID and so write to the same server database entry. That's
the last I heard about it.
That is in fact a possibility. It uses the output from
/proc/sys/kernel/random/uuid to work. Is there a flaw with this
method that we know nothing about? Should we use another?
-Yaakov
10:47 p.m.
Yaakov Nemoy wrote:
On Nov 19, 2007 11:13 PM, David Kewley <kewley(a)gps.caltech.edu>
wrote:
> I noticed something similar many months ago, where my machine's entry didn't
> even have the right architecture. As I recall, I emailed the Smolt
> maintainer, and he said it was probably a problem with the client-side UUID
> generation not being random enough. As a result, multiple machines could
> get the same UUID and so write to the same server database entry. That's
> the last I heard about it.
>
That is in fact a possibility. It uses the output from
/proc/sys/kernel/random/uuid to work. Is there a flaw with this
method that we know nothing about? Should we use another?
Its funny (not that I'm laughing) but there seems to be a handful of
UUID's that come up more often then others. two or three of them quite
a bit more often. It might be worth it to black list those UUID's and
have the client re-generate if one of those UUID's comes up. If there
is a problem with /proc/sys/kernel/random/uuid not being random enough
though this might not actually correct anything. Can anyone confirm?
-Mike
5:52 a.m.
On Mon, Nov 19, 2007 at 11:32:03PM -0500, Yaakov Nemoy wrote:
That is in fact a possibility. It uses the output from
/proc/sys/kernel/random/uuid to work. Is there a flaw with this
method that we know nothing about? Should we use another?
Well libuuid is the other alternative. I'm a bit concerned about reports
the kernel uuid generator isn't as random as it should be. I'd like to know
more - such as what uuids come up a lot and chase that further.
Alan
7:36 a.m.
On 11/20/2007 12:52 PM, Alan Cox wrote:
On Mon, Nov 19, 2007 at 11:32:03PM -0500, Yaakov Nemoy wrote:
> That is in fact a possibility. It uses the output from
> /proc/sys/kernel/random/uuid to work. Is there a flaw with this
> method that we know nothing about? Should we use another?
Well libuuid is the other alternative. I'm a bit concerned about reports
the kernel uuid generator isn't as random as it should be. I'd like to know
more - such as what uuids come up a lot and chase that further.
I agree we should track this down in the kernel. But even so, it is
theoretically possible for the same UUID to come up multiple times.
Shouldn't we be generating UUIDs on the smolt server itself and letting
the client know what the UUID is, to better protect against duplicates?
12:45 p.m.
On 11/20/07, Christopher Aillon <caillon(a)redhat.com> wrote:
I agree we should track this down in the kernel. But even so, it is
theoretically possible for the same UUID to come up multiple times.
Shouldn't we be generating UUIDs on the smolt server itself and letting
the client know what the UUID is, to better protect against duplicates?
I would rather have proper UUID generation. Such a feature, while
technically more correct, would be slightly harder to make sure the
server can handle both the old and new method.
Besides, if we focus our efforts on proper UUID generation, then other
projects will benefit as well.
-Yaakov
2:56 p.m.
On Tue, 2007-11-20 at 13:45 -0500, Yaakov Nemoy wrote:
On 11/20/07, Christopher Aillon <caillon(a)redhat.com> wrote:
> I agree we should track this down in the kernel. But even so, it is
> theoretically possible for the same UUID to come up multiple times.
> Shouldn't we be generating UUIDs on the smolt server itself and letting
> the client know what the UUID is, to better protect against duplicates?
I would rather have proper UUID generation. Such a feature, while
technically more correct, would be slightly harder to make sure the
server can handle both the old and new method.
Besides, if we focus our efforts on proper UUID generation, then other
projects will benefit as well.
But in smolt we also track what versions of kernel do people use. Or we
don't want to track installations with older kernels?
--
Lubomir Kundrak (Red Hat Security Response Team)
1:25 p.m.
Alan Cox wrote:
On Mon, Nov 19, 2007 at 11:32:03PM -0500, Yaakov Nemoy wrote:
> That is in fact a possibility. It uses the output from
> /proc/sys/kernel/random/uuid to work. Is there a flaw with this
> method that we know nothing about? Should we use another?
>
Well libuuid is the other alternative. I'm a bit concerned about reports
the kernel uuid generator isn't as random as it should be. I'd like to know
more - such as what uuids come up a lot and chase that further.
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.
-Mike
3:04 p.m.
On Tue, Nov 20, 2007 at 01:25:47PM -0600, Mike McGrath 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.
We shouldn't have any duplicates if its properly random. I don't know how
relevant the actual values are myself because random numbers is "hard maths"
and I'm not a mathematician. I've raised it however but since its turkey
genoiciding season in the USA it might be a bit slow
4:20 p.m.
On Tue, 2007-11-20 at 16:04 -0500, Alan Cox wrote:
On Tue, Nov 20, 2007 at 01:25:47PM -0600, Mike McGrath 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.
We shouldn't have any duplicates if its properly random. I don't know how
relevant the actual values are myself because random numbers is "hard maths"
and I'm not a mathematician. I've raised it however but since its turkey
genoiciding season in the USA it might be a bit slow
Is rfc4122 being used ?
http://www.ietf.org/rfc/rfc4122.txt
--
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |
4:35 p.m.
On Tue, Nov 20, 2007 at 10:20:17PM +0000, Simo Sorce wrote:
Is rfc4122 being used ?
http://www.ietf.org/rfc/rfc4122.txt
Yes - for randomly generated.
10:50 p.m.
On Tue, 2007-11-20 at 16:04 -0500, Alan Cox wrote:
On Tue, Nov 20, 2007 at 01:25:47PM -0600, Mike McGrath 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.
We shouldn't have any duplicates if its properly random. I don't know how
relevant the actual values are myself because random numbers is "hard maths"
and I'm not a mathematician. I've raised it however but since its turkey
genoiciding season in the USA it might be a bit slow
(I'm a pescetarian FWIW, and didn't butcher any Turkeys)
Was there any outcome on this in the end?
My initial guesses include that there's some hardware device common to
some of these reports that is inappropriately registering as a source of
random entropy, and then generating very predictable data. That would be
a somewhat serious kernel bug that I want to check for.
Any news? Alan - whatcha wanna do?
Jon.
6:05 a.m.
On Tue, Dec 04, 2007 at 11:50:50PM -0500, Jon Masters wrote:
> and I'm not a mathematician. I've raised it however but
since its turkey
> genoiciding season in the USA it might be a bit slow
(I'm a pescetarian FWIW, and didn't butcher any Turkeys)
Sounds fishy to me.
Was there any outcome on this in the end?
Just been resurrected on l/k
8:09 a.m.
On Wed, 2007-12-05 at 07:05 -0500, Alan Cox wrote:
On Tue, Dec 04, 2007 at 11:50:50PM -0500, Jon Masters wrote:
> > and I'm not a mathematician. I've raised it however but since its
turkey
> > genoiciding season in the USA it might be a bit slow
>
> (I'm a pescetarian FWIW, and didn't butcher any Turkeys)
Sounds fishy to me.
I fed you a line, knew you'd bite.
> Was there any outcome on this in the end?
Just been resurrected on l/k
Right. That was why I asked - I saw the thread, but it doesn't seem to
have gone anywhere yet. I guess the kernel should not be returning UUIDs
at all until there's sufficient entropy to do so. I'll ponder it.
Jon.
8:25 a.m.
Jon Masters wrote:
On Wed, 2007-12-05 at 07:05 -0500, Alan Cox wrote:
> On Tue, Dec 04, 2007 at 11:50:50PM -0500, Jon Masters wrote:
>
>>> and I'm not a mathematician. I've raised it however but since its
turkey
>>> genoiciding season in the USA it might be a bit slow
>>>
>> (I'm a pescetarian FWIW, and didn't butcher any Turkeys)
>>
> Sounds fishy to me.
>
I fed you a line, knew you'd bite.
>> Was there any outcome on this in the end?
>>
> Just been resurrected on l/k
>
Right. That was why I asked - I saw the thread, but it doesn't seem to
have gone anywhere yet. I guess the kernel should not be returning UUIDs
at all until there's sufficient entropy to do so. I'll ponder it.
Long story short. There doesn't seem to be any problem with the way the
kernel generates UUID's. It has to do with how smolt RPM installs and
how the LiveCD is made (all live cd people end up with the same UUID /
arch, etc)
-Mike
8:44 a.m.
On Wed, Dec 05, 2007 at 09:09:31AM -0500, Jon Masters wrote:
> > (I'm a pescetarian FWIW, and didn't butcher any
Turkeys)
> Sounds fishy to me.
I fed you a line, knew you'd bite.
It had a barb on it and I fancied a snipe. I shad have known better.
I hake to carry this on but I thougt I cod catch you floundering on your perch.
We betta move on. Eel be time to skate back to my plaice. Sole long..
You mean piscivore anyway, 'pescetarian' is just a new 'gotta be
different'
word made up by people who didn't know the dictionary had a word for it already
and had for hundreds of years
> > Was there any outcome on this in the end?
>
> Just been resurrected on l/k
Right. That was why I asked - I saw the thread, but it doesn't seem to
have gone anywhere yet. I guess the kernel should not be returning UUIDs
at all until there's sufficient entropy to do so. I'll ponder it.
Possibly. That still doesn't help us in our quest for unique system identifiers
however. If we simply don't have enough entropy then we may need to mix in
system specific bits but properly one way hashed (eg disc serial numbers)
Alan
9:26 a.m.
Once upon a time, Alan Cox <alan(a)redhat.com> said:
Possibly. That still doesn't help us in our quest for unique
system identifiers
however. If we simply don't have enough entropy then we may need to mix in
system specific bits but properly one way hashed (eg disc serial numbers)
I would think a good list of things to include would be:
- lspci -v
will not only list the PCI cards but includes which slot they are in
- lsusb -v (although I don't think usbutils is installed by default)
includes things like firmware version for some devices and again using
a different port will give different results
- dmidecode
sometimes includes serial numbers, also can vary based on which slot
things are in
- ifconfig -a
includes MAC addresses
- smartctl -a [each hard drive]
depending on drive, includes serial number, temperature, power-on time
and count, random variables only the drive make understands
There is enough system-specific stuff in those to get pretty random
(once hashed).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:04 p.m.
On Tue, 20 Nov 2007, Mike McGrath wrote:
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.
I've got a WRT54GL running OpenWRT on a DSL line with PPPoE auth, and it
appears to hop IPs as many as 3-4 times a day. Alas, that only gets up to
about 90 IPs a month at most. (So far this month, it's changed 49 times.
Geez.) So while not the extreme number you speak of, it is a little
ridiculous. :-)
Jima
1:06 p.m.
At 11:32 PM -0500 11/19/07, Yaakov Nemoy wrote:
On Nov 19, 2007 11:13 PM, David Kewley <kewley(a)gps.caltech.edu>
wrote:
> I noticed something similar many months ago, where my machine's entry didn't
> even have the right architecture. As I recall, I emailed the Smolt
> maintainer, and he said it was probably a problem with the client-side UUID
> generation not being random enough. As a result, multiple machines could
> get the same UUID and so write to the same server database entry. That's
> the last I heard about it.
That is in fact a possibility. It uses the output from
/proc/sys/kernel/random/uuid to work. Is there a flaw with this
method that we know nothing about? Should we use another?
I don't /know/ anything about this, but if the UUID is generated early on,
there may not have been much entropy made yet. I see that /dev/random
blocks until it thinks it has enough entropy, while /dev/urandome does not,
but I don't know what /proc/sys/kernel/random/* does, though
/proc/sys/kernel/random/entropy_avail should be informative. `while : ; do
cat /proc/sys/kernel/random/{uuid,entropy_avail} ; done` depletes
entropy_avail of about 256 bits each time, but it never gets to 0, and a
uuid is always returned. This might be bad, or it might represent
obtaining enough entropy before returning. I can check harder (measure
times, look for dups) on request.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
5986
days inactive
6002
days old
19 comments
12 participants
participants (12)
-
Alan Cox -
Chris Adams -
Christopher Aillon -
David Kewley -
Jima -
Jon Masters -
Lubomir Kundrak -
Michael Wiktowy -
Mike McGrath -
Simo Sorce -
Tony Nelson -
Yaakov Nemoy