[coreboot-gerrit] Patch merged into coreboot/master: 636cc85 cbfstool: Make the add action choose an aligned entries capacity

[gerrit at coreboot.org]

the following patch was just integrated into master:
commit 636cc858bb6979cbd51abaa1d75842146b0c29f7
Author: Sol Boucher <solb at chromium.org>
Date:   Fri Apr 3 09:13:04 2015 -0700

    cbfstool: Make the add action choose an aligned entries capacity
    
    This fixes an inconsistency between `cbfstool create` and `cbfstool add` that
    was resulting in confusing claims about the amount of free space at the end of a
    CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file
    entry by testing whether it would collide with the beginning of the *subsequent*
    file header; thus, if a file's end is unaligned, its reported size will not
    match the actual available capacity. Although deleted entries always end on an
    alignment boundary because `cbfstool remove` expands them to fill the available
    space, `cbfstool create` doesn't necessarily size a new entries region to result
    in an empty entry with an aligned end.
    This problem never resulted in clobbering important data because cbfstool would
    blindly reserve 64B (or the selected alignment) of free space immediately after
    the all-inclusive empty file entry. This change alters the way this reservation
    is reported: only the overhang past the alignment is used as hidden padding, and
    the empty entry's capacity is always reported such that it ends at an aligned
    address.
    Much of the time that went into this patch was spent building trust in the
    trickery cbfstool employs to avoid explicitly tracking the image's total
    capacity for entries, so below are two proofs of correctness to save others time
    and discourage inadvertent breakage:
    
    OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS
    empty file header is small enough that it won't cross another aligned address.
    
    OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such
    that its contents end on an aligned address.
    
    THM. 1: Placing a new file within an empty entry located below an existing file
    entry will never leave an aligned flash address containing neither the beginning
    of a file header nor part of a file.
     We can prove this by contradiction: assume a newly-added file neither fills to
     the end of the preexisting empty entry nor leaves room for another aligned
     empty header after it. Then the first aligned address after the end of the
     newly-inserted file...
      - CASE 1: ...already contains a preexisting file entry header.
        + Then that address contains a file header.
      - CASE 2: ...does not already house a file entry header.
        + Then because CBFS content doesn't fall outside headers, the area between
          there and the *next* aligned address after that is unused.
        + By (A), we can fit a file header without clobbering anything.
        + Then that address now contains a file header.
    
    THM. 2: Placing a new file in an empty entry at the very end of the image such
    that it fits, but leaves no room for a final header, is guaranteed not to change
    the total amount of space for entries, even if that new file is later removed
    from the CBFS.
     Again, we use contradiction: assume that creating such a file causes a
     permanent...
      - CASE 1: ...increase in the amount of available space.
        + Then the combination of the inserted file, its header, and any padding
          must have exceeded the empty entry in size enough for it to cross at
          least one additional aligned address, since aligned addresses are how
          the limit on an entry's capacity is determined.
        + But adding the file couldn't have caused us to write past any further
          aligned addresses because they are the boundary's used when verifying
          that sufficient capacity exists; furthermore, by (B), no entry can ever
          terminate beyond where the initial empty entry did when the CBFS was
          first created.
        + Then the creation of the file did not result in a space increase.
      - CASE 2: ...decrease in the amount of available space.
        + Then the end of the new file entry crosses at least one fewer aligned
          address than did the empty file entry.
        + Then by (A), there is room to place a new file entry that describes the
          remaining available space at the first available aligned address.
        + Then there is now a new record showing the same amount of available space.
        + Then the creation of the file did not result in a space decrease.
    
    BUG=chromium:473726
    TEST=Had the following conversation with cbfstool:
    $ ./cbfstool test.image create -s 0x100000 -m arm
    Created CBFS image (capacity = 1048408 bytes)
    $ ./cbfstool test.image print
    test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
    alignment: 64 bytes, architecture: arm
    
    Name                           Offset     Type         Size
    (empty)                        0x40       null         1048408
    $ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1
    1+0 records in
    1+0 records out
    1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s
    $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
    E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big?
    E: Failed to add 'toobigmed.bin' into ROM image.
    $ truncate -s -1 toobigmed.bin
    $ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
    $ ./cbfstool test.image print
    test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
    alignment: 64 bytes, architecture: arm
    
    Name                           Offset     Type         Size
    toobig                         0x40       raw          1048408
    $ ./cbfstool test.image remove
    -n toobig
    $ ./cbfstool test.image print
    test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
    alignment: 64 bytes, architecture: arm
    
    Name                           Offset     Type         Size
    (empty)                        0x40       deleted      1048408
    $ ./cbfstool test.image print
    test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
    alignment: 64 bytes, architecture: arm
    
    Name                           Offset     Type         Size
    (empty)                        0x40       deleted      1048408
    BRANCH=None
    
    Change-Id: I118743e37469ef0226970decc900db5d9b92c5df
    Signed-off-by: Sol Boucher <solb at chromium.org>
    Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e
    Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc
    Original-Signed-off-by: Sol Boucher <solb at chromium.org>
    Original-Reviewed-on: https://chromium-review.googlesource.com/263962
    Original-Reviewed-by: Hung-Te Lin <hungte at chromium.org>
    Original-Reviewed-by: Stefan Reinauer <reinauer at google.com>
    Reviewed-on: http://review.coreboot.org/9939
    Tested-by: build bot (Jenkins)


See http://review.coreboot.org/9939 for details.

-gerrit