lbmk/config/coreboot/coreboot413/patches/0001-cbfstool-Make-use-of-s...

57 lines
2.0 KiB
Diff
Raw Normal View History

NEW MAINBOARD: HP EliteBook 820 G2 This is of Broadwell platform, one generation above Haswell. Of note: this uses HP Sure Start. Although the flash is 16MB, our CBFS section (and IFD configuration) assumes 12MB flash, so the final 4MB will be left unflashed on installation, after blanking the private flash. The coreboot documents have more information about this. Some minor design changes in lbmk were made, to accomodate this port: Support for extracting refcode binaries added (pulled from Google recovery images). The refcode file is an ELF that initialises the MRC and the PCH. It is also responsible for enabling or disabling the Intel GbE device, where Google does not enable it, but lbmk modifies it per the instructions on the coreboot documentation, so as to enable Intel GbE. Google's recovery image stores the refcode as a stage file, but coreboot changed the format (for CBFS files) after 4.13 so coreboot 4.13's cbfstool is used to extract refcode. This realisation made me also change the script logic to use a cbfstool and ifdtool version matching the coreboot tree, for all parts of lbmk, whereas lbmk previously used only the default tree for cbfstool/ifdtool, on insertion and deletion of vendor files - it was 81dc20e744 that broke extraction of refcode on google's recovery images, where google used an older version of cbfstool to insert the files in their coreboot ROMs. A further backported patch has been added, copying coreboot revision f22f408956 which is a build fix from Nico Huber. Iru Cai submitted an ACPI bugfix after the revision lbmk currently uses, for coreboot/default, and this fix is needed for rebooting to work on Linux 6.1 or higher. This patch has been backported to lbmk, while it still uses the same October 2023 revision of coreboot. Broadwell MRC is inserted at the same offset as Haswell, so I didn't need to tweak that. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-07 13:25:33 +00:00
From f22f408956bf02609a96b7d72fb3321da159bfc6 Mon Sep 17 00:00:00 2001
From: Nico Huber <nico.huber@secunet.com>
Date: Tue, 22 Jun 2021 13:49:44 +0000
Subject: [PATCH 1/1] cbfstool: Make use of spurious null-termination
The null-termination of `filetypes` was added after the code was
written, obviously resulting in NULL dereferences. As some more
code has grown around the termination, it's hard to revert the
regression, so let's update the code that still used the array
length.
This fixes commit 7f5f9331d1 (util/cbfstool: fix buffer over-read)
which actually did fix something, but only one path while it broke
two others. We should be careful with fixes, they can always break
something else. Especially when a dumb tool triggered the patching
it seems likely that fewer people looked into related code.
Change-Id: If2ece1f5ad62952ed2e57769702e318ba5468f0c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55763
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
---
util/cbfstool/common.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/util/cbfstool/common.c b/util/cbfstool/common.c
index e2ed38ffc4..539d0baccf 100644
--- a/util/cbfstool/common.c
+++ b/util/cbfstool/common.c
@@ -168,10 +168,10 @@ void print_supported_architectures(void)
void print_supported_filetypes(void)
{
- int i, number = ARRAY_SIZE(filetypes);
+ int i;
- for (i=0; i<number; i++) {
- printf(" %s%c", filetypes[i].name, (i==(number-1))?'\n':',');
+ for (i=0; filetypes[i].name; i++) {
+ printf(" %s%c", filetypes[i].name, filetypes[i + 1].name ? ',' : '\n');
if ((i%8) == 7)
printf("\n");
}
@@ -180,7 +180,7 @@ void print_supported_filetypes(void)
uint64_t intfiletype(const char *name)
{
size_t i;
- for (i = 0; i < (sizeof(filetypes) / sizeof(struct typedesc_t)); i++)
+ for (i = 0; filetypes[i].name; i++)
if (strcmp(filetypes[i].name, name) == 0)
return filetypes[i].type;
return -1;
--
2.39.2