summaryrefslogtreecommitdiff
path: root/tests/data/lib/lzma-test/data.2.lzma.bin
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2023-11-02 15:44:12 -0700
committerJulius Werner <jwerner@chromium.org>2023-11-07 22:30:02 +0000
commit682cb3b56419a242b54605cc734b99ffdcab8213 (patch)
treefe8468a05b6446d84163925be3262949f3bfeec4 /tests/data/lib/lzma-test/data.2.lzma.bin
parent5bc5b1d02486acd7572d62b519642706b2872a37 (diff)
fmap: Die immediately on verification failure
A recent security audit has exposed a TOCTOU risk in the FMAP verification code: if the flash returns a tampered FMAP during the first setup_preram_cache(), we will abort generating the cache but only after already filling the persistent CAR/SRAM region with the tampered version. Then we will fall back into the direct access path, which could succeed if the flash now returns the original valid FMAP. In later stages, we will just use the data from the persistent CAR/SRAM region as long as it looks like an FMAP without verifying the hash again (because the hash is only linked into the initial stage). This patch fixes the issue by just calling die() immediately if FMAP hash verification fails. When the verification fails, there's no recourse anyway -- if we're not dying here we would be dying in cbfs_get_boot_device() instead. There is no legitimate scenario where it would still be possible to continue booting after this hash verification fails. Change-Id: I59ec91c3e5a59fdd960b0ba54ae5f15ddb850480 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/78903 Reviewed-by: Yu-Ping Wu <yupingso@google.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'tests/data/lib/lzma-test/data.2.lzma.bin')
0 files changed, 0 insertions, 0 deletions