Coreboot parsing

[miczyg1]

First portion of code, which can:

1. Take two firmware binaries as input
2. Automatically distinguishes between coreboot images and vendor UEFI images (other image types unsupported for now).
3. Parse coreboot fmap layout to extract regions' properties.
4. Automatically recognize fmap regions with CBFSes.
5. Parse CBFSes regions to extract files' properties.
6. Checks for required utilities presence (cbfstool, UEFIExtract)

Additionally added known file types, definitions and names to categorize what will be considered open-source/closed-source/data components.

Sample output of current code processing binaries: https://paste.dasharo.com/?a85443607d32aedb#EWJfMA67HZhLKPoiWLbUZQY8YPhSn1TTTsjHFLabRjAm

Further development will also be conducted in portions implementing missing functionalities:

1. Add script to install required utilities (cbfstool and UEFIExtract).
2. Add CI file with pycodestyle checks and possibly sample binary checks.
3. Calculation of total size of open-source/closed-source/data/empty components per region/CBFS/whole image
   4 Calculation of total size of closed-source/data/empty components in vendor UEFI image.
4. Extraction of coreboot config to check for known open-source/closed-source components, .e.g check for external LAN ROM efi file, check for iPXE PCI ID if iPXE is added as secondary payload for SeaBIOS, etc.
5. Plotting the pie charts with % share for each type of component compared to the whole image size.
6. Exporting numeric statistics to CSV files (optional).

[pietrushnic]

@miczyg1 please assign a reviewer.

I don't know if the following feature requests should be part of this MR or another. Please let me know WDYT.

• Script should run as part of CI/CD
• Dasharo Openness Score should be published as part of the newsletter.
• Dasharo Openness Score should be published as part of the DUG.
• We should target the production version for DUG#2.
• CI/CD should compare the Dasharo binary with reference binaries we obtained from hardware. We should not care about the privacy of hardware in the lab since it can already be considered public domain.
• Dasharo documentation should be adequately improved to explain our methodology.
• Versioning should be added.

For which releases and which platform do we plan to provide Openses Score?

[miczyg1]

I don't know if the following feature requests should be part of this MR or another. Please let me know WDYT.

Some (if not most) of these requests are already included in the first comment in the PR. Versioning v0.1 will be added when UEFI parsing is finished and the results are presented as pie charts artifacts with the metrics exported as CSV. This is the first milestone.

For which releases and which platform do we plan to provide Openses Score?

Ultimately this should be incorporated into our templates and used for all platforms

[pietrushnic]

Some (if not most) of these requests are already included in the first comment in the PR. Versioning v0.1 will be added when UEFI parsing is finished and the results are presented as pie charts artifacts with the metrics exported as CSV. This is the first milestone.

We should be precise, which are not planned for v0.1? Can you put those in the v0.2 milestone, please?

[pietrushnic]

Ultimately this should be incorporated into our templates and used for all platforms

It doesn't answer my question.

[miczyg1]

Ultimately this should be incorporated into our templates and used for all platforms

It doesn't answer my question.

Integrating into the templates means the Dasharo Openness Score will be published as part of the newsletter AND docs.dasharo.com (release notes probably) for ALL Dasharo platforms

[pietrushnic]

It instead sounds that for ALL new releases for Dasharo support platforms. So key question would be which release would be next, so we can check Openness Score in action.

[miczyg1]

It instead sounds that for ALL new releases for Dasharo support platforms. So key question would be which release would be next, so we can check Openness Score in action.

There will be no problem for adding/generating openness score for past releases if needed.

As for the key question, I don't know, it depends on the workload when the utility will become usable. Novacustom would like to have Openness Score for each release, so probably the priority will be to use it there, not necessarily on new incoming releases.