| Age | Commit message (Collapse) | Author |
|---|
|
The .inc suffix is confusing to various tools as it's not specific to
Makefiles. This means that editors don't recognize the files, and don't
open them with highlighting and any other specific editor functionality.
This issue is also seen in the release notes generation script where
Makefiles get renamed before running cloc.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I9eabe84d55fd9f434e4128866810c0e4970f2ae7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/80081
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
|
|
This changes the path where go installs its packages.
Now the packages are not installed in the users home directory anymore.
This solution is not perfect though, since offline build are still not
possible, because go will fetch the packages at build time.
-modcacherw will create the go files with rw permissions, otherwise
coreboot is not able to delete the files afterwards (make distclean).
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I2a35369628454057ea4758cd1225e57f07cb71c8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
|
|
Yabits is no longer maintained and git repo is archived.
Yabits has not been maintained for a long time,
the project is apparently closed.
Change-Id: Ida0bb79342448510d2c309339fabbe8066eca73c
Signed-off-by: Elias Souza <eliascontato@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72463
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
Make does its work in two distinct phases. The first one basically
initializes and expands all variables, which are not in a recipe and
the second expands all variables inside recipes and then executes the
recipes if necessary.
Currently on some mainboards it can happen that cpu_microcode_bins
variable is filled with microcode paths AFTER swid-files-y is expanded
in the prerequisite for the sbom rule. That causes the
"$(build-dir)/intel-microcode-%.json pattern matching rule not to be
invoked. At the time, when the recipe is executed however (second phase
of make), swid-files-y will now contain the cpu microcode paths from
cpu_microcode_bins. That causes the goswid tooling to fail since the
necessary files were never created, since
"(build-dir)/intel-microcode-%.json" target was never executed.
In order to trigger the expansion of swid-files-y at the second make
phase (after cpu_microcode_bins is fully filled), this patch makes use
of make's secondary expansion feature.
Before on some boards (including samsung/lumpy) the goswid tool
complained about not finding the microcode sbom files.
Test: build samsung/lumpy with CONFIG_SBOM_MICROCODE=y
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I884469a388fd48be89d74ccda686dd8f299d63eb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72660
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Functionality wise nothing changed, except that the first misspellings
caused SBOM_BIOS_ACM_PATH and SBOM_SINIT_ACM_PATH to not work before.
- Fix misspelling of CONFIG_BIOS_ACM_PATH -> CONFIG_SBOM_BIOS_ACM_PATH
- Fix misspelling of CONFIG_SINIT_ACM_PATH -> CONFIG_SBOM_SINIT_ACM_PATH
- Put SBOM_COMPILER_ handling into Kconfig instead of Makefile
- Reorder CONFIG_ paths (for readablity)
- Add in code comments (for readablity)
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: If67bc3bd0d330b9b5f083edc4d1697e92ace1ea0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Make will not find the build targets unless quotes are removed.
Change-Id: Iddf4e0cd8a11eaf327d6f55baf38a30c566d0f28
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71519
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
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>
|
