[coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 274 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140126/71a50546/attachment.sig>