sys/luid: improve luid_base() algorithm#15239
Conversation
7297616 to
39d53d2
Compare
39d53d2 to
d46a675
Compare
CPU IDs may contain very little entropy. Often only a single byte may change between two CPUs. To mitigate this use a somewhat 'proper' hash algorithm (I chose DJB2 hash simply because it's small) and 'extend' it to the required output size. For 50 STM32 CPU IDs from the grenoble site, this produces a much more random LUID output.
d46a675 to
6fa15ff
Compare
maribu
left a comment
There was a problem hiding this comment.
ACK. Using a well known and well tested hash algorithm is certainly better than something home grown.
|
Note that this will of course change the L2 addresses of nodes without EUI provider. This might upset some folks. IMO this is fine, as people requiring fixed L2 addresses really should add an EUI provider. But it would be good if we stop changing LUID generation with every release. |
|
I wonder if we should consider this an 2 ACK change because of the change of the L2 addresses. Maybe @aabadie could throw in a second ACK, just in case? I think the improved entropy in the LUIDs generated will be especially useful for testbeds. |
😅 I was wondering if we should backport this to keep the LUID changes confined to one release. (last change to LUID output was #14986) |
Strong 👍. @bergzand? If so, I think a single ACK would be sufficient, as a change in L2 address generation is imminent anyway in the upcoming release. |
Contribution description
CPU IDs may contain very little entropy. Often only a single byte may change between two CPUs.
To mitigate this use a somewhat 'proper' hash algorithm (I chose DJB2 hash simply because it's small) and 'extend' it to the required output size.
For 50 STM32 CPU IDs from the grenoble site, this produces a much more random LUID output.
Before especially the last bytes (used as short address) would often be the same for different nodes.
Testing procedure
For 50
iotlab-m3nodes, this generates much more evenly distributed (64 bit) LUIDs:source code
before
Issues/PRs references
fixes #15023 for real