sys/luid: improve luid_base() algorithm [backport 2020.10]#15243
sys/luid: improve luid_base() algorithm [backport 2020.10]#15243aabadie merged 1 commit intoRIOT-OS:2020.10-branchfrom
Conversation
|
I don't really like a backport for this but I see the reason why. I won't block it. Please rebase! |
5a4c0b2 to
92cb244
Compare
92cb244 to
a9c2650
Compare
maribu
left a comment
There was a problem hiding this comment.
ACK. L2 address generation still works also in the release branch.
a9c2650 to
801fa8c
Compare
maribu
left a comment
There was a problem hiding this comment.
ACK. (This time with the correct radio button being selected :-D)
|
@bergzand: You're fine with this going in? I would argue that poor distribution and high collision rate of luid is indeed a bug - after all it is used to generate L2 addresses in the hope that they practically never collide for small sized networks. But at least for testbeds, this hope was proven wrong. So I think we can argue this is a backport of a bugfix and does not violate the "no new feature" policy. |
801fa8c to
d9eb53c
Compare
The button was right the first time around, the problem is
Fortunately this GitHub magic is only enabled for the release branch |
I have some mixed feelings about this, but I'm fine with the backport here if you guys think it makes sense. |
|
Sorry @benpicco, you have to rebase this one again :) |
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. (cherry picked from commit 6fa15ff)
d9eb53c to
8c3b004
Compare
|
I really don't see how that manual rebasing is going to help with anything. |
aabadie
left a comment
There was a problem hiding this comment.
(Still the same changes)
Backport of #15239
LUID output already changed for this release due to #14986.
But this was an improper fix. To avoid changing LIUD output in the next release again, I propose we backport this patch.
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