23 червня 2023 р. 17:25:32 GMT+03:00, Thierry Reding thierry.reding@gmail.com написав(-ла):
On Fri, Jun 23, 2023 at 02:46:54PM +0300, Svyatoslav Ryhel wrote:
23 червня 2023 р. 14:24:37 GMT+03:00, Thierry Reding thierry.reding@gmail.com написав(-ла):
On Fri, Jun 23, 2023 at 08:55:56AM +0300, Svyatoslav Ryhel wrote:
This is a small tool for calculation of SoC UID based on the same Linux function. It can be further used for generation of device unique data like mac address or exposing it as serial number.
It's a very bad idea to use the SoC UID as a MAC address. There are better ways (such as MAC address randomization) to generate one if for some reason you don't have a real MAC address or are concerned about privacy.
SoC UID is not used directly as MAC but it is used as a device specific base to generate device specific one. You can check LG board to see what I mean.
Is this something that originates from the original vendor code? My primary concern is that this might end up reusing MAC addresses which were assigned to other devices.
No, but vendor code makes some magic inside the kernel, to avoid this in mainline linux, which is obviously not be accepted, I decided to generate mac in u-boot based on device specific data (soc id) and tweak linux dtb on load. It is not the ideal decision but so far it is the best I could make without messing stuff too much. If no bt mac is provided, bt will not work.
The SoC UID is also not very well suited as a serial number because it identifies only the SoC, but doesn't say anything about any of the other components of a device. Many devices have serial numbers in some EEPROM chip, so those would be more appropriate.
That is not the case of devices in patches and IIRC SoC UID is used as fastboot ID on transformers by vendor.
That doesn't really make this a better idea, but I also understand that your options are limited given the information you have.
Well, why not? SoC ID is not smth secret. Even linux kernel can expose it and vendor firmwares often display it. As far as I can tell, this is the only 100% valid thing which can determine device unlikely and has stable way of calculation.
I suppose not all devices have such a system-wide serial number, so perhaps there are cases where this would be better than nothing.
Vendors usually do not expose serial in any device hardware, or at least do not bother to inform, where to find it.
My experience differs. There's usually some serial number somewhere because vendors need some way of tracking these devices. But yeah, if you get an OEM device they typically don't tell you where to find it. One thing you might want to do is probe the various I2C busses to see if there's an EEPROM on any of them. They are often found at addresses 0x50-0x58 or so.
True, I have dug those extensively but nothing so far.
Again, I'm not strongly objecting to this, but I'd prefer some better way to identify system than by chip UID, because it's not meant for this purpose.
Well, maybe it is not meant for this purpose, but it is quite a nice fit.
Best regards, Svyatoslav R.
Thierry