fiano
fiano copied to clipboard
linuxboot
UTK does not display deeper than the top most layer
I suspect it is supposed to show a deeper nested table but utk does only detect the top most layer on some images. See attached output table / json vs the UEFITool output.
github.com/linuxboot/fiano v5.0.1-0.20191025053120-41ac08f71926+incompatible
mimoja@Mimoja-FirmwareVM:~/Projects/Firmware/MFT/files$ utk AB5C8F19220DF31B1B0A5C5A26914530A44FC3822C0F4B92EAEBC8EC1FC1B758 table
Node GUID/Name Type Size
BIOS 0x2c0000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x230000
Free 0x0
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x40000
Free 0x0
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x30000
Free 0x0
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x20000
Free 0x0
mimoja@Mimoja-FirmwareVM:~/Projects/Firmware/MFT/files$ utk AB5C8F19220DF31B1B0A5C5A26914530A44FC3822C0F4B92EAEBC8EC1FC1B758 layout-table
Node GUID/Name Offset Size
BIOS 0x00000000 0x002c0000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x00000000 0x00230000
Free 0x00230000 0x00000000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x00230000 0x00040000
Free 0x00270000 0x00000000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x00270000 0x00030000
Free 0x002a0000 0x00000000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x002a0000 0x00020000
Free 0x002c0000 0x00000000
mimoja@Mimoja-FirmwareVM:~/Projects/Firmware/MFT/files$ utk AB5C8F19220DF31B1B0A5C5A26914530A44FC3822C0F4B92EAEBC8EC1FC1B758 layout-table-full
Node GUID/Name Offset Size
BIOS 0x00000000 0x002c0000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x00000000 0x00230000
Free 0x00230000 0x00000000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x00230000 0x00040000
Free 0x00270000 0x00000000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x00270000 0x00030000
Free 0x002a0000 0x00000000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x002a0000 0x00020000
Free 0x002c0000 0x00000000
{
"Elements": [
{
"Type": "*uefi.FirmwareVolume",
"Value": {
"FileSystemGUID": {
"GUID": "7A9354D9-0468-444A-81CE-0BF617D890DF"
},
"Length": 2293760,
"Signature": 1213613663,
"Attributes": 4294938367,
"HeaderLen": 72,
"Checksum": 19565,
"ExtHeaderOffset": 0,
"Revision": 1,
"Blocks": [
{
"Count": 35,
"Size": 65536
}
],
"FVName": {
"GUID": "00000000-0000-0000-0000-000000000000"
},
"ExtHeaderSize": 0,
"DataOffset": 72,
"FVOffset": 0,
"ExtractPath": "",
"Resizable": false
}
},
{
"Type": "*uefi.FirmwareVolume",
"Value": {
"FileSystemGUID": {
"GUID": "7A9354D9-0468-444A-81CE-0BF617D890DF"
},
"Length": 262144,
"Signature": 1213613663,
"Attributes": 4294938367,
"HeaderLen": 72,
"Checksum": 19627,
"ExtHeaderOffset": 0,
"Revision": 1,
"Blocks": [
{
"Count": 4,
"Size": 65536
}
],
"FVName": {
"GUID": "00000000-0000-0000-0000-000000000000"
},
"ExtHeaderSize": 0,
"DataOffset": 72,
"FVOffset": 2293760,
"ExtractPath": "",
"Resizable": false
}
},
{
"Type": "*uefi.FirmwareVolume",
"Value": {
"FileSystemGUID": {
"GUID": "7A9354D9-0468-444A-81CE-0BF617D890DF"
},
"Length": 196608,
"Signature": 1213613663,
"Attributes": 4294938367,
"HeaderLen": 72,
"Checksum": 19629,
"ExtHeaderOffset": 0,
"Revision": 1,
"Blocks": [
{
"Count": 3,
"Size": 65536
}
],
"FVName": {
"GUID": "00000000-0000-0000-0000-000000000000"
},
"ExtHeaderSize": 0,
"DataOffset": 72,
"FVOffset": 2555904,
"ExtractPath": "",
"Resizable": false
}
},
{
"Type": "*uefi.FirmwareVolume",
"Value": {
"FileSystemGUID": {
"GUID": "7A9354D9-0468-444A-81CE-0BF617D890DF"
},
"Length": 131072,
"Signature": 1213613663,
"Attributes": 4294938367,
"HeaderLen": 72,
"Checksum": 19631,
"ExtHeaderOffset": 0,
"Revision": 1,
"Blocks": [
{
"Count": 2,
"Size": 65536
}
],
"FVName": {
"GUID": "00000000-0000-0000-0000-000000000000"
},
"ExtHeaderSize": 0,
"DataOffset": 72,
"FVOffset": 2752512,
"ExtractPath": "",
"Resizable": false
}
}
],
"ExtractPath": "",
"Length": 2883584,
"FRegion": null,
"RegionType": 0
}
The Image is from ACERs BIOS_Acer_2.05.0004_AW370hF2 update package, that can be found here: https://global-download.acer.com/GDFiles/BIOS/BIOS/BIOS_Acer_2.05.0004_A_A.zip?acerid=635785999202158977
The image use FFSv1 GUID for their firmware volume (even if UEFITool displays a FFSv2 Subtype).
Whitelisting the FFSv1 GUID in pkg/uefi/firmwarevolume.go supportedFVs does allows to go a little deaper (but I didn't check the differences between FFSv1 and v2 so this is a blind hack).
Then the 'Compressed section' shown by UEFITool in not decoded:
BIOS 0x2c0000
FV 7A9354D9-0468-444A-81CE-0BF617D890DF 0x230000
File AE717C2F-1A42-4F2B-8861-78B79CA07E07 EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x1eda02
Sec EFI_SECTION_COMPRESSION 0x1ed9ea
Free 0x425b0
...
Minor nitpick: there is no "FFSv1" concept in publicly-available EFI/UEFI images (v1 was replaced with v2 before Intel Framework specification was publicly released and EDK1 was open-sources). The proper term here is "FFSv2 Rev1" vs "FFSv2 Rev2". The first had some interesting quirks like tailed files, which the second later dropped.
For now we can surely use FFSv1 for those Framework/PI-before-1.0 volumes because real FFSv1 are most like Intel-internal only and are long forgotten. The GUID update and revision update were made in the same spec (PI 1.0), so it's probably better to call it FFSv1, especially with a presence of FFSv3 that differs from FFSv2 by GUID only (with revision staying 2).
Oh that's cool, so we can parse it similarly to FFSV2? Do you have some references regarding the tailed files/differences between the two revisions?
You can get the related definitions in EFI Platform Interface v0.9x here. Tail was a FFS file attribute indicating that the file has additional UINT16 after it's body that is a bitwise negation of it's checksums. Even modern EDK2 still has traces of it. UEFITool supports them too. Another visible difference between Rev1 and Rev2 is that a different default checksums are used:
// Standard data checksum, used if FFS_ATTRIB_CHECKSUM is clear
#define FFS_FIXED_CHECKSUM 0x5A
#define FFS_FIXED_CHECKSUM2 0xAA
Also, Rev1 volumes can't have extended headers (and, therefore, custom volume GUIDs), the ExtHeaderOffset field in the volume header is reserved.
Here's a sample file from Intel, it has everything that PI 0.9x is about:
- tons of Rev1 volumes
- tailed files
- custom compression specific for Intel (they added another 4 byte header before LZMA compressed data start)
However, I don't think there's much need in supporting such kind of files, as they are very rare in practice, so it's a nice-to-have.