system76 / firmware-open

System76 Open Firmware
Other
944 stars 84 forks source link

Populate SMBIOS serial number #432

Open MilesBHuff opened 1 year ago

MilesBHuff commented 1 year ago

dmidecode -t system has many missing fields; example:

# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
        Manufacturer: System76
        Product Name: Oryx Pro
        Version: oryp7
        Serial Number: 123456789
        UUID: Not Settable
        Wake-up Type: Reserved
        SKU Number: Not Specified
        Family: Not Specified

Handle 0x000D, DMI type 32, 11 bytes
System Boot Information
        Status: No errors detected

As you can see above, the "Serial Number", "UUID", "SKU Number", and "Family" are undefined.


The serial number is actually used by KDE in the "About this System" menu: image I would like to have my BIOS report the correct serial number so that, in the future, I can get that serial number from KDE instead of by turning the laptop upside down.


I posted about this first on Reddit; the contents of that post are copied below:

dmidecode -t system returns a serial number of "123456789". How can I change this to be my *actual* serial number?

Related: The "SKU Number" is "Not Specified", the "Family" is "Not Specified", and the UUID is "Not Settable".

I know none of these settings really impact day-to-day usage, but KDE's SystemSettings5 has a place where you can view your serial number, and I'd like for mine to display correctly there. It would be nice to have, so that I could copy/paste it for support tickets.

https://www.reddit.com/r/System76/comments/14h8bva/bios_has_fake_default_serial_number


One commenter mentioned that it's because System76 has not yet implemented reading from a "CBFS" file. I didn't see an issue about this exactly, so I am creating one here to track the issue.

They're hard-coded values in coreboot. You will need to recompile the firmware to change them. See: src/arch/x86/smbios{,_defaults}.c.

There's a config to read the UUID from a CBFS file, but we don't use it.

https://www.reddit.com/r/System76/comments/14h8bva/comment/jpfhvfw/?utm_source=share&utm_medium=web2x&context=3


Related: https://github.com/system76/firmware-open/issues/268

crawfxrd commented 1 year ago

Do you actually need any of them?

I'm not sure how much of this is feasible with coreboot, which has mostly static data determined at build time. I'd expect it to require some substantial changes to how we build and flash firmware.

MilesBHuff commented 1 year ago

The only one I'm particularly interested in is the Serial Number, since it's nice to have it there and ready to be copied/pasted when I (and other customers) need support.

268 says that the UUID is important for Vanta/osquery, which is apparently critical for some corporate environments? I'm not familiar with it, myself.

SKU Number seems like it's only something that would be useful for y'all, System76.

I don't know what Family is.

Reddit says it's possible to read the UUID from a CBFS file, whatever that is; but also that System76's Coreboot doesn't currently support this.

crawfxrd commented 1 year ago

DRIVERS_GENERIC_CBFS_UUID. It's specifically for providing Type 1 UUID (/sys/class/dmi/id/product_uuid). Using it would require changing how we do the initial flash and upgrades with tooling to copy the CBFS file or generate it if it doesn't exist.

A similar change would be required for setting the serial number.

These fields are described in: SMBIOS 3.6.0, 7.2 System Information (Type 1)

crawfxrd commented 1 year ago

It looks like there is already DRIVERS_GENERIC_CBFS_SERIAL for setting the serial number.

Ref: https://doc.coreboot.org/drivers/cbfs_smbios.html

crawfxrd commented 1 year ago

Since UUID already has an issue, I've changed this one to be for just the serial number.

Type 2 "Asset Tag" would probably be the next most useful field.

kb2ma commented 1 month ago

I need to use Cloudflare Zero Trust. Its WARP client uses dmidecode to read the serial number, as documented here.