On 26.01.2014 05:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avo...
(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.