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. But there is a problem with attempting this: when you request for option the hashing would always give a number, even if that option doesn't exist. And then we're back to reading garbage for new options.
2a) instead of having separate field we could make XOR layout checksum into CMOS checksum. This would save 2 bytes but will break any existing users if they check checksum.
(IIRC we already have problems with the Linux nvram driver which does checksumming somehow differently. Or maybe that was fixed already.)
Ok. Let's hold 2a in reserve if 2 bytes is considered too expensive
...but the above reminded me that it is ultimately a responsibility of our source code and our design to never let booting fail simply due to some garbage in NVRAM.
Code and design really must ensure a working state.
There are number of problems with this: 1) Overclocking options. If you overclock too much, you don't boot successfully. 2) FILO uses options to control its behaviour. If by garbage tells to boot from bad filename, it will probably stop unable to find the file. 3) vbnv field may be a problem. Even if this goal is achieved we still need an upgrade way as new option with garbage may make the system bootable but uncomfortable to most of users, which is to avoid. E.g. disabling touchpad: I personally disable touchpad (but through OS facilities, not coreboot) but many users would get confused by disabled touchpad.