[PATCH 1/5] common: machine_id: support /chosen/barebox, machine-id-path override

[Ahmad Fatoum]

Hello Trent,

(Cc'ing mailing list)

On 28.06.21 21:50, Trent Piepho wrote:
> On Sun, Jun 27, 2021 at 11:41 PM Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>> The Kconfig option already warns that the current behavior of
>> machine_id_set_hashable() overriding previous calls can lead to the
>> machine-id changing over updates. We don't yet have this problem in
>> practice, because the only two upstream users are for bsec and ocotp,
>> which are efuse drivers for different SoCs. On the other hand, users
>> may want to get the unique ID from an EEPROM and with deep probe
>> support, the initcall ordering will be independent of the actual probe
>> order.
> 
> On a board I did before Barebox had machine-id support, we used two
> sources of serial number to generate the machine id.  One was the imx7
> unique id and the other was a serial number in a i2c security chip.
> 
> The imx id is predictable, so even hashed one can predict the
> machine-id exactly. 

We happen to have stm32mp1 twins with consecutive MAC addresses.
I compared their serial numbers and while they clearly didn't start
at zero, all bytes were the same, except for two nibbles that were
one apart. So yes, if the i.MX UID follows a similar scheme, you
may be able to guess the machine-id of other devices in the same
batch if you already have the machine-id of one of them.

> We didn't really like that, so we combined two
 sources.

Is your issue one of privacy or security?

My understanding is that the machine id is not disclosed as matter
of privacy, so it's harder to track a device by manner of the unique
IDs embedded in its outgoing communication.

> It seems like there is no way to do that with this design?

You can write a driver that collects multiple sources and offers
a single NVMEM cell for consumption.

> I think it could be done if there was a function to add hash input,
> which board code could call.  Keep the pools separate and have a
> defined order.  I.e., /chosen/barebox,machine-id is first, then
> machine_id_add_hashable() is next.

If we restrict the new machine_id_add_hashable() for board use that
would work, yes. I don't like it from a design perspective though:
A user would expect a machine-id-path property to point at all info
used for determining the machine-id, not some of them.

> Or /chosen/barebox,machine-id could be a _list_ of paths, to be used
> in order.  But that requires a nvmem driver for each source. 

That's fine by me and could be added in future. I can add a property
size check, so we leave open this avenue without breaking users.

The root device tree node already has a device in barebox, so board
could use that to offer custom info.

> The security chip wouldn't have worked for a nvmem driver.

Why not? Check out nvmem-rmem with just exports a memory region
as read-only nvmem device. You can do likewise. There are also
helpers to get a nvmem device out of a (i2c) regmap.

> I'll also point out that just hashing the data is not a good idea to
> make a UUID.  Anyone who hashes the imx unique id will get the exact
> same UUID.  So it is not very universally unique!

The i.MX unique ID is unique across i.MX processors. Yes, it would
collide with an attacker that guess the ID, but is that really
a threat? Anyhow, there are boards using it like this already in the
field. So this won't change, but for the new binding introduced here,
I can address issues that are raised.
> Also consider if I give every board a unique sequential serial number
> from eeprom and use that.  Then someone else makes a completely
> different board and they also use sequential serial numbers unique for
> their boards.  But our serial numbers are the same as theirs, so we
> have a UUID collision.
> 
> This is already a known issue when generating UUIDs that are not
> purely random.  See RFC4122 §4.3 for generating UUIDs in a namespace.
> This is what I used.  The namespace would be barebox + board type, so
> that unique UUIDs are created when different types of boards use the
> same serial number and also "barebox", so when a single board creates
> different UUIDs for different reasons but they are all based on the
> serial number they UUIDs also still unique
Users can do that, barebox will hashh it to get the format the OS expects.
It's probably a good idea to hint at RFC4122 for users interested in
generating their own material for use with the machine-id.

Cheers,
Ahmad


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |