Matchmaking for Normal (Verified) Mode

29 views
Skip to first unread message

Marc Herbert

unread,
Oct 20, 2016, 2:28:56 PM10/20/16
to Chromium OS dev
There are many resources about entering Developer Mode, but sometimes one also needs to revert back to Normal/Verified Mode. It could be to debug an elusive issue happening only or more frequently in Normal Mode, to run some tests in the same configuration than consumers (in which the firmware doesn't initialize the display), or maybe just to enjoy... security again.

For Normal Mode the kernel partition must be signed with the keys that the firmware expects. This is the one link in the chain of trust that Developer Mode allows to be broken, correct? In practice we found (re-)matching these two sides to be a challenge when juggling with hardware, firmware and software at various and evolving stages of development; since they rely on various keys. So is there a simple way to dump keys and check whether:

   1. the key a given kernel partition is actually signed with 
           matches
   2. the key that the firmware expects it to be signed with?

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)?

/etc/lsb-release can contain a useful "-mp" or "-mp-v2keys" suffix. Is there something similar information for firmware?

Thanks!

Randall Spangler

unread,
Oct 20, 2016, 2:36:48 PM10/20/16
to Marc Herbert, Chromium OS dev
Use dev_debug_vboot, which will print key hashes and attempt validation of RW firmware and kernel and print the results.


--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en


Mike Frysinger

unread,
Oct 21, 2016, 6:12:16 PM10/21/16
to Marc Herbert, Chromium OS dev
On Thu, Oct 20, 2016 at 11:28 AM, Marc Herbert <marc.h...@gmail.com> wrote:
There are many resources about entering Developer Mode, but sometimes one also needs to revert back to Normal/Verified Mode. It could be to debug an elusive issue happening only or more frequently in Normal Mode, to run some tests in the same configuration than consumers (in which the firmware doesn't initialize the display), or maybe just to enjoy... security again.

For Normal Mode the kernel partition must be signed with the keys that the firmware expects. This is the one link in the chain of trust that Developer Mode allows to be broken, correct?

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

In practice we found (re-)matching these two sides to be a challenge when juggling with hardware, firmware and software at various and evolving stages of development; since they rely on various keys. So is there a simple way to dump keys and check whether:

   1. the key a given kernel partition is actually signed with 
           matches

futility show /dev/sda2 /dev/sda2

   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.

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)?

there should be 0 overlap between devkeys and real signed keys.  devkeys would only match local developer builds because those are what build_image/etc... use to sign with.

/etc/lsb-release can contain a useful "-mp" or "-mp-v2keys" suffix. Is there something similar information for firmware?

currently, no.  also remember that /etc/lsb-release is stamped once at image signing time and is no guarantee the keys haven't been changed since (manually by a dev of course).
-mike

Julius Werner

unread,
Oct 21, 2016, 9:06:32 PM10/21/16
to Mike Frysinger, Marc Herbert, Chromium OS dev
> 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).

Marc Herbert

unread,
Oct 22, 2016, 1:27:11 AM10/22/16
to Chromium OS dev
2016-10-21 18:06 GMT-07:00 Julius Werner <jwe...@chromium.org>:
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).

This is the simplest and safest option for a consumer device. It
doesn't let choose a specific version and it doesn't work
for development systems. I mean sometimes it's not even very clear
which kind of firmware is on a randomly given system - hence the
original question.

The "few minutes" can extend depending on network
connectivity, availability of a spare removable, a Windows PC
and other "real-world" annoyances.
Also, a "few minutes" is a short time... in a Windows world, not in
a ChromeOS world ;-)

Thanks everyone for the expert answers; the next step is clear:
spending some quality time with /var/log/debug_vboot_noisy.log

Vincent Palatin

unread,
Oct 23, 2016, 1:34:58 PM10/23/16
to Marc Herbert, Chromium OS dev
On Fri, Oct 21, 2016 at 10:26 PM, Marc Herbert <marc.h...@gmail.com> wrote:
2016-10-21 18:06 GMT-07:00 Julius Werner <jwe...@chromium.org>:
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).

This is the simplest and safest option for a consumer device.

I'm doing it on my development systems several times a week.

 
It
doesn't let choose a specific version


It does use the specific version used as the recovery image.
Maybe the tool you are using to download the recovery key image doesn't let you pick the version, but that's independent of the recovery process itself.

 
and it doesn't work
for development systems. I mean sometimes it's not even very clear
which kind of firmware is on a randomly given system - hence the
original question.

If the machine still boots, booting the recovery key with the developer USB boot mode (dev_boot_usb=1 and ctrl+U) will both get you back on a properly signed MP bootloader and with a working normal image.
That's honestly several order of magnitude easier than what you are trying to achieve.

 

The "few minutes" can extend depending on network
connectivity, availability of a spare removable, a Windows PC
and other "real-world" annoyances.
Also, a "few minutes" is a short time... in a Windows world, not in
a ChromeOS world ;-)


Are you referring here to Chrome app to create recovery stick ?
Yes, that's not the fastest or the most reliable way of getting recovery image. 

 

Thanks everyone for the expert answers; the next step is clear:
spending some quality time with /var/log/debug_vboot_noisy.log

Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages