coreboot-kgpe-d16/.gitmodules

68 lines
1.6 KiB
Plaintext
Raw Normal View History

[submodule "3rdparty/blobs"]
path = 3rdparty/blobs
url = ../blobs.git
update = none
ignore = dirty
[submodule "util/nvidia-cbootimage"]
path = util/nvidia/cbootimage
url = ../nvidia-cbootimage.git
[submodule "vboot"]
path = 3rdparty/vboot
url = ../vboot.git
branch = main
[submodule "arm-trusted-firmware"]
path = 3rdparty/arm-trusted-firmware
url = ../arm-trusted-firmware.git
[submodule "3rdparty/chromeec"]
path = 3rdparty/chromeec
url = ../chrome-ec.git
[submodule "libhwbase"]
path = 3rdparty/libhwbase
url = ../libhwbase.git
[submodule "libgfxinit"]
path = 3rdparty/libgfxinit
url = ../libgfxinit.git
[submodule "3rdparty/fsp"]
path = 3rdparty/fsp
url = ../fsp.git
update = none
ignore = dirty
[submodule "opensbi"]
path = 3rdparty/opensbi
url = ../opensbi.git
[submodule "intel-microcode"]
path = 3rdparty/intel-microcode
url = ../intel-microcode.git
update = none
ignore = dirty
branch = main
[submodule "3rdparty/ffs"]
path = 3rdparty/ffs
url = ../ffs.git
[submodule "3rdparty/amd_blobs"]
path = 3rdparty/amd_blobs
url = ../amd_blobs
update = none
ignore = dirty
[submodule "3rdparty/cmocka"]
path = 3rdparty/cmocka
url = ../cmocka.git
update = none
branch = stable-1.1
[submodule "3rdparty/qc_blobs"]
path = 3rdparty/qc_blobs
url = ../qc_blobs.git
update = none
ignore = dirty
[submodule "3rdparty/intel-sec-tools"]
path = 3rdparty/intel-sec-tools
url = ../9esec-security-tooling.git
[submodule "3rdparty/stm"]
path = 3rdparty/stm
url = ../STM
branch = stmpe
Add SBOM (Software Bill of Materials) Generation Firmware is typically delivered as one large binary image that gets flashed. Since this final image consists of binaries and data from a vast number of different people and companies, it's hard to determine what all the small parts included in it are. The goal of the software bill of materials (SBOM) is to take a firmware image and make it easy to find out what it consists of and where those pieces came from. Basically, this answers the question, who supplied the code that's running on my system right now? For example, buyers of a system can use an SBOM to perform an automated vulnerability check or license analysis, both of which can be used to evaluate risk in a product. Furthermore, one can quickly check to see if the firmware is subject to a new vulnerability included in one of the software parts (with the specified version) of the firmware. Further reference: https://web.archive.org/web/20220310104905/https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/ - Add Makefile.inc to generate and build coswid tags - Add templates for most payloads, coreboot, intel-microcode, amd-microcode. intel FSP-S/M/T, EC, BIOS_ACM, SINIT_ACM, intel ME and compiler (gcc,clang,other) - Add Kconfig entries to optionally supply a path to CoSWID tags instead of using the default CoSWID tags - Add CBFS entry called SBOM to each build via Makefile.inc - Add goswid utility tool to generate SBOM data Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: Icb7481d4903f95d200eddbfed7728fbec51819d0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/63639 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
2022-04-14 14:54:16 +02:00
[submodule "util/goswid"]
path = util/goswid
url = ../goswid
branch = trunk