On Fri, May 29, 2009 at 07:45:18PM +0200, Stefan Reinauer wrote:
On 29.05.2009 16:14 Uhr, Luc Verhaegen wrote:
Currently, our security of the cmos value being correct with respect to the options table, is the existence of the option name string in the optionstable, and the validity of the checksum. We need more than this, we need a better way of matching cmos data with the options table.
Why?
Example:
Run native bios on epia-m. It stops booting, loads the defaults and tells you to go into the config. Alter the config, boot again, and it is happy.
Then plug in a coreboot image. It flags that the checksum is invalid, and therefor most of the users of cmos data use a default, yet it continues booting.
Alter a single value with nvramtool, and suddenly the cmos checksum is correct. No matter what the other values are. Sometimes you're lucky, but in the epia-m case, you lose serial output (as it suddenly is the lowest value, a value which screen wasn't used to) and seabios tries to boot off the network. All one can do is clear the cmos and then boot properly...
What can be done to fix this: 1) track board and version information. 2) add some way to define the default settings in the cmos.layout.
Then there are several situations possible.
* when a legacy bios was run and the rtc is full of garbage (for us), or when a different board is used, or when the major is different. This should be treated the same way as an invalid checksum. Booting refuses to use it and feeds back defaults (which can also be overridden by code depending on the return value of get_option). Nvramtool can catch this nicely and can offer to fill in defaults, or at least refuse to correct the checksum. * when booting, and when a minor difference between cmos and option table is detected, treat the retrieved information as in the previous point. * when a minor difference between rom option table and cmos.layout is detected, then nvramtool can offer to program the default value of the difference, because it can find out the difference. * when the cmos.layout is for a different board, or of a lower version, then nvramtool should basically refuse to accept it.
Also when nvramtool detects invalid values, it can offer to program defaults or at least refuse to validate the checksum. nvramtool should be able to write anything though, through the use of some argument like --force. It should also be able to just set up everything by default.
Before any of this is done, the table generation code should get fixed to output more sensible things (why do we dump this to a list of chars in a table?) with things like defines or enums for the values. And we should be able to do checking at boottime as well.
I know that this all nontrivial to implement, and that therefor it'll take some time for someone to implement it. But i believe it makes sense, and it will definitely avoid a board booting up with invalid settings, and at least go for defaults.
Luc Verhaegen.