Support extracting symbols in .dynsym section for GraalVM Native Images

[rudsberg]

Description

This PR adds support for extracting SBOMs embedded in native images where the SBOM symbols are saved in the .dynsym section of ELF files. Newer versions of GraalVM Native Image saves the SBOM symbols in the .dynsym section while older versions saves them in the .symtab section. This PR ensures SBOM extraction works in both cases.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist:

• I have added unit tests that cover changed behavior*

*No additional tests were added. The new getSymbols function is exercised via TestParseNativeImage that calls fetchPkgs. This is a negative test testing that an error is thrown when SBOM extraction is attempted on a native image that wasn't created with an embedded SBOM.

• I have tested my code in common scenarios and confirmed there are no regressions
• I have added comments to my code, particularly in hard-to-understand sections

[rudsberg]

Hi @kzantow - Are you or some other team member available to review this small PR in the near future?

[martijndwars]

Hi @kzantow, any update? We're eager to get these changes in Syft! :)

[wagoodman]

How many symbols would be added to the SBOM for these packages (say on average)? Ideally there would be a test that asserts the expected set of symbols from a test fixture.

[martijndwars]

How many symbols would be added to the SBOM for these packages (say on average)?

Just to make sure I understand where the question comes from; are you concerned that Syft would spend too much time/memory on reading the (dynamic) symbol table from the ELF? Note that symbols are added to the ELF, not the SBOM. The SBOM is stored in the symbol named sbom.

[rudsberg]

@wagoodman, as @martijndwars pointed out: the relevant symbols (sbom, sbom_length, and __svm_version_info) are part of the Native Image ELF file and not the final SBOM. An error is thrown if any of those symbols are not present. TestParseNativeImage tests that error path. There is currently no integration test that: creates a Native Image with an embedded SBOM, invokes syft, and makes assertions on the extracted SBOM. Such a test would indirectly assert that the three symbols are part of the ELF file. Note that the SBOM feature is only available in Oracle GraalVM (not the community version) which is released under GFTC license and that can be pulled from Oracle's container registry.

My suggestion is that we merge this so users like @martijndwars can extract SBOMs with syft using newer versions of Native Image. If there's interest from the syft team to improve the general integration testing using Oracle GraalVM, that would be appropriately done in another PR.

[wagoodman]

@martijndwars @rudsberg thanks for the corrections -- I assumed that there was a need to extract symbols for the intention of having more detail in the SBOM, but now I see that this is really a response to a change upstream and the cataloging behavior is still the same.

Regarding the test update, I agree, that improvement can always come in another PR (I see how that would be more difficult to test here!).

[wagoodman]

Thanks for the contribution!