[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] esx: Use MD5 sum of mount path as storage pool UUID

On Thu, Aug 12, 2010 at 01:40:14AM +0200, Matthias Bolte wrote:
> 2010/8/9 Justin Clift <jclift redhat com>:
> > On 08/09/2010 06:56 AM, Matthias Bolte wrote:
> >>
> >> With the previous storage pool UUID source not all storage pools
> >> had a proper UUID, especially GSX storage pools. The mount path
> >> is unique per host and cannot change during the lifetime of the
> >> datastore. Therefore, its MD5 sum can be used as UUID.
> >>
> >> Use gnulib's crypto/md5 module to generate the MD5 sum.
> >
> > Just as a general thought, would it be preferably to use the SHA1 function
> > instead of the MD5 one?
> Every non-trivial hash function will do for the purpose of deriving a
> UUID from the mount path.
> > Asking because MD5 seems to be trending "out of favour" (as a
> > generalisation) compared to SHA1, after some cryptographers showed MD5 hash
> > collisions could be practically achieved with some types of data. (or
> > something along those lines)
> I'm aware of MD5 being considered as broken for cryptographic use
> cases, but this one isn't cryptographic so I don't care about the
> problem of crafted collisions here. The only real problem here would
> be when you have two datastores with different mount paths that hash
> to the same UUID, but I think md5 is collision-free enough so we can
> ignore this problem.
> There is another "problem" with the approach of using the mount path
> hash as UUID. In case of a Windows based GSX server you can use CIFS
> shares as datastores addressed via UNC paths like \\nas\share. If you
> have multiple GSX server sharing that datastore then all will have the
> same UUID because the have the same mount path. Actually I don't
> consider this as a real problem because in this case there is one
> datastore with one UUID shared between multiple hosts.

This is actually a feature! If the same storage pool is visible on
multiple hosts, it is absolutely desirable that it have the same
UUID on each host.

> > For all intents and purposes, I'm thinking it'll make no practical
> > functional difference, but figure it's worth asking. :)
> >
> gnulib also provides SHA1 and SHA256 so we could use those instead of
> MD5, but I think MD5 is good enough for this special use case here.

Agreed, we don't need cryptographic security for this use case, so MD5
is fine.

|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]