Getting a product serial number in prepare-device for amd64 classic

A customer has an amd64 classic project whose gadget snap will use the Serial Vault.

We’d like the prepare-device hook to set a unique serial number [1] on each system (even if this is not currently an enforced requirement).

One method to obtain a unique serial number in the prepare-device hook may be:

   $ cat /sys/devices/virtual/dmi/id/product_serial

Does this require declaring a plug or will it just work (the gadget is strict confinement)? (I don’t have spare hw to test this on.)

Is this a recommended approach or is there something better?

[1] snapctl set registration.proposed-serial=UNIQUE

Yes, you would need a plug (hardware-observe might work by skimming what we have available),

are they flashing this at manufacturing? or is just “defaults” from the board they use? if they are flashing it it might be reasonable.

Also afaict that can in principle contain spaces or other special chars, that’s not a problem as such, but means one need to be careful with quoting for the snapctl command if the hook is a shell script.

Also if relevant ‘/’ cannot appear in a serial (or any other primary key of assertions).

hardware_observe does not auto connect. [1] We are using a brand store.

  1. Can they configure this to auto-connect in the brand store?

  2. Are there documented instructions for configuring a snap-declaration to auto-connect in a brand store?

  3. Not sure where the image is flashed. (Not sure why that matters.)

thanks!

[1] https://docs.snapcraft.io/reference/interfaces

no, I’m talking whether they flash the product_serial/dmi values? it’s a potentially bad idea to use something they don’t control. are we even sure it’s really unique?

No, not sure.

This is why the initial post included: “Is this a recommended approach or is there something better?”

I would like some help/recommendations for how customers can ensure they use unique serial numbers (because there has been consideration in the past and for the future of denying serial assertions for duplicate serial numbers).

1 Like

I don’t think there’s a general answer.

You need to ask what kind of customisation they do at manufacturing? do they set sane values for DMI/SMBIOS data? yes, no? have something else around?

If they do some sane customisation they probably want the snapd serial to match their notion of product serial.

Otherwise you can always generate a random serial otherwise.

ok, that seems reasonable. thanks!

Has there been any thought to a process to ensure and advise customers on the importance and how they should generate unique serial numbers for their devices? It seems to me that this could become a hairy mess for some customers, especially if they ever let certain devices sit on a shelf disconnected for a length period of time and then bring the device back online, potentially with a duplicate serial number to an existing device.

some points

  • I’m not sure why sitting on a shelf is relevant to this?
  • the serial needs to be unique only with brand/model, not globally
  • afaik the serial-vault makes an assumption that devices have a strong opinion about what their serial is, this means assuming that the brand through manufacturing sets that/makes it available on the device itself OTOH from snapd POV serial is not mandatory in a serial-request, a device can leave out setting proposed-serial
  • the serial-vault could also have a mode where if the device doesn’t specify one it generates a strong random one if the brand doesn’t care (which sound strange on the face of it but as everything it all depends)

I’m not sure why sitting on a shelf is relevant to this?

It’s just an example. Say a device were sitting on the shelf with a certain serial number. Because we haven’t really advised the customer on how they should go about coming up with serial numbers for their devices and the importance of each being unique to their context, it’s possible that they might give another device the same one as the device sitting on the shelf since they forgot about it for some reason. It’s just a hypothetical example, but it’s important not to do.

Another reason “sitting on a shelf” may matter is protecting today’s deployments from possible future requirements of serial number uniqueness.

The Serial Vault previously did enforce uniqueness (AIUI). This was turned off, but not definitively for all time (AIUI). If a device is sitting on a shelf today with a non-unique serial number, and later the Serial Vault turns on enforcement of uniqueness, that system will never obtain a serial assertion and will never be able to install from a secure brand store. Perhaps other currently unimagined software will (reasonably) assume that a serial number uniquely describes a device (isn’t that fundamental to the idea of a serial number?).

So today, we do not forcefully warn/advise: Ensure your serial numbers are unique! (within the project domain). I worry this can set up for problems later.

1 Like

where should we do that?

I can add some wording here Gadget snaps , don’t know if it’s enough/the most relevant place

1 Like

That’s a start and probably worth doing. Thanks for volunteering to do that Samuel.

1 Like

I added this there (Gadget snaps):

If the device service (typically the serial-vault) requires to set registration.proposed-serial to use as the “serial number” (a string, not necessarly a number) part of the identification, then this must be set to a value that is unique across all devices of the brand and model. This also cannot contain /.

Thanks Pedronis.

The serial vault as I understand it does not now require a unique serial number. It does issue a serial assertion with the revision incremented for duplicate serial numbers. But, the SV did at one time require serial number uniqueness. I suppose it might again someday require uniqueness (non-unique serial numbers does not make much sense on the face of it.)

So the above added text does yet not seem to me to give enough advice.

I’m probably not understanding which part of my addition is unclear/insufficient. My advice there is basically:

  1. if must set registration.proposed-serial (which ATM is alway the case with the serial vault)
  2. then must set to something unique

On reread, I see that you are saying set it uniquely. But this follows a complex “if”. It is not clear to me that users can answer the “if” very easily.

Can we not simply say something like: Ensure the serial number is unique across brand/model…

I tried to turn the sentence(s) around, hopefully it’s clearer:

One must ensure that registration.proposed-serial is set to a value unique across all devices of the brand and model and that it does not contain a /. It is going to be used as the “serial number” (a string, not necessarily a number) part of the identification in case the device service supports setting it or requires it, as is the case with the serial-vault.

1 Like