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: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
