Factory key verification test for unified builds |
|||||
Issue descriptionWe have a test in the factory that checks that the root key is correct for the device being tested. There is a test for this in the Hardware ID configuration (see reef): https://chrome-internal.googlesource.com/chromeos/chromeos-hwid/+/refs/heads/factory-reef-8811.B/v3/REEF# - name: verify.root_key.electro when: ComponentEq('chassis', 'electro') evaluate: - Assert(ComponentEq('hash_gbb', 'hash_gbb_mp_v2_electro')) - Assert(ComponentEq('key_root', 'key_root_mp_v2_electro')) - name: verify.root_key.basking when: ComponentEq('chassis', 'basking') evaluate: - Assert(ComponentEq('hash_gbb', 'hash_gbb_mp_v2_basking')) - Assert(ComponentEq('key_root', 'key_root_mp_v2_basking')) The current approach is error-prone since it relies on people adding the correct test manually above. With unified builds we can use the signed firmware updater from the release image. We read the mapping from model to root key and then compare this with the firmware on the device.
,
Sep 12 2017
Here's the bug discussed in the rlz meeting
,
Sep 12 2017
,
Sep 12 2017
Just to confirm, the request here is that specifying "model" in hwid will imply a specific key and strapping to check, rather than specifying each separately, correct? But all three will be checked?
,
Sep 14 2017
re#4 To clarify that: The old way for reef mentioned in issue description is because there were multiple projects shared the same HWID and all root keys of projects would be all in the HWID database. If project A used the wrong key of project B then it can still be mapped "correctly" from HWID point of view. Hence this rule is to avoid this situation explicitly. Now with the unified build, there is only 1:1 mapping between HWID database and a model / project so this will not be happened (keys info should be only for one model / project). Issue: With unified build, it is still possible that someone submits root_key of model B to the HWID database of project A. In this case, the HWID verification will be failed in late stage of factory flow. In order to prevent this issue more ealier we can 1. keys info in HWID database can be extracted from chromeos-firmwareupdate directly by specifying the correct model name ( crbug.com/763328 ) not from probed result in the DUT. In the review process, we can ask partners to provide the output from ( crbug.com/763328 )
,
Feb 5 2018
Re-assign to yhong. The plan is to utilize and trust the firmware updater inside release image, instead of baking more firmware hashes that no one really confirmed if they're correct or not in HWID config database.
,
Mar 1 2018
Issue 807222 has been merged into this issue. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by sjg@chromium.org
, Aug 31 2017