summaryrefslogtreecommitdiff
path: root/src/device/oprom/x86emu/ops.c
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2019-12-12 13:23:06 -0800
committerJulius Werner <jwerner@chromium.org>2019-12-13 20:14:26 +0000
commitf8e1764bb9696782ad3e525be8be34c3a9e14588 (patch)
tree35087fb9f64d011304aabb77a5e00d87d5d701a8 /src/device/oprom/x86emu/ops.c
parent9b7c23292454ad8c04ec82fa03d276bc425fe315 (diff)
security/vboot: Ensure firmware body size is respected again
CB:36845 simplified how coreboot finds the RW CBFS after vboot has and eliminated a layer of caching. Unfortunately, we missed the fact that the former cached value didn't exactly match the FMAP section... it was in fact truncated to the data actually used by vboot. That patch unintentionally broke this truncation which leads to performance regressions on certain CBFS accesses. This patch makes use of a new API function added to vboot (CL:1965920) which we can use to retrieve the real firmware body length as before. (Also stop making all the vb2_context pointers const. vboot generally never marks context pointers as const in its API functions, even when the function doesn't modify the context. Therefore constifying it inside coreboot just makes things weird because it prevents you from calling random API functions for no reason. If we really want const context pointers, that's a refactoring that would have to start inside vboot first.) This patch brings in upstream vboot commit 4b0408d2: 2019-12-12 Julius Werner 2lib: Move firmware body size reporting to separate function Change-Id: I167cd40cb435dbae7f09d6069c9f1ffc1d99fe13 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37680 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Mathew King <mathewk@chromium.org>
Diffstat (limited to 'src/device/oprom/x86emu/ops.c')
0 files changed, 0 insertions, 0 deletions