Tool for measuring openness of Dasharo firmware image

[IgorBagnucki]

Measuring openness of Dasharo firmware image It would be useful to create a tool that would automatically create reports with percentage information, how open is given Dasharo firmware image. Such report would be usefull promotion, creating marketing materials and to help clients make informed decisions, to provide percentage values, in what percentage the firmware image is created using the open-source resources.

Tool for measuring Dasharo image openness The best solution would be an automated tool that can calculate ratio between open and closed-source components. The tool can work in the following way:

• Implemented in Python 3
  • Easy and quick to write and understand
  • Platform agnostic language
  • Can easily parse multiple formats of data
• Include a list of known components defining which of them are open, closed or not-sure
  • Defined in json as it is human-readable and easy to parse using Python
  • Would allow for openness calculation without providing necessary information every time
• The tool can read additional configuration that would have a priority over default configuration files
  • Each project making use of the tool would be able to specify if particular component is open or not.
  • For example if coreboot bootblock would be closed-source, the project could specify that in custom configuration file
• Read list of UEFI regions using UEFIExtract
• Read and parse cbfs using cbfstool to create a list of components in a given image
• Calculate percentage size (based on binary size in bytes) of each component excluding empty space in the image
• Option to create a report in markdown format.
  • Would speed up creation of human-readable reports and documentation
• Option to create a report in json format
  • Would better support data parsing by other tools

[pietrushnic]

@IgorBagnucki this is great proposal. Thank you for that one.

Couple ideas:

• Python may be not the best language for modern development. Are you proposing it because of you know it or there is other reason? Did you considered alternatives, if yes, which one?
• I believe console output like something what @macpijan reported internally would be first great step - if correct data would be produced, then putting output in any formatting tool (jinja, google sheet) would be easy stuff, of course we value full automation and potential integration with Dasharo tools
• maybe first step would be to integrate on top of https://github.com/Dasharo/fwdeploy/pull/1/files - please note I have all the components there and based on that we can easily decide which one are open and which are closed
• in long run it should be clearly stated what licenses are associated with given binary - it would be easier to create community movement around binaries which have very concerning claims in license, in very long run database of such binaries would be useful for us and security researchers

[IgorBagnucki]

@pietrushnic Thank You for Your input

• I choose Python, of course because I know it, as I can't choose something unknown to me. :) It's the best tool for this job in my language toolbox, but I didn't consider modern languages like Go or Rust because I simply don't know them well enough to decide if these languages are a good or bad choice for this application. If You have any suggestions, what language would fit better, I'll happily consider it.
• You're right. Creating just a raw console output will be easiest at the start and easy to extend in the future to create output in other data formats.

[pietrushnic]

@IgorBagnucki maybe you or other project participants would like to learn new language. This is relatively easy and low risk project so using new technologies would be welcome. Engineers should learn new languages. I'm in favor of Rust - not because it seem to be good for the task (it seem that Go would be better), but because there is potential synergy in important firmware projects e.g. oreboot, UEFI/edk2 or Linux. Let's think how much time it would be needed to learn Rust for the purpose of writng above tool, when we will have budget then we can start thinking where we will get money.

We should focus on absolute MVP, minimal set of featues. Maybe this kind of tool can be written on hackathon?

[IgorBagnucki]

To better visualize the concept, I am adding a few screenshots. This image shows example of UEFI sections in protectli firmware. As we are modifying only BIOS region, overall openness can't exceed BIOS region percentage size in the whole image that is (BIOS_region_size / image_size) * 100% = (60000h / 800000h) * 100% = 75% This is maximum openness percent for this image if we are not opening ME region or descriptor region.

To calculate the final score calculate the openness percent of BIOS_region and in the case of coreboot we can just use cbfs to look how it is build It is required to decide which of the components are open. In this case following components are closed-source:

cpu_microcode_blob.bin
fspm.bin
fsps.bin
pci8086,5916.rom
pci8086,5917.rom
pci8086,150c.rom

These closed-source files take total of 1219584 bytes. Rest of the files (excluding the empty space) take 393873 bytes, so BIOS region is open in the (393873 ÷ (393873 + 1219584)) * 100% = 24.411%

To calculate the final percent, it is needed to calculate how much space open-source files take in the entire image 0.24411 * 0.75 * 100% = 18.308%

[pietrushnic]

Question is how we should consider ME neutring, in some sense it makes platform more free.

[pietrushnic]

@tlaurion your input would be appreciated.

[tlaurion]

This image shows example of UEFI sections in protectli firmware. As we are modifying only BIOS region, overall openness can't exceed BIOS region percentage size in the whole image that is (BIOS_region_size / image_size) 100% = (60000h / 800000h) 100% = 75%

I think the base of the calculation should consider ME with actual consumed space. Taking just the BIOS region gets GBE and ME out of the equation, and are quite important to take into consideration.

Taking x230 maximized build, for example, would complicate your calculation:

• GBE is generated per specifications. Doesn't change much calculation since 8k but still.
• ME region is reduced from 5mb to 98kb
• IFD has reduced ME space and augmented BIOS region consequently.
• Then and only, the BIOS region size matters for calculation over image_size. Otherwise, what does it mean? Free space here also matters for payload features, future wise.

ME neutering would boost the ratios if taken into consideration. Neutered ME space is considered as well when defining coreboot CONFIG_CBFS_SIZE when producing a full ROM image (which includes neutered and unlocked ME region, GBE and unlocked IFD). Otherwise, we are obligated to specify --ifd --image bios to flash only the BIOS region internally. And that BIOS region size depends of if ME was cleaned or not and if a valid IFD has been provided, and in there, if IFD BIOS region has been expended or not.

I wanted to raise attention to those points, because considering BIOS_region_size as 100% is only valid when internal reflashing of the BIOS region is considered. So calculating the ME region in basic calculation is the true measure of the initial available space for the BIOS region and I think must be calculated.

VBT should also considered closed source, no?

I have not validated your calculation conclusion. But I would love an easier proportion highlight being:

• closed source combined blob binaries size (not percentage?)
• open source binaries size (not percent? Tricky here again and depends on payload. Compressed size I guess?)
• Available combined space for payload expansion (not percent? Useful to know how much additional useful stuff could be injected there.)

My reasoning here, for example for the KGPE-D16, now distributing roms fitting different SPIs (4mb, 8mb, 16mb) is that the used size would be only of open source software (minus cpu microcode update when/if dropped in), with percentage varying depending of produced rom size, while being the same actual blob binary sizes.

So the percentage would vary, but would not give really an idea of what is important there. We might have the microcode there, but the percentage for the different produced roms would be differnent, and more confusing then helpful when considering the closed source percentage, while only the actual size would be helpful to know?

@pietrushnic @IgorBagnucki

[krystian-hebel]

In this case following components are closed-source:

...
pci8086,150c.rom

This actually is iPXE which is open source. Unfortunately there is no easy way of differentiating between open stuff like iPXE and closed like VGA ROM. This can be in config file but only if value different than default one is used. Tool could also search some database of device IDs, but that doesn't really tell what is the source of ROM image.

[macpijan]

@krystian-hebel

Maybe something like

strings pci8086,150c.rom | grep pxe
http://ipxe.org
iPXE (http://ipxe.org)

[macpijan]

Maybe this kind of tool can be written on hackathon?

Yes, I believe so

[macpijan]

I think that @tlaurion has some very good points.

Maybe as a first step, following metric would be a good compromise (simplicity vs information):

• total flash/binary size
• MB (and % of total binary size) of free space
• MB (and % of total binary size) which comes from closed source
• MB (and % of total binary size) which comes from open source

[pietrushnic]

Very interesting feedback from stacktrust. Please analyze how far we are from that vision.

[pietrushnic]

Whole OSFW Slack thread is important in context of this task. Let's convert it into actionable items.

[baptx]

Hello, will there be a Dasharo openness score for NV4x 12th Gen like it is done for NV4x 11th Gen (https://docs.dasharo.com/variants/novacustom_nv4x_tgl/openness_analysis/)? Was it not possible to use the Libreboot fork of coreboot? It would have the advantage to have proprietary blobs removed.

[miczyg1]

Hello, will there be a Dasharo openness score for NV4x 12th Gen like it is done for NV4x 11th Gen (https://docs.dasharo.com/variants/novacustom_nv4x_tgl/openness_analysis/)? Was it not possible to use the Libreboot fork of coreboot? It would have the advantage to have proprietary blobs removed.

Hi @baptx , yes it would be possible to make an openness score for that, but unfortunately we have higher priorities to take care of.

Simply using Libreboot will not make the blobs go away, if I understood you well. This is some kind of misunderstanding. One cannot boot modern x86 platform without blobs as of today. If you would like to have a blobless platform, then ASUS KGPE-D16 or alike are your only choice.

[miczyg1]

Sort of final look and functionality of v0.1.0: https://github.com/Dasharo/Openness-Score/pull/4#issuecomment-1520382711

[miczyg1]

Set of PRs implementing Openness Score v0.1: https://github.com/Dasharo/Openness-Score/pull/1 https://github.com/Dasharo/Openness-Score/pull/2 https://github.com/Dasharo/Openness-Score/pull/3 https://github.com/Dasharo/Openness-Score/pull/4 https://github.com/Dasharo/Openness-Score/pull/5 https://github.com/Dasharo/Openness-Score/pull/6

Tag placed. https://github.com/Dasharo/Openness-Score/releases/tag/v0.1

Closing the ticket

[tlaurion]

@miczyg1 checked examples for x230 and no report is given for ME, which if I remember correctly were present from original reports? What is important, for example for x230, is that original ME is ~5mb as opposed to neutered which is 98kb. That somehow should be highlighted from the report somehow, and be comparable between boards for that matter?

[miczyg1]

@tlaurion they were not present in original reports, you may check the file history: https://github.com/Dasharo/Openness-Score/commit/d0aec9129097e8d99879e06f8bcc405d794358e6#diff-bbbb8ff3216c6505ebb75fbe7211ff6640badff30162cf0164096ffb905495de

The utility takes the output of cbfstool heads-x230-maximized-v0.2.0-1554-g21b87ff.rom layout -w, which looks like this:

This image contains the following sections that can be accessed with this tool:

'BIOS' (read-only, size 12451840, offset 131072)
'RW_MRC_CACHE' (size 65536, offset 131072)
'FMAP' (read-only, size 512, offset 196608)
'COREBOOT' (CBFS, size 12385792, offset 197120)

It is at least possible to perform the read action on every section listed above.

Your builds do not specify any ME region or IFD region, so the utility assumes the gap from offset 0 to offset 131072 (start of BIOS flashmap region) is just closed-source without knowing what is inside. We could implement a usage of ifdtool to try extracting some info about flash descriptor and ME from it...

[tlaurion]

@miczyg1 well that still represent correctly the proportion of closed source blobs percentage, but makes it hard for the user to get what it included in it.

The ROM contains an ifd and neutered me. If goal is one day to compare across boards,that data might be important to have otherwise difficult to compare.

[miczyg1]

@miczyg1 well that still represent correctly the proportion of closed source blobs percentage, but makes it hard for the user to get what it included in it.

The ROM contains an ifd and neutered me. If goal is one day to compare across boards,that data might be important to have otherwise difficult to compare.

Sure, I get the point. It's a prototype version, guaranteed to have inefficiencies :) Anyways, I am adding an issue to keep track of it: https://github.com/Dasharo/dasharo-issues/issues/461