Firmware updater: Support "multiple firmware image with multiple keyset" |
||||
Issue descriptionCurrently firmware updater is designed for single image, single key (for single board). For LOEM we've implemented supporting multiple keys using customization ID. In Unified build, it changes firmware updater to select different images by reading model, but it seem to not support switching keys. For future, it'll become more and more often to see Zerg+LOEM model - that we have to support multiple firmware images (same or different board, even same board with different versions) and multiple keysets at the same time. Also, currently auto tests (or manual tests also FAFT) has some problem finding "what's in the firmware updater" - they try to grep the -V output, which was not designed for machine to parse. I think we want to solve these together at same time: - Change firmware updater to select image and key by model - For legacy devices, do a special mapping or change keyset names - Change firmware updater content to have some JSON based metadata for test programs to read.
,
Jul 28 2017
We need to nail down the constraints on 'mosys platform model'. In coral that's some ambiguous usage for some of the devices such that clamshell and convertible have their own names. However, they should be using the same firmware rootkey. We can handle it, but i think this is one of those things we need a hierarchical taxonomy such that we can push out all the identifiers use them accordingly.
,
Jul 29 2017
I thought we had managed to converge on every UB model = GE project name / Google project name in the discussion [here](https://docs.google.com/a/google.com/document/d/1fciymxz4y4IzsE-kM4wa0jznIasOg56HE-CbfRKRAYc/edit?disco=AAAABEKInA4). If that's the case, we simply use a different key for each model and are done with it. It doesn't really matter whether it's a convertible or clamshell or totally identical HW with a different sticker in the case of WL. In the end, a sku identified by the straps is mapped to a particular model. All the skus mapped to the same model get the same key. A WL project gets a different GE project name/model, hence a different key. Am I missing something?
,
Jul 31 2017
You aren't missing anything. I was bringing up that it we'll likely need more than one device point to the same root key.
,
Aug 3 2017
,
Aug 9 2017
I think we haven't get agreement for if model name should by unique per WL projects. That will change how updater and signer should deal with keysets.
,
Aug 9 2017
For the purposes of the requirements we should support it because if we can handle that condition we can handle any other thing we'd see -- even if we use more than just 'model'. It's just a string -> object mapping we need to handle.
,
Aug 18 2017
Hungte, what's your ETA for your changes and how much overlap/stepping on each other's feet is there with Simon/Jason making changes for b/64117873?
,
Aug 25 2017
We have a master configuration binding to support this with shared keys. Each model can have its own key or share keys with other models. What are Hung-te's changes?
,
Dec 15 2017
The plan has been changed a lot and I think so far what we heard is, - unified build will support signing different model with different keys. - for WL, that should be an unique model signing in LOEM keysets. So we are not doing "multiple firmware image with multiple keysets". At least not for now. Close as WONTFIX until we see more problems. |
||||
►
Sign in to add a comment |
||||
Comment 1 by hungte@chromium.org
, Jul 28 2017