[coreboot] Understand vboot logic to select FW_B

[Aaron Durbin]

On Wed, Feb 15, 2017 at 3:20 PM,  <tturne at codeaurora.org> wrote:
> On 2017-02-15 09:45, Aaron Durbin via coreboot wrote:
>>
>> On Wed, Feb 15, 2017 at 11:38 AM,  <tturne at codeaurora.org> wrote:
>>>
>>> On 2017-02-15 07:46, Aaron Durbin via coreboot wrote:
>>>>
>>>>
>>>> On Tue, Feb 14, 2017 at 8:26 PM,  <tturne at codeaurora.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Folks,
>>>>> I'm working on coreboot on ARMv8 architecture and recently attempted to
>>>>> verify FW_B can be selected if FW_A is corrupted.
>>>>>
>>>>> In reviewing the code-path through coreboot vboot wrapper and
>>>>> vboot_reference library I'm not understanding the logic.
>>>>>
>>>>> The logic appears to be that vboot_reference library determines FW_A is
>>>>> corrupt and forces a reboot.
>>>>>
>>>>> After reboot, early in verstage_main(), both the NVRAM (flash) and
>>>>> vb2_context structures are initialized, wiping out any history of
>>>>> failure
>>>>> condition.
>>>>>
>>>>> I know I must be missing something in my analysis but don't see it.
>>>>>
>>>>> Can anybody on this list share their experiences in confirming the FW_B
>>>>> boot
>>>>> path if FW_A is corrupt?
>>>>
>>>>
>>>>
>>>>
>>>> ctx->flags & VB2_CONTEXT_FW_SLOT_B determines which slot to use. The
>>>> vbnv (vboot non-volatile) storage keeps counts for slots to try.
>>>> vb2_select_fw_slot() will do that work for you. It's located in
>>>> firmware/2lib/2misc.c. That function is called from vb2api_fw_phase2()
>>>> in firmware/2lib/2api.c.  All this logic lives in vboot_reference code
>>>> repository.
>>>>
>>>
>>> Thanks for this recap, I had identified most of this path previously.
>>>
>>> I can clearly see the corrupted A slot being detected and the status
>>> updated
>>> and vboot requesting a reboot.
>>> The reboot causes verstage to go through its initialization sequence,
>>> which
>>> in my case blows away the history of the reboot, so the cycle repeats
>>> endlessly.
>>> FW_A slot detected as corrupt reboot requested to boot from FW_B, reboot
>>> blows away this data and FW_A is detected to be corrupt and reboot
>>> requested, etc.
>>>
>>> I have verstage configured to run from bootblock, no DRAM/CBMEM
>>> available,
>>> just the RW_NVRAM fmap partition on the flash.
>>> I haven't made any change in vboot_reference or the coreboot vboot
>>> wrapper
>>> layer so for me, out of the box, something is amiss.
>>
>>
>>
>> The try count should drop on each reset. And then it should swap to
>> slot B. All of our ARMv8 and x86 boards utilize the same path. Have
>> you ensured your vbnv bindings are working? And dumping the vbnv
>> contents to the terminal each time might be helpful. I'm not sure what
>> platform you are running so it's hard to know what configuration and
>> support files you are including. Do you have serial console logging
>> enabled? What's it say?
>>
>> If you don't have one of these set then you wouldn't be reading any
>> vbnv -- or saving:
>>
>> CONFIG_VBOOT_VBNV_CMOS
>> CONFIG_VBOOT_VBNV_EC
>> CONFIG_VBOOT_VBNV_FLASH
>>
>> Check out read_vbnv() and save_vbnv() in src/vboot/vbnv.c.
>
>
> CONFIG_VBOOT_VBNV_FLASH is set in our system.
> I think the key point I was missing before is the vboot reset has to retain
> vboot bss data.
> The vbnv_flash variable (static struct vbnv_flash_ctx) has to remain
> initialized across the reboot.

No. We aren't reliant on that. It would get wiped on program load. If
it doesn't that's a bug. The vbnv is supposed to maintain the state
and the flow will reload the necessary state.

>
>
>>
>>>
>>> I would be interested in hearing from anybody on the list on an ARMv8
>>> target
>>> who has run the same test I'm trying to reproduce here.
>>> Specifically, I'm not running the test code in vboot_reference, I am
>>> manually corrupting partition A before flashing it.
>>> Cheers,
>>> T.mike
>>>
>>>
>>>>
>>>>> Cheers,
>>>>> T.mike
>>>>>
>>>>> --
>>>>> coreboot mailing list: coreboot at coreboot.org
>>>>> https://www.coreboot.org/mailman/listinfo/coreboot