On 26.01.2014 05:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing
(which mentions another solution to the problem)
Flashrom solution is interesting but it doesn't handle external
flashing. It would be a nice addition to checksums for internal flashing
though.
Patrick's solution would have only one advantage compared to my
prototype: possibility of coreboot migrating the options rather than
resetting.
Patrick's solution relies on mathematical impossibility. You can't have
such function with only 16-bit salt. Let's take any partition of 248
(see http://mathworld.wolfram.com/PartitionFunctionP.html), then create
options A,B,C,... with sizes according to this partition. The hashing
function as per Patrick's proposal would have to map them to
non-interlapping regions. By evaluating this function at A,B,C,... you
can extract the partition if number of chunks is known. Since number of
chunks is an integer from 1 to 248 so the function has to store at least:
Log2[PartitionsP[248]]-Log2[248] 39
bits of information. So salt has to be at least 40 bits. Probably even
more if you put into mix that we also need sub-byte options and you have
to handle option names. This means:
1) You can't bruteforce such a parameter space during compile, so some
structure is needed.
2) You'll need more than 40 bits of storage in CMOS.
At this point I feel like Patrick's proposal is not practical.
signature.asc
Description: OpenPGP digital signature
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
