summaryrefslogtreecommitdiffstats
path: root/3rdparty
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2021-08-30 19:01:48 -0700
committerJulius Werner <jwerner@chromium.org>2021-09-01 23:57:14 +0000
commit6813d561b2fcd89e0df23a3c41843433767edec3 (patch)
tree028361f5a2f269595563ecc1a475ba0ae83d1b88 /3rdparty
parent7c6081e02b319a29268429ce38fe0345a85e8299 (diff)
downloadcoreboot-6813d561b2fcd89e0df23a3c41843433767edec3.tar.gz
coreboot-6813d561b2fcd89e0df23a3c41843433767edec3.tar.bz2
coreboot-6813d561b2fcd89e0df23a3c41843433767edec3.zip
cbfs: Make sure all cases of single file header corruption are isolated
The new CBFS stack was written to try to isolate cases of single file corruption as far as possible and still make other files avaialble (at least as long as verification is disabled and they can still be found at all). For most cases of header corruption, it will just continue trying to parse the next file. However, in cases where parts of the file extend beyond the end of the rdev, we have been relying on the range checking of the rdev API rather than doing it explicitly. This is fine in general, but it causes the problem that these errors cannot be distinguished from I/O errors, and I/O errors always make the whole cbfs_walk() fail. That means we will not return a successful result from cbfs_mcache_build(), and leads to an odd discrepancy in how certain kinds of corrupted CBFSes are treated with and without mcache. This patch adds an explicit range check to make the behavior consistent. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ice2b6960284bd0c19be35b0607e5e32791e7a64c Reviewed-on: https://review.coreboot.org/c/coreboot/+/57271 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Diffstat (limited to '3rdparty')
0 files changed, 0 insertions, 0 deletions