Check VPD - whitelabel_tag in the finalize process of GRT if DUT is a Whitelabel model |
|||
Issue descriptionStarting from unibuild-v1, a new factory process for whitelabel project is to provision VPD - whitelabel_tag from shopfloor. Regarding verification, we have no way to verify whether LOEM name in whitelabel_tag is correct or not but we can indeed check that whether whitelabel_tag is provisioned or not since it is a mandatory requirement for whitelabel project. A following action: In the finalize process, we can base on sku id and whitelabel_tag to get correct hash of rootkey from chromeos-firmwareupdate in the recovery image. In this way, we can eliminate the firmware_keys from HWID database.
,
May 10 2018
,
May 11 2018
One issue is that, it seems there is no way to identify whether this DUT is a whitelabel device or not. 1. mosys didn't provide such kind of information. 2. cros_config can't either. Regarding cros_config, I tried to call `cros_config /firmware sig-id-in-customization-id` (which is the way in impl of cros_config to check whitelabel) but it fails. Maybe because that property didn't have a value in string format. Hi Charles, Is it an idea to add a command like `cros_config --is_whitelabel`? Or any existing way to identify whether a DUT is a whitelabel device or not? Thanks.
,
May 11 2018
While this feature would be nice, it shouldn't be a blocker because we shoudl have a list of branding (either models, or model+wltag) that this factory is authorized to provide. Currently this is exported via HWID file. If we remove allowed keys from HWID, we can add allowed model/whitelables to HWID or to another file passed with HWID. For a current example, "whitetip" is fully functional, including firmware update, without a whitelabel tag. But it won't pass HWID since the default model's key isn't present as an approved key in the HWID file.
,
May 11 2018
Regarding case of whitetip, 1. If whitelabel tag is not provisioned and performed firmware updating already, then the check planed here will block it first so the mis-shipping with default key will not be happened. 2. If whitelabel tag is provisioned, then `mosys platform signature` or `cros_config XXX` should be able to report expected signature id. Then we have the key to verify whether current key in firmware is as expected in chromeos-firmwareupdate as long as we can make sure FSI have the correct key information in chromeos-firmwareupdate. The only exception is there is a "whitelabel-tag - default" (magic word) in the model config which is used before any loem is identified. It looks like that default tag should be removed after any loem is ready.
,
May 11 2018
One edge case we will need to plan: 1. Factory updates firmware with correct whitelabel-tag provisioned. 2. Later, somehow whitelabel-tag is deleted. 3. DUT will be shipped with this status without this plan. Finally the brand-code can't be queried by the SW in user's hand. |
|||
►
Sign in to add a comment |
|||
Comment 1 by marcochen@chromium.org
, May 2 2018