Surface Laptop 4 Intel firmware version mismatch

[Tyler-2]

trafficstars

I downloaded https://download.microsoft.com/download/f/7/0/f70b3d0a-59b1-4842-9130-0c152bb738ba/SurfaceLaptop4_Win10_18363_21.062.24023.0.msi and it seems like the versioning of the detected current versions and the downloaded versions is giving two incompatible numbers:

tyler@func-platform:~/Downloads/surface-uefi-firmware$ fwupdmgr install out/SurfaceLaptop4/SurfaceLaptop4_surfacekip_20.5.139.0.cab 
Decompressing…           [***************************************]
Specified firmware is older than installed '20.0.1419 < 335545739'
tyler@func-platform:~/Downloads/surface-uefi-firmware$ fwupdmgr install out/SurfaceLaptop4/SurfaceLaptop4_surfaceme_15.0.1680.1.cab 
Decompressing…           [***************************************]
Specified firmware is older than installed '240.6.36865 < 4026902276'
tyler@func-platform:~/Downloads/surface-uefi-firmware$ fwupdmgr install out/SurfaceLaptop4/SurfaceLaptop4_surfaceuefi_10.7.141.0.cab 
Decompressing…           [***************************************]
Specified firmware is older than installed '10.0.1933 < 167773325'

[Tyler-2]

I don't know if this is a problem with fwupdmgr or something with how the scripts are tagging the files with metadata. But fwupdmgr seems to use these int based versions numbers:

└─UEFI Device Firmware:
      Device ID:          c13894911da7556177c38756ef5bea60e7d59e8d
      Current version:    117466251
      Vendor:             DMI:Microsoft Corporation
      GUIDs:              a1d95185-351e-4ba3-831d-7f6058084995
                          44821a4d-837e-519c-bf4b-56946b129097
      Device Flags:       • Internal device
                          • Updatable
                          • System requires external power source
                          • Needs a reboot after installation
                          • Device is usable for the duration of the update

[qzed]

I think it should in theory support Surface version numbers (see e.g. here) but not sure why that doesn't work here. Just checked and it's the same on my device.

Also it kinda looks like it's not just fwupd screwing up version numbers, it's also the script. 20.0.1419 should not be a valid version number, at least with the 8/16/8 scheme.

In case of the first firmware:

• 335545739 should be 20.5.139 (following the 8/16/8 bit scheme).
• 20.0.1419 decoded as 8/8/16 would also line up with 20.5.139 as 8/16/8. Which perfectly matches the file name.

So I guess there's one bug in our script (or is this an issue somewhere else?) but also some issue with fwupd. The same versioning issue fits the UEFI firmware. I have no idea how the ME firmware version (according to file name) is encoded, however. That seems to be different (probably some MS vs Intel scheme).

Cc @StollD

[qzed]

FWIW there is an option to ignore version checks: --allow-older.

[StollD]

fwupd uses the triplet version style by default (https://fwupd.org/lvfs/docs/metainfo/version), which is 8/8/16.

The surface version number format wouldnt help a lot because the version numbers that Microsoft puts into the "marketing", and the one that they write into the UEFI have been different in the past. fwup goes off the number in the UEFI, so we have to do that too. In the .inf file that number is stored as a single hexadecimal integer. We can convert that into every format we want, so I just went with the default.

But now comes the best part: Microsoft likes to randomly lower that number in their updates. Windows Update can handle it, but fwupd can't.

So my suggestion would be: Forget the version numbers. If you are sure the UEFI you want to flash is newer than the one you have, force the update with --allow-older.

[qzed]

But now comes the best part: Microsoft likes to randomly lower that number in their updates. Windows Update can handle it, but fwupd can't.

Argh, now that's just wonderful...