splatink/lbmk
1
0
Fork 0
mirror of https://codeberg.org/libreboot/lbmk.git synced 2026-03-25 13:29:03 +02:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into 25.04_branch

Browse Source
This commit is contained in:
Leah Rowe
2025-05-08 21:24:56 +01:00
parent b525833f42 a3ba8acfac
commit 15461df2e8
8 changed files with 3 additions and 279 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
config/coreboot/coreboot413/patches/0001-cbfstool-Make-use-of-spurious-null-termination.patch
View File

@@ -1,56 +0,0 @@
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

33
config/coreboot/coreboot413/patches/0002-Fix-cbfstool-build-error-on-GCC-15-host-compiler.patch
View File

@@ -1,33 +0,0 @@
From 06e8d7a9db4efe1dc2b7e5865b801a5518b38fbd Mon Sep 17 00:00:00 2001
From: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Date: Tue, 29 Apr 2025 17:31:13 +0300
Subject: [PATCH 1/1] Fix cbfstool build error on GCC 15 host compiler
GCC 15 now considers the unterminated-string-initialization warning as
part of -Werror by default. Coreboot compiles host utilities with the
system compiler, which results in getting this error in some files.
Mark a hexadecimal translation table in cbfstool code as "nonstring" to
avoid the warning-turned-error.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
---
util/cbfstool/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/cbfstool/common.c b/util/cbfstool/common.c
index 539d0baccf..f6fe647503 100644
--- a/util/cbfstool/common.c
+++ b/util/cbfstool/common.c
@@ -188,7 +188,7 @@ uint64_t intfiletype(const char *name)
char *bintohex(uint8_t *data, size_t len)
{
- static const char translate[16] = "0123456789abcdef";
+ static const char translate[16] __attribute__((__nonstring__)) = "0123456789abcdef";
char *result = malloc(len * 2 + 1);
if (result == NULL)
--
2.39.5

4
config/coreboot/coreboot413/target.cfg
View File

@@ -1,4 +0,0 @@
# SPDX-License-Identifier: GPL-3.0-or-later
tree="coreboot413"
rev="5c186c6777c9438ff4681929c9c25c98dee28bef"

1
config/submodule/coreboot/coreboot413/module.list
View File

@@ -1 +0,0 @@
3rdparty/vboot

5
config/submodule/coreboot/coreboot413/vboot/module.cfg
View File

@@ -1,5 +0,0 @@
# SPDX-License-Identifier: GPL-3.0-or-later
subrepo="https://review.coreboot.org/vboot.git"
subrepo_bkup="https://github.com/coreboot/vboot"
subhash="4c523ed10f25de872ac0513ebd6ca53d3970b9de"

178
config/submodule/coreboot/coreboot413/vboot/patches/0001-extract_vmlinuz.c-Fix-the-bounds-check-on-vmlinuz_he.patch
View File

@@ -1,178 +0,0 @@
From 195f61375aeec9eec16604ec59f6eda2e6058cc1 Mon Sep 17 00:00:00 2001
From: "Luke T. Shumaker" <lukeshu@lukeshu.com>
Date: Thu, 30 May 2024 14:08:33 -0600
Subject: [PATCH 1/1] extract_vmlinuz.c: Fix the bounds check on
vmlinuz_header_{offset,size}
The check on vmlinuz_header_offset and vmlinuz_header_size is obviously
wrong:
if (!vmlinuz_header_size ||
kpart_data + vmlinuz_header_offset + vmlinuz_header_size >
kpart_data) {
return 1;
}
`kpart_data + some_unsigned_values` can obviously never be `> kpart_data`,
unless something has overflowed! And `vmlinuz_header_offset` hasn't even
been set yet (besides being initialized to zero)!
GCC will deduce that if the check didn't cause the function to bail, then
vmlinuz_header_size (a uint32_t) must be "negative"; that is: in the range
[2GiB,4GiB).
On platforms where size_t is 32-bits, this is *especially* broken.
memcpy's size argument must be in the range [0,2GiB). Because GCC has
proved that vmlinuz_header_size is higher than that, it will fail to
compile:
host/lib/extract_vmlinuz.c:67:9: error: 'memcpy' specified bound between 2147483648 and 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=]
So, fix the check.
I can now say that what I suspect the original author meant to write would
be the following patch, if `vmlinuz_header_offset` were already set:
-kpart_data + vmlinuz_header_offset + vmlinuz_header_size > kpart_data
+now + vmlinuz_header_offset + vmlinuz_header_size > kpart_size
This hypothesis is supported by `now` not getting incremented by
`kblob_size` the way it is for the keyblock and preamble sizes.
However, we can also see that even this "corrected" bounds check is
insufficient: it does not detect the vmlinuz_header overflowing into
kblob_data.
OK, so let's describe the fix:
Have a `*vmlinuz_header` pointer instead of a
`uint64_t vmlinuz_header_offset`, to be more similar to all the other
regions. With this change, the correct check becomes a simple
vmlinuz_header + vmlinuz_header_size > kblob_data
While we're at it, make some changes that could have helped avoid this in
the first place:
- Add comments.
- Calculate the vmlinuz_header offset right away, instead of waiting.
- Go ahead and increment `now` by `kblob_size`, to increase regularity.
Change-Id: I5c03e49070b6dd2e04459566ef7dd129d27736e4
---
host/lib/extract_vmlinuz.c | 72 +++++++++++++++++++++++++++-----------
1 file changed, 51 insertions(+), 21 deletions(-)
diff --git a/host/lib/extract_vmlinuz.c b/host/lib/extract_vmlinuz.c
index 4ccfcf33..d2c09443 100644
--- a/host/lib/extract_vmlinuz.c
+++ b/host/lib/extract_vmlinuz.c
@@ -15,16 +15,44 @@
int ExtractVmlinuz(void *kpart_data, size_t kpart_size,
void **vmlinuz_out, size_t *vmlinuz_size) {
+ // We're going to be extracting `vmlinuz_header` and
+ // `kblob_data`, and returning the concatenation of them.
+ //
+ // kpart_data = +-[kpart_size]------------------------------------+
+ // | |
+ // keyblock = | +-[keyblock->keyblock_size]-------------------+ |
+ // | | struct vb2_keyblock keyblock | |
+ // | | char [] ...data... | |
+ // | +---------------------------------------------+ |
+ // | |
+ // preamble = | +-[preamble->preamble_size]-------------------+ |
+ // | | struct vb2_kernel_preamble preamble | |
+ // | | char [] ...data... | |
+ // | | char [] vmlinuz_header | |
+ // | | char [] ...data... | |
+ // | +---------------------------------------------+ |
+ // | |
+ // kblob_data= | +-[preamble->body_signature.data_size]--------+ |
+ // | | char [] ...data... | |
+ // | +---------------------------------------------+ |
+ // | |
+ // +-------------------------------------------------+
+
size_t now = 0;
+ // The 3 sections of kpart_data.
+ struct vb2_keyblock *keyblock = NULL;
struct vb2_kernel_preamble *preamble = NULL;
uint8_t *kblob_data = NULL;
uint32_t kblob_size = 0;
+ // vmlinuz_header
+ uint8_t *vmlinuz_header = NULL;
uint32_t vmlinuz_header_size = 0;
- uint64_t vmlinuz_header_address = 0;
- uint64_t vmlinuz_header_offset = 0;
+ // The concatenated result.
void *vmlinuz = NULL;
- struct vb2_keyblock *keyblock = (struct vb2_keyblock *)kpart_data;
+ // Isolate the 3 sections of kpart_data.
+
+ keyblock = (struct vb2_keyblock *)kpart_data;
now += keyblock->keyblock_size;
if (now > kpart_size)
return 1;
@@ -36,37 +64,39 @@ int ExtractVmlinuz(void *kpart_data, size_t kpart_size,
kblob_data = kpart_data + now;
kblob_size = preamble->body_signature.data_size;
-
- if (!kblob_data || (now + kblob_size) > kpart_size)
+ now += kblob_size;
+ if (now > kpart_size)
return 1;
+ // Find `vmlinuz_header` within `preamble`.
+
if (preamble->header_version_minor > 0) {
- vmlinuz_header_address = preamble->vmlinuz_header_address;
+ // calculate the vmlinuz_header offset from
+ // the beginning of the kpart_data. The kblob doesn't
+ // include the body_load_offset, but does include
+ // the keyblock and preamble sections.
+ size_t vmlinuz_header_offset =
+ preamble->vmlinuz_header_address -
+ preamble->body_load_address +
+ keyblock->keyblock_size +
+ preamble->preamble_size;
+
+ vmlinuz_header = kpart_data + vmlinuz_header_offset;
vmlinuz_header_size = preamble->vmlinuz_header_size;
}
- if (!vmlinuz_header_size ||
- kpart_data + vmlinuz_header_offset + vmlinuz_header_size >
- kpart_data) {
+ if (!vmlinuz_header ||
+ !vmlinuz_header_size ||
+ vmlinuz_header + vmlinuz_header_size > kblob_data) {
return 1;
}
- // calculate the vmlinuz_header offset from
- // the beginning of the kpart_data. The kblob doesn't
- // include the body_load_offset, but does include
- // the keyblock and preamble sections.
- vmlinuz_header_offset = vmlinuz_header_address -
- preamble->body_load_address +
- keyblock->keyblock_size +
- preamble->preamble_size;
+ // Concatenate and return.
vmlinuz = malloc(vmlinuz_header_size + kblob_size);
if (vmlinuz == NULL)
return 1;
-
- memcpy(vmlinuz, kpart_data + vmlinuz_header_offset,
- vmlinuz_header_size);
-
+ memcpy(vmlinuz, vmlinuz_header, vmlinuz_header_size);
memcpy(vmlinuz + vmlinuz_header_size, kblob_data, kblob_size);
*vmlinuz_out = vmlinuz;
--
2.45.1

2
config/vendor/hp820g2/pkg.cfg vendored
View File

@@ -7,5 +7,5 @@ MRC_url="https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_13904.77.0_s
MRC_url_bkup="https://web.archive.org/web/20220310155922/https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_13904.77.0_samus_recovery_stable-channel_mp-v3.bin.zip"
MRC_hash="3ff1599c52539f0707a07a8664a84ce51cd3fed1569df4bb7aa6722fc8dec0af1754250333b6ca1a9794d970a4de7b29a5cf2499f5b61e4c3eab64d1314aaea9"
MRC_board="samus"
MRC_refcode_cbtree="coreboot413"
MRC_refcode_cbtree="fam15h"
MRC_refcode_gbe="131253"

3
include/init.sh
View File

@@ -134,7 +134,8 @@ xbmk_set_env()
xbmkcache="`findpath "$XBMK_CACHE"`" || \
err "Can't resolve cachedir: '$XBMK_CACHE'"
export XBMK_CACHE="$xbmkcache"
[ -d "$XBMK_CACHE" ] || err "cachedir '$XBMK_CACHE' is a file"; :
[ ! -e "$XBMK_CACHE" ] || \
[ -d "$XBMK_CACHE" ] || err "cachedir '$XBMK_CACHE' is a file"; :
# if "y": a coreboot target won't be built if target.cfg says release="n"
# (this is used to exclude certain build targets from releases)