summaryrefslogtreecommitdiff
path: root/src/commonlib
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2020-11-18 18:31:22 -0800
committerJulius Werner <jwerner@chromium.org>2021-02-18 02:32:37 +0000
commitf0cc7adb2fc2ecdc4e6f0dd4e81b7895859b55d2 (patch)
tree205a025c1c1009edf7e9d9834c1c43f9c3297990 /src/commonlib
parentff61a39e90e0f8cb94a3dd015a2ebd6cae728cc6 (diff)
cbfstool: Ensure attributes always come last in the metadata
In a rare placement edge case when adding a file with alignment requirements, cbfstool may need to generate a CBFS header that's slightly larger than it needs to be. The way we do this is by just increasing the data offset field in the CBFS header until the data falls to the desired value. This approach works but it may confuse parsing code in the presence of CBFS attributes. Normally, the whole area between the attribute offset and the data offset is filled with valid attributes written back to back, but when this header expansion occurs the attributes are followed by some garbage data (usually 0xff). Parsers are resilient against this but may show unexpected error messages. This patch solves the problem by moving the attribute offset forwards together with the data offset, so that the total area used for attributes doesn't change. Instead, the filename field becomes the expanded area, which is a closer match to how this worked when it was originally implemented (before attributes existed) and is less confusing for parsers since filenames are zero-terminated anyway. Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: I3dd503dd5c9e6c4be437f694a7f8993a57168c2b Reviewed-on: https://review.coreboot.org/c/coreboot/+/47824 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Diffstat (limited to 'src/commonlib')
0 files changed, 0 insertions, 0 deletions