> i thought you could boot dev signed firmware, but maybe i'm confusing it
> with chainloading to a partition which means it'd be the same as a kernel
> blob
No, you can't. Yes, you probably are. (You can also run unverified
firmware from the RW_LEGACY flash section by pressing CTRL+L instead
of CTRL+D, but that is chainloaded after verified RW firmware.)
>> 1. the key a given kernel partition is actually signed with
>> matches
>
>
> futility show /dev/sda2 /dev/sda2
That won't really tell you whether it matches the firmware, though.
You have to pass -k to futility to pass in the public kernel subkey,
which you'd have to extract from your RW firmware first...
dev_debug_vboot is a nice tool that does all of this for you. (It also
runs automatically and you can just look at the results in
/var/log/debug_vboot_noisy.log.)
>> 2. the key that the firmware expects it to be signed with?
>
>
> the key is embedded in the firmware and the firmware is in the flash. you
> could prob use flashrom to extract the firmware, then use cbfstool to
> extract blobs from it. a pita to be sure.
>
> i wonder if extending crossystem to dump the fw keys would make sense.
Keys are stored in the VBLOCK FMAP sections, not in CBFS, so all you
need is to run futility on the full firmware image. It's not that
common a task so I don't think we need anything else in crossystem on
top of that (and as Randall said, dev_debug_vboot tells you everything
you could want to know in this area for 99% of the cases anyway).
>> Pressing "Tab" on the firmware screen shows a few SHA1 checksums.
>> "futility show" on kernel partitions and devkeys/ files displays other "data
>> key" SHA1s. However I could not find any relationship between the first and
>> second sets, is there one? Have been looking in the wrong place(s)?
The firmware screen only dumps the hash of the root (and recovery)
key, which isn't really enough to tell if it will boot a certain
kernel on its own. Since the kernel VBLOCKs do not store the public
half of the subkey (they're simply signed by it), you need to extract
the full key and have futility validate the signature with it to
really find out of they match. Again, dev_debug_vboot does this for
you. (The one thing the TAB display is good for is to quickly check
whether the root key starts with b11d74ed, because that's our dev
key... if it doesn't, that usually means in practice that you have the
latest MP keys.)
As for the original question, the easiest and most foolproof way to
get a Chromebook back into pristine state is really to just go through
the
http://www.google.com/chromeos/recovery process. It only takes a
few minutes and should bring you back reliably from any state (unless
you cracked open the device and really mucked with it badly).