On Fri, Jun 23, 2023 at 02:46:54PM +0300, Svyatoslav Ryhel wrote:
> 
> 
> 23 червня 2023 р. 14:24:37 GMT+03:00, Thierry Reding 
> <thierry.red...@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.

> 
> >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.

> >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.

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.

Thierry

Attachment: signature.asc
Description: PGP signature

Reply via email to