Skip to content

Dasharo Openness Score

This document aims to compare the openness of Dasharo firmware and AMI BIOS for MSI PRO Z690-A DDR4 WiFI.

There is an ongoing discussion about the methodology of the openness metric.

BIOS versions used in the analysis

MSI original BIOS from AMI

In the case of the AMI BIOS, the entire image should be considered proprietary. There are several parts of the image that have a well-known structure or make use of a public standard. However, to decode these structures, one needs to employ reverse-engineering tools and techniques to know what structures are present. For simplicity we treat UEFI variables as BIOS data. All empty padding regions between FFS and all volume free spaces are treated as unused space.

Dasharo BIOS

CBFS regions

The below table shows only a single FMAP region COREBOOT. There are also two RW vboot partitions containing copies of the same components from COREBOOT region (except the verstage, bootblock and cbfs master header). Note that there are other regions to store non-volatile data like MRC cache, UEFI variables or vboot state backup.

Region COREBOOT:

File Size (bytes) Is it open-source?
cbfs master header 32
fallback/romstage 95152
cpu_microcode_blob.bin 944144
intel_fit 80
fallback/ramstage 127231(LZMA)
config 1378
revision 842
build_info 142
fallback/dsdt.aml 9973
vbt.bin 1254 (LZMA)
(empty) 2596 N/A
fspm.bin 720896
fsps.bin 290481 (LZ4)
fallback/postcar 37504
fallback/payload 1813047 (LZMA) ✔ (with exceptions)
fallback/verstage 77008
(empty) 1055076 N/A
bootblock 31808

The payload used is Tianocore EDK2 UEFIPayload. In order to support network boot over i225 Ethernet, an i225 EFI driver is included in the payload. The driver is 154064 bytes in size uncompressed (63445 LZMA compressed). The 63445 bytes will be added to closed source pool and removed from the payload size in the calculations.

Note that UEFIPayload has support for Option ROM loading, for example to support external graphics card output during POST. It is an additional closed-source code which depends on the hardware configuration and is not included in the calculations.

Type Total size (bytes) Percent
COREBOOT region 5208644 N/A
empty 1057672 N/A
code size (open + closed) 4150972 N/A
open-source 2132006 51.36%
closed-source 2018966 48.64%

Region FW_MAIN_A/FW_MAIN_B:

File Size (bytes) Is it open-source?
fallback/romstage 95152
cpu_microcode_blob.bin 944144
fallback/ramstage 127231(LZMA)
config 1378
revision 842
build_info 142
fallback/dsdt.aml 9973
(empty) 100 N/A
fspm.bin 720896
fsps.bin 290481 (LZ4)
vbt.bin 1254 (LZMA)
fallback/postcar 37504
fallback/payload 1813047 (LZMA) ✔ (with exceptions)
(empty) 1306724 N/A

The FW_MAIN_A/FW_MAIN_B regions have been expanded first with CBFStool to show whole empty space for given region.

Type Total size (bytes) Percent
FW_MAIN_A/B region 5340928 N/A
empty 1306824 N/A
code size (open + closed) 4042044 N/A
open-source 2023078 50.05%
closed-source 2018966 49.95%

COREBOOT has slightly higher open-source code percentage due to verstage and bootblock not being present in FW_MAIN_A/B regions. Summary for all 3 regions:

Whole flash image

To get the overall BIOS region and full image percentage of open source code we ignore unused space or FMAP regions which do not have CBFS and are merely data generated during build process or boot process. The BIOS region percentage is calculated as follows:

(COREBOOT region open-source size + FW_MAIN_A/B open-source size * 2) * 100 divided by (COREBOOT region code size + FW_MAIN_A/B code size * 2).

Full image code only percentage is calculated as follows:

(COREBOOT region open-source size + FW_MAIN_A/B open-source size * 2) * 100 divided by (ME + descriptor + COREBOOT region code size + FW_MAIN_A/B code size * 2).

Region Size (bytes) Open-source percent (bytes)
descriptor 0x1000 0%
ME 0x3D9000 0%
unused hole 0xC26000 N/A
BIOS 0x1000000 50.5%
Summary 0x2000000 38%

Comparison of pure code open-source vs closed-source.

This was rather expected result.

AMI BIOS region statistics:

Type Total size (bytes) Percent
BIOS data (UEFI var) 524288 N/A
empty 7638472 N/A
code size (open + closed) 8614456 N/A
open-source 0 0%
closed-source 8614456 100%

Full BIOS region openness compared to AMI BIOS with data and free space:

That mean

Full image openness code only compared to AMI BIOS:

Few conclusions from the above charts:

  • Dasharo needs more space for BIOS data, it is mainly dictated by the usage of vboot which needs a significant amount of space for VBLOCKs, GBB and other stuff
  • BIOS data is rather comparable between the firmware distributions, although it must be noted that vboot also generates BIOS data as explained above
  • Dasharo has much less free space than AMI, however it must be noted that Dasharo contains 3! copies of functional firmware, but AMI only a single copy. Without vboot, BIOS region free space would reach over 70%!
  • While BIOS region's Dasharo Openness Score is 50%, when compared with Intel ME and descriptor, the overall Dasharo Openness Score is 38%
  • ME share is different because the size of BIOS code is different on both distributions

Summary

Image Open-source percent (bytes)
AMI BIOS 0%
Dasharo 38%

Dasharo code takes approximately 4MB of space for a single region + some space for data which is less than 1MB. This reduces the single copy of firmware from 8MB to roughly 4MB compared to AMI BIOS. This is roughly 50% reduction of TCB! More over, given the 50% share in size of open-source code, Dasharo liberates BIOS in 75%!

Few conclusions:

  • Although the reduction of TCB is 50% it cannot be seen on the charts due to 3 copies of the firmware in Dasharo image. It also effectively increases the percentage of BIOS code both open and closed source in the full image.
  • More significant differences would be seen with vboot disabled, there would be more free space and even less BIOS code both open and closed